bokchoy

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

+1. I also want the docker allocations to display all templates with an indicator whether the container is running or not. I have several containers that I only run occasionally, but normally have them off. When I'm assigning an ip to a docker I review the list of docker allocations within whichever subnet it's going to be in, but I then also have to consider which ip's are associated to stopped containers, otherwise when I start one of the stopped containers I get an error relating to the ip.

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 also had this issue with the LSI 9207-8i controller taking painfully long to post which led me to this thread. Additionally, I was experiencing slower IO speeds on my 4TB WD Red drives and updating the firmware and bios resolved that as well. My 9207 came with: MPT2BIOS 7.37.00.00 Firmware 19.00.00.00 IT NVDATA 14.00.00.00 @Switchblade got me in the right direction, but didn't provide any instructions on how to accomplish this. Additionally, there are a few articles that explain this process, but were super old and I wasn't sure if it would work. The article I followed that worked for me was here, but in case it isn't available later I'll summarize here: ** Note: It's recommended to upgrade the same versions of the bios and firmware. The versions are in the file names preceded by P (ie P20) 1. Go to the download page for the 9207-8i here 2. Under BIOS download the file: UEFI_BSD_Pxx 3. Under Firmware download the files: Installer_Pxx_for_UEFI and 9207-8i_Package_Pxx_IR_IT_Firmware_BIOS_for_MSDOS_Windows 4. Get a USB drive formatted as FAT32 4. Extract the files. 5. In UEFI_BSD_Pxx, copy the BIOS for the updater (x64sas2.rom) to the root of the USB 6. In Installer_Pxx_for_UEFI, copy the firmware updater (sas2flash.efi) to the root of the USB 7. In 9207-8i_Package_Pxx_IR_IT_Firmware_BIOS_for_MSDOS_Windows, copy the firmware 9207-8.bin to the root of the USB 8. Boot (or reboot) server to UEFI shell 9. Change to the correct partition, mine was fs0 so in the command line I just typed: fs0 10. Optionally, you can see all installed LSI controllers with the bios and firmware versions. Helpful if you have multiple controllers installed. sas2flash.efi -listall 11. Update the bios and firmware in the same command. The -c flag specifies the controller to flash if you have more than 1 you can specify which by listing the controllers in the above step and specifying in the command sas2flash.efi -c 0 -b x64sas2.rom -f 9207-8.bin 12. Double check the flash worked. On my first attempt I did see the console output showing the flash was successful, however, it was not updated. sas2flash.efi -listall You should see that the bios and firmware are updated. 13. Reboot

Seems it's the same as mine. No. To be honest I think it's an issue with the nic, possibly a bad firmware flash previously? In the bios it's identified in the pci device list, but I attempted to update the firmware using the SPP 2017.10.1 along with the post-production SPP Gen8.1 and neither identified device updates for the 375T. I manually reviewed the rpm packages and release notes and did find a firmware update for the 375T. I also tried an older firmware version 5.6.3 by adding it to the rpm packages which was recognized in HP SUM, however, still no dice. Last thing I did was manually unpack the rpm and install without HP SUM. I got an error message related to not finding a device or something. It was late at that point and I gave up after hours of trial/error. Unfortunately, the only time the 375T is recognized is the bios pci list and when I broke out of the HP SUM to get to a terminal to list the devices. It's not listed an interface so I can't check the firmware version. There are many posts/articles that discuss issues with this card so it's possible this is just another issue. I'm going to keep it around and do additional testing, but in the meantime I bought another 4 port nic with an intel controller which should work ootb. Thanks for your help! If I eventually get the 375T working I'll try to remember to update this topic in the event someone else runs into anything similar.

Also, I expanded my search beyond this forum to see if there were any issues related to the controller. Came across this HP advisory. I've got a recent spp update from 10/2017 that may have the updated firmware - won't know till later when I can check. I updated my firmware/drivers before adding the nic so hopefully this update fixes the issue. Just out of curiosity do you know what firmware version is on your nic ( ethtool -i <interface>)? IOMMU group 13: [4040:0100] 02:00.0 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42) [4040:0100] 02:00.1 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42) [4040:0100] 02:00.2 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42) [4040:0100] 02:00.3 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)

Nice. You didn't have to configure anything besides upgrading to 6.4? I'm using them as 1Gbps ports. I contacted @limetech after reading all forum posts related to NC375 and not having any luck with unRaid 6.4 recognizing the interfaces. Sent them my diagnostic logs as well. This was their response: So I figured I'd see if you had it resolved first since it's the same controller before starting a new topic.

Did this ever get resolved for you? I recently acquired an HP NC375T 4-port nic with the same controller. In my case the "netxen_nic" driver is loaded so it appears the driver was added, however, I am still unable to use the nic since none of the interfaces show up in the network configuration.

If I use br0 for all dockers I have no issues loading the containers on the docker tab and the docker container image loads. When I add another interface eth2 which is on a different subnet then the view for the docker tab takes about 10-15 seconds to load. Below are my network settings and the missing images. Once the list of containers finally loads there are no images. Networking settings:

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!