Closed leonowski closed 3 years ago
Just realized you have this on docker hub. Tried again with that image in case there was something wrong with my local build from your git branch.
Current docker run cmd:
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 'leonowski/docker-blueiris:run_as_service'
almost the same results unfortunately:
This time I didn't VNC into the container until the logs stopped scrolling. Was greeted with this screen:
pastebin: https://pastebin.com/YcdULADZ
It does look like some permissions issue. I tried to run this on a mac with Docker Desktop and I'm running in to the same problem. It seems like wine tries to link serial ports of the host machine in ~./wine/dosdevices at some point. I believe this fails and so everything else fails. On the mac, I was able to get around this by using a named volume just for the prefix directory like this:
somevolume:/root/prefix
As opposed to mapping a volume to a path like this:
$(pwd)/some_place:/root/prefix
As a test, can you try creating a new volume and using that instead of a path? I'm not sure how to do that through the unraid GUI, but you can do it through the command line like above. If you specify a volume name that doesn't exists yet, it should create it (or, you can make one before you start with docker volume create some_volume_name
ok, trying again with this after creating a volume:
docker run -d --name='blueiris2' --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' --log-opt max-size=5m --log-opt max-file=2 --init --privileged --mount source=bi5,target=/root/system 'leonowski/docker-blueiris:run_as_service'
This does allow me to proceed to the BI install. It installs and then shuts down the container after completion as planned.
However upon restart and removing --privileged
I get a bunch of explorer errors
012c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
012c:err:winediag:nodrv_CreateWindow The explorer process failed to start.
012c:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
2020-09-12 17:31:31,856 INFO spawned: 'dummy-taskmgr' with pid 934
012c:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
012c:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
also, is NoVNC working for you guys? long list of errors in the pastebin starting with this:
WebSocket server settings:
- Listen on :8080
- Web server. Web root: /root/novnc
- No SSL/TLS support (no cert file)
- proxying from :8080 to localhost:5900
Failed to read: session.ignoreBorder
Setting default value
Failed to read: session.forcePseudoTransparenc
Not trying to create work for you if you've got it working. Was just trying to move my install to docker after accidentally borking my win10 VM ;)
full pastebin: https://pastebin.com/krd2R4bz
No worries. This is all interesting to me. It may take some time to figure out as I'm relatively "new" to wine. I'm sure it has to do with running things as root. I'm looking into not having to do that now.
@johnny2678
I just noticed in the run you pasted this volume:
--mount source=bi5,target=/root/system
Did you mean the target to be /root/prefix
instead?
OMG... 🥴 that's embarrassing.
Still no NoVNC
But over VNC the install completed and the console came up after the container restarted. Need to spend some more time with this but I think I've taken enough of your Saturday ;) sorry.
ok, i think this should work for you @johnny2678 . You can run it without privileged mode now. But, you must create the prefix path first on the host machien and set it to 777 so the container can write to it. Or, if you used a named volume, that isn't required.
Another note:
Now that this doesn't run as root, the default port for the blueiris web server can not use port 81. So, in the GUI, you must set it to something higher than 1024. You can still map it to anything you want through docker though like -p 81:1081
Thanks for you working with us on this @leonowski! I really appreciate your time. I tried the home/wineuser update and dropped the --privileged flag. I am using a local path to a directory that I chown 777 on. I even created a subdirectory within that folder that I also chown 777'd.
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='BlueIris5-run-as-service' --net='bridge' -e TZ="America/Denver" -e HOST_OS="Unraid" -p '8083:8080/tcp' -p '84:80/tcp' -p '5901:5900/tcp' -v '/mnt/user/blueiris_install/data/':'/home/wineuser/prefix':'rw' --init --log-opt max-size=5m --log-opt max-file=2 'leonowski/docker-blueiris:run_as_service'
Now I get no popups on the vnc, not even taskmanager and the log says
2020-09-13 13:10:15,787 INFO spawned: 'dummy-taskmgr' with pid 49 wine: '/home/wineuser/prefix' is not owned by you 2020-09-13 13:10:15,795 INFO exited: dummy-taskmgr (exit status 1; not expected) --2020-09-13 13:10:17-- https://blueirissoftware.com/blueiris.exe Resolving blueirissoftware.com (blueirissoftware.com)... 64.20.60.68 Connecting to blueirissoftware.com (blueirissoftware.com)|64.20.60.68|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 133284136 (127M) [application/octet-stream] Saving to: ‘blueiris.exe’
Here is what the permissions show inside the docker container:
Here is what the permissions show outside the container. The data folder which is mapped to prefix was created and owned by root:root, but it gets changed to 1000:1000 by the dockerfile. I'm guessing this is because the user and group wineuser:wineuser doesn't exist outside the docker container context?
It seems like a big problem was with the way wine was being initialized. winetricks ran during the build and I think that throws a wrench in things. This new image now does no wine operations during build.
So, on first launch now, it will create the fresh wine prefix environment for you using the winetricks annihilate
command to start off. On unraid, you should still create the folder first if your using a volume mapping. You should not need to set 777, but you can chown using the UID like this:
chown -R 1000:1000 /your/path
Invoke it through docker: -v /your_path:/home/wineuser/prefix
The consequence of this is the initial startup is now longer as it will download vc runtime 2019, mfc42, corefonts, and wininet. When it's all done, it should eventually give you the Blue Iris installer.
I had to remove the taskmanager task as it blocked other components from installing on the first run. If you need to run it to take a look at things, you can still do it through the shell. I add it as a right click menu item in fluxbox later.
Hopefully, this works. I tested it on my unraid. I forgot to mention: We still need privileged mode on the first run. I put that back in the readme.
@leonowski I pulled the latest, deleted my container, and ran the latest. My setup is now broken.
When I remove the command that tells it to run as a service, things start up, it downloads Blue Iris even know I already have it installed, then does a few other things. Eventually I get a Blue Iris install screen in the VNC. I walk through that, it asks me for my License Key even know it was previously configured, I enter it and hit "Next", then Blue Iris stops running for some reason.
I was looking through the updates to the readme and I think the issue might be related to wineuser
, I haven't ran any chmod
's. I'll give that a shot.
I tried running a chmod 777
from my host, on my volume mounted directory. Unfortunately I get the same result as above, it doesn't seem to find my Blue Iris install and configuration.
For now I cloned down you repo and then checked out a specific commit, built that, and am running on it just fine. https://github.com/leonowski/docker-blueiris/commit/3ae19b7c0f2e85044f478b0fd44cbbb5e24bfb18
Any idea what I need to do to run on the latest?
Hi @TonyBrobston
The big change is this container no longer runs as root. The problem is, you ran the old version which ran as root. Wine does not allow you to use the wine prefix unless the user owns the prefix.
The other big change is the prefix is now located at /home/wineuser/prefix
So, to fix the problem, first change the owner of your persistent store on the host to ID 1000 like this:
chown -R 1000:1000 /path/to/your/data
Then, change your docker-compose yml to point from the old /root/prefix
path to /home/wineuser/prefix
path
@leonowski That fixed the issue.
I did have one other issue I struggled with for a bit. When using a volume like in my docker-compose above:
volumes:
aiinput:
aiinput
got created by root
user at some point. So I think wineuser
was not able to write to that folder as a result, breaking my ai trigger stuff. I was able to chown -R 1000:1000 /aiinput
(from inside one of the container, I had to exec
into it with something like docker exec -it --user root <container id> /bin/bash
to be root user) which fixed the issue. I'm not sure if this folder gets created by root
by default (through docker-compose) or if it was created by root
because I previously ran as root
when using Blue Iris. Since aiinput
is essentially mapped from one container (blue-iris
) to the other (trigger
), that aiinput
folder really doesn't end up on the host machine, which made this whole situation confusing.
@jshridha Any update on merging this to dev? I've been working off of this branch for awhile now and things have been great.
@leonowski Are you finding this to be stable also? If so I'll merge.
From working 32 bit jshridha/blueiris and danecreekphotography/node-deepstackai-trigger images, to being stuck on a 64 bit broken setup...
For reference, my portainer (docker-compose) being as follows:
blueiris:
image: leonowski/docker-blueiris:run_as_service
privileged: true
?? init: true <- Unsupported config option for blueiris service: 'init'
container_name: blueiris
environment:
- PUID=1000
- PGID=1000
- RESOLUTION=1920x900x24
- TZ=Australia/Sydney
volumes:
# chown -R 1000:1000 /cam **
- /cam:/home/wineuser/prefix:rw
- /cam/tmp:/tmp
ports:
- 8055:8080
- 5900:5900
# due to wineuser <- port > 1024
- 8056:81
# command: -c /etc/supervisor/conf.d/supervisord-service.conf
logging:
options:
max-size: "5m"
max-file: "2"
restart: unless-stopped
I've started numerous times from scratch, yet lady luck is not smiling upon me. My burning questions being:
The required persistent data store is thus now:
What is the su or root password as to elevate wineuser(1000) ?
Is the config option --init still required with the initial setup ?
I can't get a web connection to host:81 although the BlueIris webserver is enabled and set to port 81 (172.0.0.5:81) of which the port is exposed. Under Web Server > Advanced > "Use secure session keys and login page" and "Auto-ban IP after attempts" are both unchecked. Running the script "get_latest_ui3.sh" brings no progress.
$netstat -tulpan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 228/x11vnc
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 24/python
tcp 0 0 127.0.0.1:5900 127.0.0.1:60604 ESTABLISHED 228/x11vnc
tcp 0 0 127.0.0.1:60604 127.0.0.1:5900 ESTABLISHED 229/python
tcp 0 0 172.17.0.4:8080 172.17.0.1:59500 ESTABLISHED 229/python
tcp6 0 0 :::5900 :::* LISTEN 228/x11vnc
What am I missing to get the webserver going ... ?
@Viksie For reference, here is my latest docker-compose. This has been working great for me for a few weeks:
version: '3.8'
services:
blue-iris:
image: leonowski/docker-blueiris:run_as_service
restart: unless-stopped
# privileged: true
init: true
environment:
- RESOLUTION=1440x768x24
- TZ=America/Chicago
ports:
# - 8082:8080
- 8081:8081
volumes:
- /SURVEILLANCE/blue-iris:/home/wineuser/prefix:rw
- aiinput:/home/wineuser/prefix/drive_c/BlueIris/aiinput
command: -c /etc/supervisor/conf.d/supervisord-service.conf
trigger:
image: danecreekphotography/node-deepstackai-trigger
restart: unless-stopped
environment:
- TZ=America/Chicago
secrets:
- triggers
- settings
ports:
- 4242:4242
volumes:
- aiinput:/aiinput
deepstack-ai:
image: deepquestai/deepstack
restart: unless-stopped
environment:
- VISION-DETECTION=True
volumes:
- /SURVEILLANCE/deepstack/datastore:/datastore
secrets:
settings:
file: ./settings.json
triggers:
file: ./triggers.json
volumes:
aiinput:
I ran into issues with using port 81 inside and outside the container, so I switched that to 8081 and also had to change that setting in Blue Iris' webserver. Also I believe timezone has been working for me, but I can double check.
Here are some screenshots of my webserver settings:
Hopefully seeing a working docker-compose will clear up some of your issues. @leonowski may be able to weigh in more on some of your questions. I'm not using portainer, so I'm no help there.
Thanks @TonyBrobston. Re-reading the entire thread also helped getting it to work again.
However, I'm still seeing a difference in the time displayed within the console and UI3 interface. Clips in the console is displayed UTC+0 whereas clips in UI3 is displayed with localtime.
And even worse ... upon a restart of BI, ALL clips are being deleted, be they .bvr or .mp4, "Combine or cut video each" disabled or not. Once Bi has started up, the deleted clips are still reflected by empty placeholders in the clips section, until cleared by a DB repair.
I've noticed that the files (or entire folder) are being deleted just before the splash-screen of BI is displayed on startup. Which has me ponder if it's not related to a script ...
@Viksie I did a docker restart
on my container and I still have video files from weeks ago and am still able to play them. I also went into the Blue Iris program and shut it down, I had issues using the menu to start Blue Iris (right click > Applications > I tried the first two options I believe). I then did another restart on the docker container and all my video files are still there and playable. I also did a Blue Iris software update, which worked perfectly.
I'm not sure I'll be much help on the rest. Sorry 🤷 .
It actually clears the entire folder. Be it a container restart or the app itself from the console.
Even when I created a new folder "aiclips", it does the same on this new folder. I don't see anything in the logs and is flabbergasted by the "behavior".
One thing it is, is being consistent on my system. I recall reading a thread may moons ago when some else had this issue and I scoffed at the notion ...
I'm still having trouble with Bl getting installed on my volume in unraid. I've made all the changes suggested and created a volume that I chown 1000:1000. The c_drive in the prefix ends up with a windows folder, but it doesn't create the user folders when the installer for BlueIris downloads and tries to run. I was wondering if it might be the access type for the path in docker. I have tried rw, rw-slave, rw-shared. Doesn't seem to make a difference. In the end the I still get
Log
`130100K .......... .......... .......... .......... .......... 99% 1.02M 0s 130150K .......... .......... .......... .......... .......... 99% 37.4M 0s 130200K 100% 30.8M=92s
2020-10-05 09:56:48 (1.38 MB/s) - ‘blueiris.exe’ saved [133325776/133325776]
002c:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Application Data".
002c:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser".
002c:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Local Settings\Application Data".
0024:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0040:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\My Documents".
0040:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Desktop".
0040:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0040:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0040:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0024:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Local Settings\Temporary Internet Files".
0024:err:wininet:cache_containers_init Couldn't get path for default container 0 0024:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Local Settings\History".
0024:err:wininet:cache_containers_init Couldn't get path for default container 1 0024:err:shell:SHGetFolderPathAndSubDirW Failed to create directory L"C:\users\wineuser\Cookies".
0024:err:wininet:cache_containers_init Couldn't get path for default container 2 Failed to read: session.screen0.titlebar.left
Setting default value Failed to read: session.screen0.titlebar.right
Setting default value`
Having updated to version 5.3.3.4, the disappearing clips seems resolved automatically.
@Viksie Good to hear!
I'm merging this PR. Thanks to EVERYONE for all the hard work and wonderful contributions. Especially thanks to @leonowski for the PR and @TonyBrobston for providing invaluable testing/debugging.
Builds should hit docker hub soon.
A year later and we're back on this topic.
With BlueIris now supporting Deepstack, you can easily send a AI alert image directly to Telegram with cURL.
The macros' values can be validated on a Windows instance with an Alert Action of "msg * /time:15 ALERT_PATH=&ALERT_PATH, ALERT_DB=&ALERT_DB, CAM=&CAM".
The resulting cURL parameter (on a Windows instance) to generate the above being:
https://api.telegram.org/botXXXX/sendPhoto -F chat_id=XXXX -F caption="[&CAM](&WAN/alerts/&ALERT_DB?fulljpeg) [UI3](&WAN/ui3.htm?rec=&ALERT_DB&maximize=1) - &MEMO" -F parse_mode=MarkdownV2 -F photo=@"C:\BlueIris\Alerts\&ALERT_PATH"
The first hyperlink showing the image and the second taking you directly to the action in a live playback via the web browser (UI3) interface.
With the Linux cURL the image seems to be delivered much faster than with Windows.
Yet, on the docker image, I cannot type the parameter (as amended) as the "(" and ")" characters does not generate.
"https://api.telegram.org/botXXXX/sendPhoto -F chat_id=XXXX -F caption="[&CAM](&WAN/alerts/&ALERT_DB?fulljpeg) [UI3](&WAN/ui3.htm?rec=&ALERT_DB&maximize=1) - &MEMO" -F parse_mode=MarkdownV2 -F photo=@"/home/wineuser/prefix/drive_c/Blue Iris/Alerts/&ALERT_PATH""
Neither can the text be copied over the browser. The " ( " and " ) " characters can be typed within a shell though. The only half baked "work-around" is to echo it into a file, but then it only creates more issues in trying to validate new issues....
So I hope @leonowski @jshridha @TonyBrobston @luck-y13 and @johnny2678 are all keen in resolving the "(" and ")" not generating.
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.