Update to fix failing, stale build

[leonowski]

• update to ubuntu Focal (required for latest wine package install)
• update to latest versions of novnc and websockify
• add python as Focal needs it specified.
• add cifs-utils so users can mount shares in container and thus write to network shares in BlueIris
• add unzip so we can run it in blueiris.sh and extract ui3.zip (fixes issues where ui3 doesn't work)

[leonowski]

Few things I forgot to mention in the readme and it should probably go in somewhere:

• On first launch, it's best to wait for the blueiris.exe download. You can follow the log using the command docker logs -f <containername>. After it's done, launch the GUI on port 8080.

• It might be possible to do updates when they are available by:

1 - Destroying the container (save persistent data location).
2 - In persistent data location, delete BlueIris.exe in Program Files.
3. Redeploy container.

That should force a redownload of the latest version and the install wizard should be upgrade focused. This should also trigger the uninstall/repair dialog if it's the same exact version.

[TonyBrobston]

I pulled down this branch and am building and testing. I had some weird results using my previous volume mounted data (/root/prefix32). I removed the volume mount to test on a clean install and after Blue Iris installed it just set at a screen with an Ubuntu icon in the middle of the background. Is there something I'm doing wrong here?

[TonyBrobston]

I'm also having problems installing some Microsoft tools:

[jshridha]

@TonyBrobston I just built it and ran it and had the same issue.

[TonyBrobston]

@leonowski Is the same happening for you?

[leonowski]

@leonowski Is the same happening for you?

Strange. I do not have that issue now. It goes through the install and finishes properly. After you launch a fresh container with a fresh volume mounted for /root/prefix32, tail the docker log (or run it interactively). Watch for the blueiris.exe download. Wait for that to finish and then visit the GUI.

I do remember running into that problem early in my trials - but I don't remember what was done to fix it. Just make sure your prefix dir is clean (basically, start from scratch).

On a side note: I also made this install the 64-bit binary install instead of the 32-bit version. I put it up on my repo in the dev branch. It's simply a matter of turning off the ENV VAR for the WINEARCH and removing all the "32" references. I'll put up a PR for that later.

[jshridha]

On a side note: I also made this install the 64-bit binary install instead of the 32-bit version. I put it up on my repo in the dev branch. It's simply a matter of turning off the ENV VAR for the WINEARCH and removing all the "32" references. I'll put up a PR for that later.

That may be why the visual c++ installer didn't give you problems. That PR would be great. Since docker only runs on x64 machines anyways, I see no downside to this dependency.

[leonowski]

OK, but the 32-bit version did work for me. I suspect the same problem will still happen. You should start with a clean prefix environment for wine.

[TonyBrobston]

I've been running with no volume mount, so I believe it would be a clean environment every time.

Maybe I'm not understanding something and it's somehow running off an old container or old built image. I have been running docker-compose up -d --build each time, so I thought that meant I'd get a fresh built container each time. I went ahead and deleted all my stopped containers and all my images and am doing a build on the 64bit-test branch.

[TonyBrobston]

I just finished that build and ran into the same "Setup Failed" as above. I've been trying to google on "0x80070643" and wine, but I haven't come up with much. I'll keep digging.

[leonowski]

If your containers are stopped and you aren't mounting any external volumes, it should persist your data since it is in the container filesystem layer. The only way to destroy the data is to docker rm <container_name.

It's best to mount an external volume for the /root/prefix path in the container (formerly /root/prefix32). That way, you can manipulate files inside the wine environment easily. You can also start fresh if you need to.

The problem with this (now that I remember) could be that the wine prefix might be required to be mounted as a volume. I suggest building and running the container manually with docker directly instead of docker-compose like this:

docker build -t image_name_of_your_choice .

docker run -d -p 81:81 -p 5900:5900 -p 8080:8080 -name some-container-name -v /some/local/path:/root/prefix:rw image_name_of_your_choice

[TonyBrobston]

I suggest building and running the container manually with docker directly instead of docker-compose like this:

docker build -t image_name_of_your_choice .

docker run -d -p 81:81 -p 5900:5900 -p 8080:8080 -name some-container-name -v /some/local/path:/root/prefix:rw image_name_of_your_choice

I'll give that a shot.

[TonyBrobston]

@leonowski I did as you suggested and got the same result. I paid more attention to the logs though (in docker logs -f). Here's what printed when I got the "Setup Failed". Not sure if this helps.

00a5:fixme:advapi:DecryptFileW (L"C:\\windows\\Temp\\{10B8A047-32ED-442F-96ED-DFD72EFCB157}\\", 00000000): stub
00a5:fixme:exec:SHELL_execute flags ignored: 0x00000100
00aa:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
00aa:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
00aa:fixme:ole:CoInitializeSecurity (0032F5E8,-1,00000000,00000000,6,2,00000000,12288,00000000) - stub!
00aa:fixme:wuapi:automatic_updates_Pause
00aa:fixme:sfc:SRSetRestorePointW 0032F4B0 0032F6C0
00ad:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{DD1EC0FD-3F0A-4740-A05E-1DCD14A6B0D1}v14.26.28720\\packages\\vcRuntimeMinimum_amd64\\vc_runtimeMinimum_x64.msi", 00000000): stub
00ad:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{DD1EC0FD-3F0A-4740-A05E-1DCD14A6B0D1}v14.26.28720\\packages\\vcRuntimeMinimum_amd64\\cab1.cab", 00000000): stub
00ad:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{CB4A0FDE-1126-4AE2-97C6-A243692C3D95}v14.26.28720\\packages\\vcRuntimeAdditional_amd64\\vc_runtimeAdditional_x64.msi", 00000000): stub
00ad:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package Cache\\{CB4A0FDE-1126-4AE2-97C6-A243692C3D95}v14.26.28720\\packages\\vcRuntimeAdditional_amd64\\cab1.cab", 00000000): stub
00aa:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
00aa:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
00aa:err:msi:ACTION_InstallFiles compressed file wasn't installed (L"concrt140.dll")
00aa:err:msi:execute_script Execution of script 0 halted; action L"InstallFiles" returned 1603
00aa:err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603

[TonyBrobston]

After reading some more logs (by clicking the log file hyperlink in the screenshot above) it seems like this section is important:

[leonowski]

What if you try the docker image I have built?

leonowski/docker-blueiris

Any difference?

[TonyBrobston]

What if you try the docker image I have built?

leonowski/docker-blueiris

Any difference?

I tried docker run -d --name blue-iris -e RESOLUTION=1440x768x24 -p 81:81 -p 590 0:5900 -p 8080:8080 -v ~/blue-iris:/root/prefix:rw leonowski/docker-blueiris but had the same "Setup Failed" issue.

[TonyBrobston]

After opening a bash terminal inside vnc, I messed with installing a bunch of Microsoft Visual C++ (by saying winetricks vcrun2015 where 2015 is the version year; can be found here https://github.com/Winetricks/winetricks/blob/master/src/winetricks by searching for vcrun) installations and changing Windows versions with winecfg, I eventually somehow got Microsoft Visual C++ 2015 installed and then Blue Iris started just fine. I'm deleted everything and am going to try again. After googling around I found things like, 'i've noticed that installing vcrun2008 before 2005 helped for me" and other things like, "we installed every version starting from oldest to newest and it worked". So... I'm just trying a bunch of different approaches to find one that works.

[TonyBrobston]

After a little more testing I was able to run an install command of the current Microsoft Visual C++ version that was installed. It gave me an uninstall option. I uninstalled, then after an attempt or two to install Microsoft Visual C++ 2015 it took and then Blue Iris opened just fine.

[leonowski]

I just tried it on another docker host I have and noticed the same problem. It seems like I forgot to include an option I'm using to run my container: privileged mode.

So, add the option --privileged to the run command. I think that will make it work for you.

Alternatively, included in the container is winetricks. You can use that to install the MS VC++ runtime using the command:

winetricks vcrun2019

But, that shouldn't be necessary now. Try it with privileged mode.

[TonyBrobston]

@leonowski Cool --privileged did the trick!

[jshridha]

@TonyBrobston @leonowski

It looks like this PR is ready for merge. Any additional outstanding issues you see that need to be addressed?

[TonyBrobston]

@jshridha It looks good to me. I'd like to figure out how not to need the privileged flag, but that can be explored in a future PR. I think we should keep this moving along.

Great work @leonowski!

[jshridha]

@TonyBrobston I agree. I updated the docs to show that you only need the privileged flag for the initial run to do the Visual C++ install. After that, you're good to turn it off.

[TonyBrobston]

@jshridha @leonowski Are you guys ready to merge/deploy this?

[kloknibor]

Seems like a good solution, thanks @leonowski (and @jshridha )!

[nemesis519]

You guys are my hero! Can't wait to get rid of my old box that's just for blueiris.

[jshridha]

Looks good to me. I'll merge and let dockerhub build the dev image.