Closed leonowski closed 3 years ago
@leonowski I'll try running leonowski/docker-blueiris:run_as_service
for a bit. I do have a license. Do I have to go into Blue Iris settings and check the box to run as a service or does it do it automatically?
Also, if you haven't purchased a license, I did find a discount code on the interwebz; I think it was 15% off. Totaled to like $66. I figured even if I don't run Blue Iris long term; $66 is worth the peace of mind of the same question you're asking, "Does the free version have less functionality?"
As for the 32-bit vs. 64-bit. I did have the Blue Iris crash on 64-bit, but it happened randomly; when I click record it does fine. I have had less issues on 32-bit, but I still have had a few issues. Like right now, 8080
is up and running fine, but 81
randomly stopped serving. I'm also seeing a lot of 004e:fixme:msvcrt:MSVCRT__stdio_common_vswprintf options 26 not handled
and 004e:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled
in the logs. I'm not sure where I should put the details since I'm running on leonowski/docker-blueiris
currently.
@leonowski When I check the box to run Blue Iris as a service, it asked for a username/password. I assume I don't have to give it one? After that it told me to restart Blue Iris. I was thinking I could just hit the power button in the top right and it would automatically restart with the script that you said runs everything 30 seconds? It didn't seem to ever restart, so I did a docker restart
on the container. When it comes back up I get this error:
This puts me in a pretty sore state as I can't open Blue Iris to turn the "run as service" off. I'm not sure how to recover other than to blow my setup away and start from scratch. In the future I'll be sure to swap my volume mount to point to like /tmp
and test before modifying my real setup.
When I got into the container and ran the blueiris.sh
, I got some log output:
root@f1a8dc97aafd:~# ./blueiris.sh
0044:fixme:service:scmdatabase_autostart_services Auto-start service L"BlueIris" failed to start: 2
002c:err:module:process_init L"C:\\windows\\system32\\bash.exe" not found
root@f1a8dc97aafd:~# 00c0:fixme:heap:RtlSetHeapInformation 00000000019A0000 0 000000000031E890 4 stub
00c0:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 000000000031E554, 000000000031E570 000000000031E550
00c0:fixme:nls:get_dummy_preferred_ui_language (0x38 000000000031E554 000000000031E570 000000000031E550) returning a dummy value (current locale)
0060:err:service:validate_context_handle Access denied - handle created with access 15, needed 2
00c0:fixme:shell:InitNetworkAddressControl stub
I also saw someone say "I think you have to run the executable as administrator for it to allow “install as service”." on reddit. I really have no idea if this is necessary or possible: https://www.reddit.com/r/BlueIris/comments/g5ki6h/failed_to_install_blueiris_5_as_a_service/
Here is the window where it asks for username/password for reference:
I guess I should have been more clear on what this PR does. I made it because of the problem of trying to auto-create the service through the Blue Iris GUI (it does not work). So, these changes I put in automatically sets it up as a service upon installation. It will then kill the container. After starting the container again (with the persistent data store /root/prefix), the GUI launch will run in the 2 process mode (GUI + service). If you check the options, it will have the "Run as Windows service" box checked
I put these in the notes, but there are new run options that need to be specified:
--init
- to allow the internal script to kill PID 1
-e TZ=yourtimezone
- to pass the TZ env var
In addition to this, you must mount /root/prefix
as a persistent store somewhere on your system. Also, privileged mode is still required during the install.
@leonowski Is it possible for me to disabled the "start as a service" without opening the Blue Iris UI?
So, I checked in a couple of things into this strange branch. It looks like mfc42 was another dependency for something in blueiris, so I added that. I also noticed that the service does indeed run with this build, but it kept closing fairly quickly for some unknown reason. To my surprise, it seemed like launching the windows Task Manager in the container kept the service running. I will still have to explore this - wine is very strange and I'm new to it. Actually, it seems like if I keep any windows process up, the service stays up (like a cmd prompt). But, taskmgr seems to be a good thing to run since you can keep track of the blueiris.exe.
If this service stuff works out, we could have 2 modes when launching this container controlled by env vars: A "headless" mode that just runs the service and whatever minimal components are needed and a admin mode that can launch the management GUI to do things like add cameras and such.
@leonowski I'm going to pull the latest on that and run it for awhile.
I've been having Blue Iris randomly lock up about once a day. Once it's locked up I can't seem to do anything. A docker restart on the container brings it up just fine, but while it was locked up it isn't recording. It also happens to have the update screen up, may or may not be related.
I'll report back later, after running your latest updates for the day.
I also noticed that the time/timezone is correct everywhere except the timestamp that is in the camera view. However when I used this solution before, it worked everywhere: https://github.com/jshridha/docker-blueiris/issues/17#issuecomment-685886361
Here is an example of the time/timezone. You can see that the time on my mac and the time on the ubuntu vnc thing match, but the time in the video window does not.
Also, I haven't said this enough. Thank you for all the work you have been doing! It seems like you're very knowledgable and I really appreciate that you're diving deep into this. Let me know in what ways I can help, as I'll fill whatever gaps I can.
This latest check-in for this branch seems to be working better. I need to update the README still, but here are the important points:
Persistent data store /root/prefix is required. Everything else is in the ephemeral container. So, make sure you set up a mount for /root/prefix so you can persist that data (it's the wine environment).
Task Manager is launched by supervisord at startup. This has the benefit of bringing up the Wine Mono and Wine Gecko installation dialogs as soon as the container is first launched. You no longer have to wait for the blueiris.exe installer to download first. Yay.
After installation, uncheck the 2 checkboxes at the end of the wizard that allow you to read the blueiris readme and launch blueiris immediately. You want to skip this because after the wizard is done, the blueiris.sh script will kill PID 1 to stop the container (you must then restart the container one more time or have originally set the container to restart=always
.
After it comes back up, the GUI should launch. At this point, you can go ahead and set up the app as you like. Add cameras, set up the web GUI interface, etc. After you finish, destroy the container. This will leave you with the persistent data.
Now, here's the fun part: You can run this as a docker container that runs the blueiris.exe as a service only. X11, novnc, X11vnc, and flux box will not run. It will run as a pretty tight container that only runs blueiris.exe and some supporting processes (supervisor, a windows dummy CMD window to keep the blueiris service running, and a process watching script that will force the container to die if blueiris.exe crashes). This makes the container behave like a real service. You can then work with blueiris through the UI3 interface (on port 81). To run as a service, launch the container again using the existing persistent data and a command: -c /etc/supervisor/conf.d/supervisord-service.conf
. This will force the container to use the alternate supervisor config that only runs the service.
The downside to this is that if you want to go in and do things like add more cameras or manage the server, you will have to destroy the container again, and then relaunch without the -c /etc/supervisor/conf.d/supervisord-service.conf
. Things should restart fairly quickly, but blueiris will be down for that short period of time between restarts.
Other interesting notes about this version:
I removed the multiple uses of RUN in the Dockerfile in an attempt to shrink the file system layers. It seems to have worked. This image is still pretty huge though. It might be good to have another image that just has minimal components when running in service-only mode.
ENTRYPOINT (/usr/bin/supervisord) is now used with a default CMD. This allows us to change the launch options easily using CMD at run time.
Finally, I'm still having problems with recording continuously on 64-bit. :( Maybe it's the kernel I'm using. I'm on 4.19. I'm curious to know what you're using @TonyBrobston )
@leonowski I'll give this last post a read when I have some time and update to the latest (probably tonight or tomorrow afternoon).
As for the kernel version, I googled and found a few commands:
server:~$ uname -r
4.15.0-91-generic
server:~$ uname -a
Linux server 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
server:~$ cat /proc/version
Linux version 4.15.0-91-generic (buildd@lgw01-amd64-013) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020
I had a spare minute so I updated things as you mentioned above. Also my timezone issue I described a few comments back seems to be gone.
I'll run things as a service for a day or two and report back.
Here's my docker-compose for reference:
blue-iris:
image: leonowski/docker-blueiris:run_as_service
restart: unless-stopped
privileged: true
init: true
environment:
- RESOLUTION=1440x768x24
- TZ=America/Chicago
ports:
- 8080:8080
- 5900:5900
- 81:81
volumes:
- /tmp/blue-iris:/root/prefix:rw
command: -c /etc/supervisor/conf.d/supervisord-service.conf
I spun up another container to test this setup: https://github.com/danecreekphotography/node-deepstackai-trigger/wiki/Integrating-with-BlueIris
In the process I noticed the time/timezone in the video window was wrong again. I did a quick docker restart
on that container and the time/timezone immediately corrected itself.
@leonowski I just now realized what you meant when you said "recording continuously". I thought you were referring to just hitting this button:
I'm messing around with setting up node-deepstackai-trigger
and am having some issues when I select:
Basically the Blue Iris program stays running but the cameras just freeze.
I was able to determine the problem. The problem happened when recording started and these options were turned on:
Direct to disk recording should allow the h264/h265 streams from my cameras to be saved directly to disk without re-encoding by blueiris. I believe the problem happens because turning on overlay actually requires re-encoding since it is adding information to the original stream. In any case, I don't need to use the overlay feature since my cameras can do this directly and this can save some CPU cycles on blueiris. We should add this problem to the notes.
The interesting problem that arose from this is that blueiris would get in a state of continuous restarts if something bad happens with the camera settings. To get out of this, you can disable the camera by changing the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Perspective Software\Blue Iris\Cameras(your_camera)name\
There is a value for "Enabled" set to 1. If you set it to 0 and restart the container, you can get out of this state. You can change the .reg files in a text editor directly (in the wine prefix /root/prefix).
This got me thinking - it might be good to have a script or some type of "safe mode" that disables all cameras. This will allow you to at least get into the Blue Iris GUI to fix some things.
@leonowski Have you tried using this Blue Iris docker image with node-deepstackai-trigger
? I'm trying to trigger my camera. I am able to get node-deepstackai-trigger
to call the correct Blue Iris endpoint. I seem to be having some sort of networking issue. The Blue Iris container/service/network name is blue-iris
. Here's what the logs say:
[Web request] /aiinput/person.jpg: Calling trigger uri http://blue-iris:81/admin?trigger&camera=house_east&user=[redacted]&pw=[redacted]
When I run the same thing from a web browser on my development machine substituting blue-iris
with my server's IP, it triggers the camera just fine:
http://[my server's IP here]:81/admin?trigger&camera=house_east&user=[redacted]&pw=[redacted]
However if I do the same thing from triggers.json
it will show:
[Web request] /aiinput/person1.jpg: Calling trigger uri http://[my server's IP here]:81/admin?trigger&camera=house_east&user=[redacted]&pw=[redacted]
but still it won't trigger the camera.
Since you're exposing port 81 on the host, you can use the host ip instead of the container name and it should work.
@leonowski I tried that, unfortunately no luck 😢 .
As a test, you can launch the container and override the entrypoint and user like this:
docker run -it --entrypoint=/bin/bash --user=root --rm danecreekphotography/node-deepstackai-trigger
Once inside the shell, do a apt update
followed by apt install curl
. Then, you can try to use curl from inside this test container. Maybe it can help you figure out the networking issue. You can install other tools too to help you figure out things from inside the container.
@leonowski It looks like it's an issue with the security around Blue Iris' web server. I just pulled down the danecreekphotography/node-deepstackai-trigger
repo and added a console.log
to the Promise.all
to print the return of this call:
Looks like it returns the entire Blue Iris login page. So, seems like I have something configured incorrectly in Blue Iris to allow this to work.
Seems like the issue is that docker is assigning a 172
address and I think Blue Iris isn't allowing 172
addresses. I'm not quite sure what to do in this case. I don't really know the difference between 192
and 172
addresses...
The docker default subnet for container network is 172.17. 0.0/16. So, you can get any IP from that for containers. That is in the private range like 192 addresses. It shouldn't affect your ability to reach the IP you can reach blueiris at. I just tested this and blueiris's web server works fine inside the docker container from other containers. You can test this by trying to curl or netcat the private IP address and port from the host or other containers.
How are you webserver settings set up? Use Secure session keys and login
should be turned off. You may want to turn off auto banning as well. Also, set authentication to be required from all connections.
@leonowski You're my savior man. That worked. Thank you!
This last update adds the ability to run Linux scripts from inside the WIndows/Wine environment. This is good for configuring alerts in Blue Iris. Got it from this:
https://wiki.winehq.org/FAQ#How_do_I_launch_native_applications_from_a_Windows_application.3F
That way, you don't have to do any fancy windows stuff to trigger something. Just call a trusty linux script to do something (like curl another web service).
@leonowski I grabbed the latest again and am running it.
I've noticed a lot of:
00f4:fixme:variant:get_date_format ignoring flags 400
in the logs, any idea what that is?
I've also been seeing a lot of:
in the web UI, I've had to switch from the HTML5 player to JavaScript to make it usable; otherwise it refreshes the UI every few seconds.
I don't know what the get_date_format warning message is for. I have not looked into it yet. I see the same thing.
I have the same problem in the Web UI as well and have to switch to the javascript player too. I then tested it against a real Windows installation and I'm running into the same issue. It seems to be a problem with Blue Iris. Haven't found a solution yet.
@leonowski With a bit of digging, looks like others are having he same issue as of recently. I wonder if it'd be worth eventually working towards tagging docker images based on blue iris versions? That way we could swap a tag to switch easily?
https://ipcamtalk.com/threads/video-delay-has-exceeded-60-seconds.50796/
The issue was actually outside of Blue Iris and with the UI3 package. Extracting the latest version to the UI directory in your wine prefix will fix this: https://github.com/bp2008/ui3/releases/tag/118
The container is not set up to keep track of versions and Blue Iris doesn't seem to keep a storage area for historical releases. They just have their main download. We could change the startup script to use an ENV VAR for the download URL if you have your own file that you want to use.
@leonowski In an attempt to upgrade versions I deleted BlueIris.exe
from here:
https://github.com/leonowski/docker-blueiris/blob/bb32638307ca4426c65a44522ae968dd6e9c757d/blueiris.sh#L3
It seems to download using: https://github.com/leonowski/docker-blueiris/blob/bb32638307ca4426c65a44522ae968dd6e9c757d/blueiris.sh#L19 Then at some point the container dies and is restarted, then it downloads again, and then the same over and over and over until I stop it.
I also get this error message in the UI:
Hi @TonyBrobston
Sorry about that. I was wrong about the upgrade process. I had tested it using the same exe install files, but not with an actual newer build of the installer exe. It looks like this was the wrong way to go. Do you still have access to the deleted blueiris.exe? If not, I can post them somewhere for you to get. I had renamed mine instead of deleting them.
I have changed the supervisor config to not restart blueiris.sh. That will allow you to continue running in the X11 desktop environment after the main blue iris processes close. So, you can do the update using the update button in the Blue Iris settings. I realize this doesn't help you now after deleting the exe - so, let me know if you need it. Once you get the blue iris GUI up, run the process to update and it should close and restart blueiris for you.
@leonowski I ended up just manually reconfiguring my Blue Iris. Since I've been in there a lot it only took me like 20 minutes.
Sorry for such a long PR with so many comments and changes. I think this is good to go if you guys think so too.
I changed the way the service behaves in the default mode. The container will not stop when blueiris stops in the normal mode. It will stay up so you can do things like updates or manage the wine environment. It will still stop if you switch to the service mode.
I added a menu for Blue Iris stuff in the right click menu of Fluxbox. You should see it under a main "Blue Iris" menu item in fluxbox. Just right click on the desktop to see it. I included:
If you guys think this is good, I think it should go in the latest dev.
Forgot to mention: Added the curl and jq packages. Helpful for running scripts in container and will probably be useful for integration with the AI triggers.
Also, I removed the cifs-utils package. I don't really think it's needed.
this PR should
close #17 close #28
@leonowski I'll pull the latest of this branch and run it.
@jshridha I think we should consider merging this to dev
soon. I've been running the updates and things have been good. I do have a small concern that it may eventually randomly crash; so it would be good to have it long running without stopping/starting the container.
I'm also currently using the node ai tool and have everything running in docker. It has been working great, compared to just plain old motion detection. I've been working on fine tuning my triggers. Unfortunately my neighbor put a t-shirt over a mail box (long story) and deepstack thinks there's a 85-97% chance it's a person 🤦 (depending on the lighting and different things). I'll likely start to play around with the mqtt part and tie some automations into Home Assistant.
Here's an example docker-compose (I realize this is a bit out of scope):
version: '3.8'
services:
home-assistant:
image: homeassistant/home-assistant
restart: unless-stopped
network_mode: host
volumes:
- ~/home-assistant:/config
devices:
- /dev/ttyACM1:/dev/ttyACM0
blue-iris:
image: leonowski/docker-blueiris:run_as_service
restart: unless-stopped
privileged: true
init: true
environment:
- RESOLUTION=1440x768x24
- TZ=America/Chicago
ports:
- 8080:8080
- 5900:5900
- 81:81
volumes:
- /SURVEILLANCE/blue-iris:/root/prefix:rw
- aiinput:/root/prefix/drive_c/BlueIris/aiinput
command: -c /etc/supervisor/conf.d/supervisord-service.conf
trigger:
image: danecreekphotography/node-deepstackai-trigger:latest
restart: unless-stopped
environment:
- TZ=America/Chicago
secrets:
- triggers
- settings
ports:
- 4242:4242
volumes:
- aiinput:/aiinput
deepstack-ai:
image: deepquestai/deepstack:latest
restart: unless-stopped
environment:
- VISION-DETECTION=True
volumes:
- /SURVEILLANCE/deepstack/datastore:/datastore
secrets:
settings:
file: ./settings.json
triggers:
file: ./triggers.json
volumes:
aiinput:
I've been trying to run leonowski/docker-blueiris:run_as_service on my unraid server with no success. The blueiris.sh fails every time.
Here is the docker command: docker run -d --name='BlueIris5' --net='bridge' --privileged=true -e TZ="America/Denver" -e HOST_OS="Unraid" -e 'TZ'='America/Denver' -e 'RESOLUTION'='1440x768x24' -p '8083:8080/tcp' -p '84:80/tcp' -p '5900:5900/tcp' -v '/mnt/user/appdata/blueiris5/bi/':'/root/prefix':'rw' --init 'leonowski/docker-blueiris:run_as_service'
Here is the log ` 130150K .......... 100% 83.7M=2m40s
2020-09-10 16:21:34 (811 KB/s) - ‘blueiris.exe’ saved [133284136/133284136]
Executing mkdir -p /root 0024:err:environ:run_wineboot boot event wait timed out `
Hi @luck-y13
After it starts, are you able to go to the web interface on port 8083? The blueiris script runs and it looks like something downloads, but there are required dialogs to jump through the GUI. The first thing you should see is an attempt to install wine-mono and wine-gecko. Eventually, the blue iris installer GUI should appear.
Do you get anything in the GUI?
I get this Wine popup saying that /root/prefix is being updated. Then in the log it says that the wine timed out.
I believe the privileged flag should be: --privileged
and not --privileged=true
I removed my data folder and removed the image leonowski/docker-blueiris:run_as_service and tried to start it again, but this time using leonowski/docker-blueiris:latest. This time it had the pop ups for mono and gecko which installed fine and it prompted to install BI which also installed ok.
But now the log has 2020-09-10 17:47:24,120 INFO exited: blueiris (exit status 53; not expected) 2020-09-10 17:47:27,124 INFO spawned: 'blueiris' with pid 939 002b:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 002b:err:module:import_dll Library VCRUNTIME140_1.dll (which is needed by L"C:\Program Files\Blue Iris 5\BlueIris.exe") not found 2020-09-10 17:47:28,170 INFO success: blueiris entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 002b:err:module:import_dll Library mfc140u.dll (which is needed by L"C:\Program Files\Blue Iris 5\BlueIris.exe") not found 002b:err:module:import_dll Library FTD2XX.dll (which is needed by L"C:\Program Files\Blue Iris 5\SeaMAX.dll") not found 002b:err:module:import_dll Library SeaMAX.dll (which is needed by L"C:\Program Files\Blue Iris 5\BlueIris.exe") not found 002b:err:module:LdrInitializeThunk Importing dlls for L"C:\Program Files\Blue Iris 5\BlueIris.exe" failed, status c0000135
I believe the privileged flag should be:
--privileged
and not--privileged=true
I changed it to --privileged
and no difference.
I just tried this in unraid as well (I haven't really tried it on there, but I'm actually a very early user of Unraid so I had one running so I could try it).
I had to make sure the persistent directory was clear for the first launch and then use --privileged
as an extra parameter in the Advanced view. Then it worked. The final output of the command according to the Unraid GUI was:
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='blueiris' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'TZ'='America/Los Angeles' -p '8080:8080/tcp' -p '81:81/tcp' -p '5901:5900/tcp' -v '/mnt/cache/blueiris-test':'/root/prefix':'rw' --init --privileged 'leonowski/docker-blueiris:run_as_service' 028e511b28023788ba1ce6971d7426469efb01830dca3dd528d060b21164713e
The command finished successfully!
if it still fails, can you post the entire output of docker logs
for the container?
I'm having a problem that I think is probably unrelated to this branch. However I'm curious to know if anyone else experiences this issue. After the video container has been running for a long time I get weird speeding up and slowing down of frames on all of my cameras in Blue Iris (I think I had this same issue on Unifi Video, after that docker container was long running). If I restart the container the problem seems to go away. I'll attach a video showing an example (it wouldn't let me upload a .mp4
, so I put it in a folder and zipped it, since it allows zip).
video.zip
You got it to work on Unraid which gives me hope, but I still can't get it to install with your run_as_service branch. I've deleted my image and re-downloaded it multiple times. My docker run is the same as yours except for the TZ. I go to 8083 and see it saying the wine configuration is being updated, but it just hangs and never brings up the gecko or mono installer.
Here is the log. You'll see after it downloads the blueiris.exe, it tries to launch it with wine, but I guess since it never installed gecko or mono it just hangs.
Is there anything in your wine cache directory in the container? ~/.cache/wine
After it finishes building on dockerhub, give this new one a try. I put in gecko and mono msis into the package.
ok, this newer version seems better at prebaking mono and gecko. hopefully, this fixes the issue.
First off, thanks for this.
I have been trying to get your run_as_service
branch for days. Was trying to figure this out on my own, but keep bumping into the same problem.
running on Unraid with this command:
docker run -d --name='blueiris' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'RESOLUTION'='1440x900x24' -p '8123:8080/tcp' -p '8987:81/tcp' -p '5903:5900/tcp' -v '/mnt/user/appdata/bi5-leonowski/':'/root/prefix':'rw' --log-opt max-size=5m --log-opt max-file=2 --init --privileged 'jh/bi5:leonowski'
have tried creating the local share and chown-ing to nobody:users and also just letting docker create the share specified in the run cmd, but the container fails with multiple messages like it can't find the /root/prefix
such as:
wine: '/root/prefix' is not owned by you
2020-09-12 13:08:43,293 INFO exited: dummy-taskmgr (exit status 1; not expected)
Warning: Failed to open file(/usr/share/fluxbox/nls/C.UTF-8/fluxbox.cat)
...
Executing wine regedit /S C:\windows\Temp\override-dll.reg
regedit: The file 'C:\windows\Temp\override-dll.reg' was not found.
Executing wine64 regedit /S C:\windows\Temp\override-dll.reg
regedit: The file 'C:\windows\Temp\override-dll.reg' was not found.
...
------------------------------------------------------
Note: command wine vc_redist.x86.exe /q returned status 2. Aborting.
------------------------------------------------------
0170:err:module:process_init L"C:\\windows\\system32\\blueiris.exe" not found
rm: cannot remove 'blueiris.exe': No such file or directory
unzip: cannot find or open /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip, /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip.zip or /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip.ZIP.
00b0:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_CACHE_INFORMATION
00b0:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_CACHE_INFORMATION
00b0:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_CACHE_INFORMATION
unzip: cannot find or open /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip, /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip.zip or /root/prefix/drive_c/Program Files/Blue Iris 5/ui3.zip.ZIP.
full pastebin: https://pastebin.com/ym5Z4S7C
any ideas?
So, I've been trying to work out a way to make this run similar to the Windows version of Blue Iris. I'm not sure if this is even a good approach, but a side effect of this effort is that Blue Iris now uses the correct time. The "fix" was to import a windows registry reg file that I used to try and set up the service automagically (along with specifying the correct TZ env var for the container). It does seem to work as there are 2 separate BlueIris.exe processes running. Unfortunately, when I close the GUI process, it seems to also close the service. I'm still working on that.
Because of the way services work in Windows, I thought that it may be possible for the container to run continuously even if it is in a bad state. To try and get around that, I created a small "check_process.sh" script that runs every 30 seconds. If it doesn't find any BlueIris.exe processes, the script will send a kill to PID 1. I disabled automatic restart for the blueiris.sh script in supervisord so that this check_process.sh script can handle this. Since PID 1 is being killed in the container, the container now needs the
--init
option turned on. For docker-compose, the option is documented here .I haven't explored the possibility of the service requiring a Blue Iris license to run. I have also observed, in my testing, the service running without the UI - I just haven't figure it all out yet. I wanted to get this PR in to discuss anyway.
There are also some startup improvements in this:
Visual C++ 2019 runtime is installed quietly before the blueiris.exe installer. There still is a Wine Mono and Wine Gecko installer dialog that requires manual interaction. I'm working to find the best way to get rid of that.
After install, PID 1 will be killed so a fresh restart brings up BlueIris.exe as a service.
Lastly, I'm still having trouble with recordings on the 64-bit version. Can anyone else confirm that it is a problem for them? For me, my Blue Iris will crash when I attempt to record anything. This doesn't seem to happen on the 32-bit version.