Leaderboard

What hostility? I haven't seen any from anyone but yourself. We are hard at work trying to reproduce and resolve this issue, but you seem to think that because we haven't yet, that we're sitting here just twiddling our thumbs. We are not. We have multiple test servers constantly running Plex and injecting new data to it to try and force corruption. Hasn't happened to us once. That leads us to believe that this may be specific to individual setups/hardware, but we haven't figured out why just yet. You have a completely valid method to get back to a working state: roll back to the 6.6.7 release. Otherwise we are continuing to do testing and will provide more for folks to try in this bug report thread as we have ideas to narrow this down. Clearly this issue isn't as widespread as some may think, otherwise I think we'd have an outpouring of users and this thread would be a lot longer than 4 pages at this point. That said, it is a VERY valid concern that we are very focused on resolving, but sometimes things take longer to fix.

After two more corruptions since Sunday, I finally went back to 6.6.7 today. I am very disappointed by the lack of transparency from the UNRAID team. I understand finding/fixing the issue might take time, but at least communicate the current progress and next steps.

The Plex database corrupted twice on my server, and Sonarr at least twice, resulting in many of my hours used resolving the problems. Both were stored in /mnt/user/appdata/. I have moved everything to /mnt/cache/appdata/ by toggling the 'use cache only' setting and so far no database corruptions. I appreciate limetech taking this matter seriously and want to say thanks for an otherwise fantastic 6.7.0 release.

Please refer to this post:

While this may seem argumentative (and I don't mean it to be), but can you confirm this Your post on June 5th says the same thing but the only diagnostics that you've posted recently that I found was from June 9th (https://forums.unraid.net/topic/80680-checking-for-docker-app-updates-spins-forever/?tab=comments#comment-750259) which shows that appdata is stored on cache, disk1, 2, and 3. While this is perfectly valid if you only deleted the plex folder (you did delete it didn't you?), it does *imply* that the possibility exists that the entire plex folder doesn't exist on disk3. And, according to the diagnostics on June 9th, your BIOS version is still from 2015, but numerous updates have been made to it, with the most recent being June 25, 2019. Not saying that this is the issue, but an update would at least hopefully rule that out.

I don't believe that there is any truth to that.

Stop spreading FUD. It does not serve anyone's purpose.

If you have a cache disk and use /mnt/cache for the appdata, you will have no problem updating. Those that have issues got it from 6.7.

I am having the exact same issue. I posted about it here: and here: We don't seem to be the only ones experiencing this problem. As Switch points out, the problem does not occur on UnRaid 6.6.7. So I'm thinking it's most likely a kernel issue. Even when downgrading I still experience the "Failed to wrapper hybrid_drv_video.so" error in the Plex Docker log. However the hardware transcoding DOES seem to be functioning. The "kernel: i915 0000:00:02.0: Resetting vecs0 for hang on vecs0" error which potentially locks up the entire UnRaid system -- if I don't stop the docker fast enough -- does not occur on UnRaid 6.6.7. Specs: M/B: Supermicro - X10SLH-F/X10SLM+-F CPU: Intel® Xeon® CPU E3-1285L v4 @ 3.40GHz

The other thing that makes it hard besides no feedback is that it seems that this issue happens at random. In my case, it could be hours, could be days, maybe even a few weeks. It's hard to grab logs/diags when it happens, cause you never know when it will.

Another day of corruption in the database. Should we be doing anything different? I've posted my diagnostics 2-3 times since this was moved to a bug fix, and I've not heard anything back on any of them. After being called out for not giving correct information in the original posting...and then asked to do the testing on 6.7.2...there has been no response. Here at the diags. I'm trying to be an active contributor...but its getting tough when there is no feedback. Thanksswissarmy-diagnostics-20190710-2354.zip rm

When I checked it I remember it was in the default setting which I believe is "Auto". If you can refresh my memory on what the screen looks like in version 7.x, I can confirm 100% what it was set to.

I can confirm that's happen in TVheadend too, not only in Plex. I think its related with Unraid,l and not with dockers.

As my wife is very fond of saying, I don't pay that much attention Are you running anything like PiHole?

I can attest to this - I forgot that I turned on DirectIO somewhere along the way.. I turned it off, restarted my array and all my docker containers now start properly even with the path set to /mnt/user/appdata. Turn it back on - none of my containers start - DB errors everywhere. Not saying this is necessarily related to db corruption over time issues that users are having - but in my case this is definitely the culprit. Saw this thread from a while ago with people having similar issues:

@limetech I just managed to corrupt my sqllite db's on both Radarr and Sonarr (never checked Plex at the time it happened though). I have always used /mnt/user/appdata for everything, and I do not have any problems. But, in the course of testing something out for another user here, I enabled DirectIO (was previously at auto). With that enabled, the db's immediately crashed. After I noticed the corruption, I reverted DirectIO back to "No", and everything fired up correctly. Hopefully this is a data point you can use in solving this problem. Diagnostics attached which covers everything [v0.2.0.1344] NzbDrone.Core.Datastore.CorruptDatabaseException: Database file: /config/nzbdrone.db is corrupt, restore from backup if available. See: https://github.com/Radarr/Radarr/wiki/FAQ#i-am-getting-an-error-database-disk-image-is-malformed ---> System.Data.SQLite.SQLiteException: disk I/O error disk I/O error EDIT: Should actually clarify that no actual corruption happened. SQLite thought it was corrupted if DirectIO was enabled. With it disabled, everything came back alive with no issues servera-diagnostics-20190629-2304.zip

Quick peek at your diags show your network config is bonkered you have 3 network interfaces with the same IP address and gateway assigned to all of them. In this case, nobody can predict the networking to be functional as the routing table would make no sense. you network config actually declares an eth4/br4 - but that interface doesn't exist. Quick fix. Shut down UnRAID, and pull the USB. Edit file config/network.cfg # Generated settings: IFNAME[0]="eth0" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.1.22" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.1.1" DNS_SERVER1="192.168.1.1" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" MTU[0]="1500" SYSNICS="1" This should be doable in the GUI with the GUI boot mode using the local browser, but I've never used GUI boot mode.

I am on 6.7.1 and db corruption continues. /mnt/user/appdata and /mnt/disk1/appdata have both suffered corruption. I have no cache disk (out of sata ports until my lsi card gets here). xfs no system crash, just running as expected. This happens frequently in Sonarr/Radarr and Plex I will update to 6.7.2 to test. not sure if it's anyway related.. But I'm seeing tons of "Waited one whole second for a busy database." in the plex console. Not sure if it was like this previously during an import of a library. Update: It happened sometime overnight, I had a few movies queued in in Radarr but it appears those completed. It corrupted sometime after. server-diagnostics-20190626-1058.zip

I’m certainly happy you got it working again but it could be the updater failed because it’s on a USB 3.0 port. While, yes, USB 3.0 SHOULD work. Things are never that simple. If you peruse the forums you’ll see lots of people who have USB dismount issues on 3.0 which is usually solved by moving to a 2.0 port. I can’t say for certain that it had a hand in your problem but to discount it out of hand is a bit arrogant and unscientific.

It was worth a try. The kernel doesn’t deal well with XHCI for whatever reason and often times gets unmounted on boot. So it’s always best to use a 2.0 port.

I was not saying that the upgrade process did not appear to complete correctly. I am suggesting that the files did not in fact all get written successfully to the USB stick since the error you mention suggests an error reading from the USB stick.

I suspect the upgraded files were not written successfully to the USB stick. I would recommend downloading the ZIP version of the release from the Limetech site and extracting all the bz* type files over-writing the versions on the flash drive. You can also roll back the update by copying all the files from the ‘previous’ folder on the USB stick back to the root of the USB stick.

Tested with an AMD R9 Nano ( GPU + Audio Passthrough ) and the new Unraid 6.6.2 version. So far everything looks good, but I will test this bug with an AMD RX 56 Nano this weekend.