BNoyes1

oh, yea, when it didn't work I turned mover back off for appdata & system and restarted docker so Plex would work again. I tried again here, and same thing, still lists disk5 for some share files/folders. I will note that I ran mover with logging on and it printed '<filename> file exists' many times over. chopper-diagnostics-20260304-2205.zip

tried it a few times, but it continues to say that some files are on disk5. chopper-diagnostics-20260304-2001.zip

dvr_pool3 failed SMART, so I swapped it out and I am waiting for the drive to preclear & and the pool to resilver, although I don't think that'd cause the DB corruption. Additionally, someone on reddit recommended changing the Plex container's '/config' path to "/mnt/cache/appdata/plex" instead of "/mnt/user/appdata/plex". Something about the appdata share listing "Exclusive Access" as 'No'.

Database is corrupted again even after switching to the Linuxserver Plex container. I do see BTRFS errors in the log for sdd1 (and sdb1 on the same lines?) both are part of the dvr_pool. In another thread it says to run "btrfs dev stats" and that returns all 0s: root@Chopper:/mnt# btrfs dev stats /mnt/dvr_pool [/dev/sdd1].write_io_errs 0 [/dev/sdd1].read_io_errs 0 [/dev/sdd1].flush_io_errs 0 [/dev/sdd1].corruption_errs 0 [/dev/sdd1].generation_errs 0 [/dev/sdf1].write_io_errs 0 [/dev/sdf1].read_io_errs 0 [/dev/sdf1].flush_io_errs 0 [/dev/sdf1].corruption_errs 0 [/dev/sdf1].generation_errs 0 [/dev/sdb1].write_io_errs 0 [/dev/sdb1].read_io_errs 0 [/dev/sdb1].flush_io_errs 0 [/dev/sdb1].corruption_errs 0 [/dev/sdb1].generation_errs 0 [/dev/sde1].write_io_errs 0 [/dev/sde1].read_io_errs 0 [/dev/sde1].flush_io_errs 0 [/dev/sde1].corruption_errs 0 [/dev/sde1].generation_errs 0 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs 0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0Is this related to the DB corruption? It is completely separate pool from the NVMe cache that contains the DB. chopper-diagnostics-20260302-2001.zip

OK, I'm gonna try a different Plex container. I read several recommendations for the binhex-plexpass back when I set it up but it looks like more people actually use the Linuxserver.io Plex container, so I tried to migrate to that one using the guide here: https://www.reddit.com/r/unRAID/comments/1kbh0d2/how_to_migrate_from_binhexplex_to_plex_from/ but what I ended up with was 2 identically named servers on my Plex account; One that was offline/inaccessible, and one with no media 🤦‍♂️. I guess I'll try again tomorrow.

Database is corrupted again, Jan 19, 2026 19:19:53.364 [22692467936056] ERROR - [Req#3af8a2] SQLITE3:0x80000001, 11, statement aborts at 10: [SELECT (SELECT max(idx) FROM 'main'.'fts4_metadata_titles_icu_segdir' WHERE level = ?) + 1] database disk image is malformed Only thing 'concerning' I see in the logs is php-fpm[10850]: [WARNING] [pool www] server reached max_children setting (50), consider raising it a few times over. and this just popped up recently: Jan 19 19:36:20 Chopper kernel: block nvme0n1: the capability attribute has been deprecated. Jan 19 19:36:20 Chopper kernel: mpt3sas 0000:05:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM Note: I changed the name of the server to "Chopper" when I replaced the USB/Updated UNRAID chopper-diagnostics-20260119-1936.zip

OK, I ran a single pass of MemTest and there were no errors, so I replaced the flash drive, moved my license, updated Unraid, and repaired the database. Hopefully that is the source of the DB corruption.

It was a user on the Plex forums that said If you need that speed it would be better to place it on dedicated NVMe storage. I have my docker appdata/config setup on the NVMe cache pool. I used to have the secondary storage set as the array because I wanted a 'backup' incase the NVMe drives failed but when I started having db issues, I turned that off and have the secondary set as none, but that didn't seem to help the issue. I will note that the binhex-plexpass folder in the appdata share lists 'Cache', 'Disk3', 'Disk4', 'Disk5', & 'Disk6' under Location even with secondary storage turned off. logs are attached. Thanks unraid-diagnostics-20251231-1030.zip

So this database corruption is occurring about every 2 weeks, I need to solve this. Those on the Plex forums seem to be blaming the Unraid Cache. I’m sure their is plenty of glowing testimony in the UNRAID forums for placing Plex on the cache disk but unless special care is taken with regard to the db files this will happen. I do have my Plex data files on a cache of 2 NVMe drives with the idea that this would be fast and reliable for loading metadata and artwork from. The database is already trying to cache data and putting an abstraction layer between it and its files (including the -shm and -wal ) is likely to lead to your condition. If you need that speed it would be better to place it on dedicated NVMe storage. Is there a way to use a 'dedicated NVMe' in Unraid? It seems like my options are the array or a cache, but I've been using Unraid for less than a year so there's much I don't know. Any way to prevent it or do I just need to ditch Unraid?

I tried to scrub that pool, not sure how to interpret these results, but now sdg is spun down and will not spin back up. UUID: 337e481b-5b2d-4830-855b-2324b53c31cb Scrub started: Thu Nov 20 07:20:08 2025 Status: finished Duration: 6:27:49 Total to scrub: 1.31TiB Rate: 58.96MiB/s Error summary: read=175727184 super=3 Corrected: 175597814 Uncorrectable: 129370 Unverified: 0I pulled the disk and I'm running a Hard Disk Sentinel test on it now. I suspect the drive has failed, and at 77536 POH, I don't suppose it owes me anything. All that being said, this disk is part of my NVR pool so should be unrelated to Plex. but Thanks for catching that, Not sure why there was nothing shown on the UNRAID web UI.

So I've been having this issue every couple weeks where the Plex database is getting corrupted. DVR recordings don't show up and they are shown in the DVR schedule with "An Unknown Error Occurred", but the recordings are present in the DVR pool. The Plex logs give database errors such as: SQLITE3:0x80000001, 779, statement aborts at 12: [DELETE FROM 'main'.'fts4_metadata_titles_icu_segdir' WHERE level = ?] database disk image is malformed Following the SpaceInvaderOne Video, I can fix the corruption, at least temporarily, but it re-corrupts a few weeks or even days later. I see several threads about corruption occurring in UNRAID docker containers, and a few have instructions/scripts for repairing the corruption, but I haven't found any that address the underlying problem. What is causing the corruption, & how can the corruption be prevented in the first place? I asked on the Plex forums and they seem to want to blame the UNRAID cache (where the docker appdata and therefore the database is stored). Is this not the best place for the docker appdata? My understanding was it was best to place this on fast storage to speed up library navigation. Thanks unraid-diagnostics-20251119-2234.zip