Jump to content

mi5key

Members
  • Posts

    24
  • Joined

  • Last visited

Report Comments posted by mi5key

  1. 22 minutes ago, Squid said:

    Probably a network glitch or some other transient event.  With 6.8.0, if unRaid can't communicate with dockerHub, it does show update available.  Try again later

    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.

  2. 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.

  3. 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.

    • Like 1
  4. 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.

  5. 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.

  6. 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

  7. 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.

  8. 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

     

    tower-diagnostics-20190824-1805.zip 97.47 kB · 1 download

     

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

  9. 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

×
×
  • Create New...