bokchoy

Is it possible to to output to a different directory using recordings-transcoder instead of in-place conversion?

I don't have PTZ cameras, but do have a couple varifocal and zooming does work through Xeoma (just tested). Nearly all of my camera configurations like zoom, rotation, text overlay, network settings, picture quality settings, I set using my camera's UI as well. Once I set those settings I rarely change them. As for why PTZ isn't working in your case you should contact the developer and explain your issue with your specific camera model. As for your connection issue, it might be your camera configuration module or client settings. For example, if you choose to buffer and transcode the archive on your server rather than the client your server hardware needs to be powerful enough to handle that. I opt not to buffer the stream so I get near real-time data and decode it on the computer I'm watching the stream from and use the GPU to handle the decoding so I don't get any connection issues. Xeoma is a great choice for many people to balance resource utilization, licensing cost, features, and UX (user experience). Of course that is just my opinion, but I hope this helps others who are trying to determine which surveillance software to use. I've tried most of them and settled on Xeoma. I tried using this docker awhile ago, but just ended up using a vm for it and it's been rock solid.

What are you trying to do in Xeoma that has led you to think it's terrible? I've used Xeoma for years and continue to do so because the developer is responsive to emails, bugs I've brought up get patched usually in the next version, chaining modules gives you a lot of control over specific workflows, and Xeoma is relatively light on hardware resources compared to others. Combining node-red with Xeoma has given me even more flexibility to set up complex workflows that can't be done using Xeoma only. For instance one of the workflows I have is integrating Xeoma with Slack: - Xeoma: During specific hours - Xeoma: When a motion event is triggered - Xeoma: Create an archive (only way to get an mp4) - Xeoma: Send an http request to node-red - Node-red: Get the mp4 file - Node-red: Upload mp4 to Slack channel (when I have time to include presence detection this workflow will be updated to query HA for presence prior to uploading to Slack)

Hey hopefully someone can help! Background: I accidentally hit a drive carrier and popped a drive out of the array while working on another server. After pushing it back in my drive array was showing the drive as disabled so I stopped the array > detached the drive > restarted array > stopped array > then attached the drive to the array and restarted to do a rebuild. Once completed, I am experiencing the following issues: 1. I only have one vm and was passing through an Nvidia M2000 gpu that WAS WORKING great until after the rebuild. I read up on so many forum topics attempting to get this working again and most are the same issues dealing with iommu groups and syslinux config. That is not my issue. When starting the vm I don't get any error messages, however, the os (debian) fails to load. Using vnc instead of gpu works fine. I also tested creating another vm from a template using gpu passthrough with the M2000 and it works without issue. 2. Unstable ssh sessions. Prior to the rebuild I had zero issues with ssh sessions. After the rebuild I continuously get dropped sporadically. Also, during the session I experience 2-3 sec of lag occasionally while typing. Of note, if I use the built-in terminal session on the webui I have zero issues. 3. Servers connecting to file shares over nfs are constantly having issues now that worked flawlessly before. Constantly seeing "nfs: server 10.0.3.2 not responding, still trying" and very slow response when changing or listing mounted directories. I've attached an export of my logs. Thank! store-diagnostics-20181008-1619.zip

I used this docker for awhile, but eventually moved it onto a vm. I saw these errors in both. I had to take Xeoma down temporarily while I move servers, but will check when I get the vm up and running again. FWIW I was running the latest beta/stable (they're both the same right now, 17.11.24) Edit: Despite seeing those errors I've not had any problems running 5 Dahua ip cams (2x 5MP, H.265 and 3x 3MP H.264) except when using the smart codec. The latest version says it fixed the smart codec issue, but I still have problems with it "not skipping" (aka not recording) about every 3-5 min for some duration like 5 sec. Archival works as it should, replaying archived footage works as expected. I don't see my surveillance archive ballooning so it is managing the size of the archives.

Just wanted to jump in and say thanks once again @coppit for all your work getting this working. I've been running since April with no issues on 17.3.30. Just upgraded to 17.5.5 and running fine!

Also running docker 1.12.6 When I get time either later tonight or this weekend I plan on comparing the xeoma files that were installed in the VM vs he files installed in the docker config and seeing if I can see any differences or seeing if Xeoma is writing logs somewhere. @coppit Is it possible for you to modify your docker vars to set it up at another location on the i.e. /config <-> /mnt/cache/appdata/Xeoma2, /archive <-> /mnt/disks/<disk>/xeoma2-archive. and try connecting? Curious if you may have manually copied files/updated configurations once Xeoma was running in the container that's allowing Xeoma to respond to requests.

Didn't return anything.

Didn't work from my iPhone.

Verified Xeoma works when I run it in a VM and connect remotely from MacBook pro. Same computer I was using before. I'll try doing it from my iPhone.

I received this too at one point, but don't recall exactly what I was doing. I do know it's only happened once to me and it was post install of Xeoma. I fixed it by deleting the config directory and starting over.

Yes I am using ip/port/password just as you did in the client. Below is my output: netstat -a -n -p | grep 8090 tcp 0 0 0.0.0.0:8090 0.0.0.0:* LISTEN 31392/docker-proxy Nope. Either you had posted instructions or I read it elsewhere that the free version doesn't allow remote connections. Just doing the trial standard version or beta.

Using host or bridge both have the same issue not finding the server. I'm going to install it on a VM and see if that works. Hope to get the docker working though. As a side note, just having Xeoma client running trying to find a server (without installing) on my MacBook pro is just crushing the battery and making it run super hot. As soon as I quit it operates normally.

Haha yes.

Great job! That fixed it. The container restarts without error. The original problem is still an issue though. The client cannot find the server. Make sure that server part of Xeoma is working on PC with IP address 192.168.20.160:8090 Ignore the different subnet. Just got a new switch and set up new vlans. As a side note I run about 15 other containers and have not had any networking issues with them. I've verified after my network updates I can still access all the containers.

Here is the log when restarting the container *** Killing all processes... *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh... *** Running /etc/my_init.d/50_configure_xeoma.sh... ln: failed to create symbolic link '/usr/local/Xeoma/config': File exists *** /etc/my_init.d/50_configure_xeoma.sh failed with status 1

1 way is to ssh to your server and cd to the mapped volume for the config location you set when you added the Xeoma docker. Then depending on what text editor you use you can edit the xeoma.conf file in the config directory.

@coppit I want to test Xeoma before purchasing an 8-camera standard license for about $100, but I reread your instructions many times over and it was still unclear how the registration gets created in the docker container. You mentioned the registration will exist in the config directory and deleting it will probably require you to contact felonasoft, however, I'm not sure if you register the product from the client or if this registration process has to occur once you've connected to the server from the client. Thanks for the help!

Sorry for the confusion. I followed the instructions and it works fine on the first run (run 1st time, config file created, edit vars, restart, container runs, password set successfully message logged), however, I've received an error message if I restart the container after it has been set up. That error message which unfortunately I haven't captured stated the error was due to the config file existing and then the container stops execution. In additional installation attempts deleting container, deleting config directory, and then running the container for essentially the first time works fine which makes sense since the config directory is empty. Yes, my configuration is very similar 8090/tcp <-> 192.168.0.160:8090 /archive <-> /mnt/user/Surveillance/archive /config <-> /mnt/cache/appdata/Xeoma In the Xeoma client I then click the menu -> Connect to -> Remote server (? Not at home so don't know the exact verbiage), then I enter 192.168.0.160 for server, 8090 for port, and in the password field I enter the password that I used in the env vars. After a short period (15-20 sec maybe?) red text appears above the fields with text that essentially states it can't find it - since I'm not at home I'm not sure exactly what the message is, but that's related to the client, not the server.

Hey thanks for building a docker image for Xeoma! I'm not able to connect to the server. I've tried both bridge/host and have used 16.12.26 x64 MacOS client, 17.3.30 x64 x64 MacOS client, as well as x64 trial Standard. I found I don't get an error saying the config file already exists by deleting the config directory each time and have the docker container recreate it and reset the config vars. I made sure to correlate the beta parameter configuration var with the beta/release packages downloaded. When Xeoma starts I try to connect to the server setting the ip, port, and password, but it never seems to find the server. Any thoughts? I've attached the most recent log. Thanks. xeoma-log.txt