mi5key

That all looks normal, same as mine. Is this a first time setup?

No, I just put the VERSION in the /mnt/user/appdata/Xeoma/xeoma.config and it works just fine. But coppit will have to update the image with the correct URL for the automatic updates to come in. # The version to use. Valid values are a string like '17.5.5', 'latest', 'latest_beta', or a URL. #VERSION='latest' VERSION='20.11.30'

Anyone else having issues starting this docker? *** Running /etc/my_init.d/40_install_xeoma.py... 2020-12-15 20:56:48 Determining version of Xeoma to use 2020-12-15 20:56:48 Config version is "latest" 2020-12-15 20:56:48 Fetching version information from Felenasoft at http://felenasoft.com/xeoma/downloads/version3.xml Traceback (most recent call last): File "/etc/my_init.d/40_install_xeoma.py", line 182, in <module> version_number, download_url, alternate_download_url = resolve_download_info() File "/etc/my_init.d/40_install_xeoma.py", line 70, in resolve_download_info version_number, download_url, alternate_download_url = latest_version() File "/etc/my_init.d/40_install_xeoma.py", line 38, in latest_version e = xml.etree.ElementTree.ElementTree(file=urllib.request.urlopen(VERSION_URL)).getroot() File "/usr/lib/python3.6/urllib/request.py", line 223, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.6/urllib/request.py", line 532, in open response = meth(req, response) File "/usr/lib/python3.6/urllib/request.py", line 642, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python3.6/urllib/request.py", line 570, in error return self._call_chain(*args) File "/usr/lib/python3.6/urllib/request.py", line 504, in _call_chain result = func(*args) File "/usr/lib/python3.6/urllib/request.py", line 650, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 404: Not Found *** /etc/my_init.d/40_install_xeoma.py failed with status 1 *** Killing all processes... Dec 15 20:56:49 5f32b2e3a36b syslog-ng[13]: syslog-ng shutting down; version='3.13.2'

Recommendations from Storj support to change the -v to --mount. Any idea how to do this in Unraid/CA? "-v ‘/mnt/user/appdata/StorjNode-V3/identity/’:’/app/identity’:‘rw’ -v ‘/mnt/user/appdata/StorjNode-V3/share/’:’/app/config’:‘rw’" Please, replace to --mount asap: https://documentation.storj.io/setup/cli/storage-node#running-the-storage-node https://documentation.storj.io/resources/faq/how-do-i-change-my-parameters-such-as-payout-address-allotted-storage-space-and-bandwidth

Just set up tdarr yesterday, loving the control that it gives me as opposed to something like Unmanic. I have it pointed at my movies folder using Handbrake, and have pinned four cores to the container. Right now, the ETA is about 16 hours @ 20% complete. The ETA bounces around between 14-18 hours. I just copied this same file to my Handbrake container watch folder, and the ETA is ~8 hours with .31% complete. Also four separate cores pinned to the container. Using the same preset: H.265 MKV 1080p30. Per the logs the ETA is steady, doesn't change much, except to decrease normally as it processes. Wondering why the discrepancy between the two? I really want to like tdarr for the control it gives. I'm confident I'm doing something wrong, just don't know what yet.

I added a second network cable yesterday, assigned an IP address, unraid made it the default route and that's when the problems started. Both NICs have outbound access to the gateway/dns, but when unraid made the second NIC the default, that's when the problems started. I disabled the second NIC, manually added a default route via the first NIC, re-enabled the second NIC and now everything is working as normal. Likely not a bug in unraid, just changing the default route to the newest added NIC appears to be the issue.

Running 6.8.0 since released, this problem just popped up for me today. All Docker containers say "update ready", updating manually does nothing. Pulls 0 bytes, just reloads the container. So, not fixed in 6.8. I'm just now going through this whole thread.

Alright then, testing with default.

@limetech I followed this advice. Should I set to something else?

Updated to rc4, been on it for about 5 hours, no corruption. Set "mdcmd set md_restrict 2" Will stress it more later.

@limetech I disabled the bonding since I only have one network cable at the moment anyhow. Messages have disappeared. Anything else I can try to assist? I have time today to try other scenarios.

In this case the mv command doesn't copy, just changes location pointer. From the command line, here is what I did.. 1) CLI: mv /mnt/user/stuff/tv/Star\ Trek\ Deep\ Space\ Nine /mnt/user/stuff/holding/ 2) Plex GUI: Scan library files in Plex 3) CLI: less /mnt/user/appdata/PlexMediaServer/Library/Application\ Support/Plex\ Media\ Server/Logs/Plex\ Media\ Server.log - observed no corruption 4) CLI: mv /mnt/user/stuff/holding/Star\ Trek\ Deep\ Space\ Nine /mnt/user/stuff/tv 5) Plex GUI: Initiated scan, Plex picked up the change and is processing files. 6) CLI: cp -rv /mnt/user/stuff/tv/Star\ Trek\ Deep\ Space\ Nine /mnt/user/stuff/tmp/ 7) CLI: less /mnt/user/appdata/PlexMediaServer/Library/Application\ Support/Plex\ Media\ Server/Logs/Plex\ Media\ Server.log - observed corruption within 1 minute.

After moving the directory of TV episodes back to the TV watch folder, I started to copy those same exact files to another location... /mnt/user/stuff/tv/Star Trek DS9 --> /mnt/user/stuff/holding So, while Plex was scanning those files, they were being copied.

Upgraded to 6.8.0-rc3 two days ago. During normal use, Plex scans periodically, a couple of movies were added, no corruption on linuxserver/Plex or binhex/Sonarr during that time. Tunable(scheduler) = none I just moved a 60G directory of tv episodes out of the TV directory, Plex rescanned, no corruption. I moved that 60G tv show back to the tv watch folder, Plex starts scanning, and started a copy of large files in another window, near immediate corruption. Diag attached. r410-diagnostics-20191020-1654.zip

Back to daily corruption, so back to 6.6.7.

Just had a Plex corruption. Edit: and Sonarr is now corrupted r410-diagnostics-20190924-1810.zip

6 days for me, no corruption on 6.7.3-rc3

I've moved back to 6.6.7 today because I was dealing with regular corruption. Limetech's near silence on the matter is troubling too.

Yeah, I haven't seen any movement from Limetech on this in quite a bit. I may be downgrading also.

I backup my Plex database nightly via cron because of this corruption issue. I have my auto update Library turned off and corruptions are rare, but this is a super duper workaround. I'd much rather have it auto scan, but until Limetech can fix this, this is how I roll. Sonarr corrupts more frequently due to the way it runs. docker stop Plex cd /mnt/user/appdata/PlexMediaServer/ tar zcf /mnt/user/appdata/PlexMediaServer/backups/Library_`date +%m-%d-%Y_%H%M`.tar.gz ./Library docker start Plex Same with Sonarr docker stop binhex-sonarr cd /mnt/user/appdata/binhex-sonarr tar zcf /mnt/user/appdata/binhex-sonarr/Backups/cron-based/sonarrdb_`date +%m-%d-%Y_%H%M`.tar.gz config.xml nzbdrone.db nzbdrone.db-journal docker start binhex-sonarr Then I have a cron sweep both locations for any backups more ten 10 days old. find /mnt/user/appdata/PlexMediaServer/backups -mtime +9 -type f -delete

r410-diagnostics-20190730-0703.zipLoaded 6.7.3-rc2 today around 5pm. By 11pm, Plex database is corrupted. I am a new unraid user, installed 6.7.2 to fresh hardware. Saw corruption from the beginning. I changed from /mnt/user to /mnt/diskX/ and corruption still occured on 6.7.2.

Unraid 6.7.2 I am having issues gaining external access to a Xeoma docker container in unraid. I am able to use the ios app when I am on Wifi and hit the container directly via the ip/port and I can see the cameras. But when I try to hit my external IP addr on the router, it will not make a connection. I can see the traffic via tcpdump... 09:48:39.649610 IP MY.EXT.IP.ADDR.64568 > 192.168.1.5.8090: Flags , seq 1887646583, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 652724141 ecr 0,sackOK,eol], length 0 0x0000: 4500 0040 0000 4000 4006 ce46 ac5b fe68 E..@..@[email protected].[.h 0x0010: c0a8 0105 fc38 1f9a 7083 3377 0000 0000 .....8..p.3w.... 0x0020: b002 ffff 1c28 0000 0204 05b4 0103 0306 .....(.......... 0x0030: 0101 080a 26e7 c7ad 0000 0000 0402 0000 ....&........... 09:48:39.650387 IP MY.EXT.IP.ADDR.64568 > 192.168.1.5.8090: Flags , seq 1887646583, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 652724141 ecr 0,sackOK,eol], length 0 0x0000: 4500 0040 0000 4000 3f06 cf46 ac5b fe68 E..@..@.?..F.[.h 0x0010: c0a8 0105 fc38 1f9a 7083 3377 0000 0000 .....8..p.3w.... 0x0020: b002 ffff 1c28 0000 0204 05b4 0103 0306 .....(.......... 0x0030: 0101 080a 26e7 c7ad 0000 0000 0402 0000 ....&........... Repeating these blocks of attempts until failure. I'm at a loss here. I've looked at the Docker iptables config and it looks ok, but not 100% sure. Do I have to explicitly allow my external IP? Mike