mi5key
-
Posts
24 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by mi5key
-
-
8 hours ago, bonienl said:
TLDR this is fixed in Unraid 6.8 and later
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.
-
2 hours ago, limetech said:
The instructions said to run first without using 'mdcmd set md_restrict'
Alright then, testing with default.
-
16 hours ago, limetech said:
I suggest trying first:
mdcmd set md_restrict 2
If still corruption, let's try:
mdcmd set md_restrict 0
@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.
-
1 hour ago, limetech said:
Oct 20 04:42:21 r410 kernel: br0: topology change detected, propagating Oct 20 04:42:22 r410 kernel: br0: received packet on bond0 with own address as source address (addr:78:2b:cb:63:a3:af, vlan:0) Oct 20 04:42:23 r410 kernel: br0: port 1(bond0) received tcn bpdu
@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.
- 1
-
47 minutes ago, limetech said:
Sorry still confused ... did you do this via command line? If so please show the commands you used. Also when you say "moved" to me that means a 'mv' operation where file by file, each file is copied and then source is deleted - is that what happened.
I think what you're saying is this: there is a directory with a bunch of files in it. While Plex is scanning that directory you also initiated a copy (not move) of that same directory to another directory. correct?
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.
-
1 hour ago, limetech said:
Please expand on this - do you mean you started a copy of large files? what is source and destination?
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.
-
Back to daily corruption, so back to 6.6.7.
-
15 hours ago, mi5key said:
6 days for me, no corruption on 6.7.3-rc3
Just had a Plex corruption.
Edit: and Sonarr is now corrupted
-
6 days for me, no corruption on 6.7.3-rc3
-
On 8/25/2019 at 7:00 AM, Rich Minear said:
I had to do the same thing. The corruption was an every day occurrence...and I couldn't keep rebuilding or restoring the databases. Since I have moved to back, I have seen ZERO corruption.
I wanted to help, and tried for a several weeks. But now I'm just anxiously watching to see if anything changes.
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.
-
6 hours ago, dustinr said:
well, sonarr finally corrupted running the latest RC2
* no parity drive
* no cache drive
Sonarr corrupted after about a week. restoring the appdata backup to a few days ago and rolling back to previous unraid, i cant beta test anymore lol
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.
Dockers wanting to update, but don't in the end?
in Stable Releases
Posted
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.