mdeabreu

Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

mdeabreu's Achievements

Noob

Noob (1/14)

1

Reputation

  1. I was having this same issue, unable to open the history page, user page, etc. You can roll back to that last version that worked pretty easily by changing the docker image pulled. In my case I'm using v2.1.44-ls35 which seems to be in a good state.
  2. I've been running rc4 since it came out and things were stable but unfortunately I got corruption this evening in both my Radarr and Sonarr containers.
  3. Ah, crystal clear. Thank you for clearing up my misunderstanding!
  4. Sorry I was unclear, the appdata share points to the array (say disk1 only); the containers themselves point directly to /mnt/cache/appdata instead of /mnt/user/appdata or /mnt/disk1/appdata Then, if I understand correctly, the containers will write directly to /mnt/cache/appdata which will be in RAM; then the mover should grab the RAM only contents and move them back into the array.
  5. Does this mean that even without a physical cache disk I could set my docker containers to /mnt/cache/appdata and then periodically run the mover to get the appdata out of ram and into the array? Could this be a potential solution for those of us without physical cache disks? (fully understanding that power loss means data loss)
  6. Unfortunately, the Plex database got corruption while trying to rebuild the Radarr and Sonarr databases. I decided to revert to 6.6.7. I will keep an eye on this thread in case there is any more testing that I might be able to help with. Fingers crossed we can get to the root of this soon.
  7. Got corruption again, this time in Sonarr, Radarr, and OpenVPN-AS. As has been mentioned it seems to occur during periods of high disk activity. I believe Sonarr was importing some media while Plex was streaming/transcoding. At this point I'm very tempted to revert to 6.6.7 as it was rock stable. Are there any other tests we can do to help resolve this? tower-diagnostics-20190818-1657.zip
  8. Despite downgrading to 6.6.7 the upgrade to -rc1 was painless. All containers/vms started successfully. I'll throw some stress tests at the system tomorrow and otherwise keep my fingers crossed.
  9. Looks like I cursed myself, got corruption for both Sonarr and Radarr despite using /mnt/disk1/appdata for the docker images. Attached are some diagnostics. Someone was streaming on Plex, there were some downloads, and Radarr was putting new media into place at which point there was the corruption. Edit: Unfortunately I’ve had to downgrade to 6.6.7, I was getting corruptions while attempting to rebuild the Radarr database and got frustrated. I hope we can see a software fix for this soon but in the mean time I’ll be sticking with 6.6.7 which seems to be stable for now. I’ll be watching this thread and happy to answer any questions about my setup if it’ll help with this issue. tower-diagnostics-20190722-0049.zip
  10. I'm unable to use a cache drive as well but I was able to switch over to using disk1 and so far I've not had any more corruption. I used UnBalance to move the appdata folder to disk1, updated the share to only include disk1, and finally rebuilt all the containers to use /mnt/disk1/appdata and so far things have been stable. It's only been a couple of days but fingers crossed.
  11. Got hit by a triple whammy and had Radarr, Sonarr, and Ombi all get their databases corrupted yesterday. Everything was fine in the afternoon but by the evening they were all dead. They were using the same mounting as mentioned in my previous message (/mnt/user/appdata/{sonarr|radarr|ombi}). The appdata share is split at the top level so the entire sonarr|radarr|ombi would be self contained on a single disk. I decided to complete remake the containers and their associated config folders however this time I am mounting directly using a disk share. So now the config folders are /mnt/disk1/appdata/{sonarr|radarr|ombi}. If I get any corruption with this configuration I'll capture diagnostics again and upload here. Side questions: 1. Using one of the disk mounts (ie /mnt/disk1/appdata/sonarr) instead of a user mount (/mnt/user/appdata/sonarr), is that data still protected by the parity disk? 2. Is it ok to access those folders using an SMB share via windows? (the appdata share is available over SMB, is it safe to access the appdata/sonarr folder if the container has mounted /mnt/disk1/appdata/sonarr)
  12. `appdata/plex` is indeed solely on disk2. I recovered the database from backups and attempted to re-add the media (believing rapid db access to be related) however it was able to successfully add the media without issue.
  13. Thanks for looking into this. I've been bitten by it a couple of times now. Upgraded to 6.7.2 recently and things were running fine. I tried adding some media to Plex and it corrupted the database. Mounted using /mnt/user/appdata Diagnostics attached. tower-diagnostics-20190628-1658.zip