Jump to content

ps2sunvalley

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ps2sunvalley

  • Rank
    Member

Recent Profile Visitors

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

  1. It happened to me! (not actually excited) I'm adding a significant amount of media at the moment and I got a server down notification from Tautulli. Sqlite3: Sleeping for 200ms to retry busy DB. terminate called after throwing an instance of 'soci::soci_error' what(): sqlite3_statement_backend::loadOne: database is locked ****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.16.2.1297-4b7ace214/PLEX MEDIA SERVER/4b038dd7-6f17-16f2-6b6beba4-37a6c664.dmp Sqlite3: Sleeping foStarting Plex Media Server. That's what my log on the Plex docker looks like right now I'm not sure what to do with the crash reports from Plex though... Attached is a very current diagnostics from unraid. Also I just restarted the docker and it looks like it is back up and running as normal. unraidserver-diagnostics-20190717-0212.zip
  2. Honestly for me guys, it's come and go on this DB crashing thing. Plex has been working fairly stable from what I can tell (my watching, and other family members with no complaints, same house and remote). But I do see this message in my Plex docker log from time to time: Sqlite3: Sleeping for 200ms to retry busy DB It's not there now, and someone is watching something so frankly, idk wtf is going on.
  3. What if you're like me and when you change directory from /mnt/user to met/cache Plex gets caught in an infinite crash loop?
  4. Okay so my Plex docker is finally throwing this message up in its logs like 1000 times. The container appears to be working (I can browse and play media right now, for the moment) Sqlite3: Sleeping for 200ms to retry busy DB. Attached is diagnostics, currently on 6.7.2 unraidserver-diagnostics-20190705-2330.zip
  5. Is anyone else having issues changing the mapping to the appdata? I've been using /mnt/user/appdata/PlexMediaServer/ for 1.5 years. If I try to only change the mapping in the docker config to /mnt/cache/appdata/PlexMediaServer/ I get this error on an infinite loop: ****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.16.2.1297-4b7ace214/PLEX MEDIA SERVER/55e3a89d-90b5-b4b2-3afbf75b-4e9ba94f.dmp Starting Plex Media Server. terminate called after throwing an instance of 'std::runtime_error' And then when I change the directory back to /mnt/user/appdata/PlexMediaServer/ everything returns to normal, and eventually I may get an SQLite error (haven't seen it in a few days now). I'm on 6.7.2 right now.
  6. Just for my info, what are the main symptoms of a corrupt database and how can one confirm that their database is corrupt?
  7. But that would allow things to still run while the app data is in /mnt/user/appdata/PlexMediaServer/ but then get caught in a crash loop when I only change the directory in the docker template to /mnt/cache/appdata/PlexMediaServer/ ? Here is what the specific entry in the docker log looks like when I do that ****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.16.2.1297-4b7ace214/PLEX MEDIA SERVER/55e3a89d-90b5-b4b2-3afbf75b-4e9ba94f.dmp Starting Plex Media Server. terminate called after throwing an instance of 'std::runtime_error' And then when I change the directory back to /mnt/user/appdata/PlexMediaServer/ everything returns to normal, and then randomly the DB will start giving that SQLite error.
  8. I tried that, and in the logs when the container restarted it just gets caught in a crash loop.
  9. Running this docker currently on 6.7.0 I've been having recent issues with Plex recognizing that new files have been added to the library. I have Plex set to "Scan my Library Automatically" but this has become hit or miss over the last week or so, and now it seems broken as I have had to force a library scan the last couple of days in order to get content added. I have even changed my setting for "Library scan interval" from daily (at night when the maintenance tasks run) to every 15 minutes, and that seems to be broken. Today I look in the Plex docker logs and I find a bunch of this: Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Sqlite3: Sleeping for 200ms to retry busy DB. Is this causing the problem? Is this related to the apparent issues with 6.7.x?
  10. That seemed to work just fine. No more warning messages
  11. I'm not mistaken. I set up this rig in early January and IIRC, 6.4.0 was released only a couple days after I installed the previous version. Either way, here is the diagnostics unraidserver-diagnostics-20180309-2207.zip
  12. I've had unraid 6.0 installed for about 2 months now, recently I checked the log and I see this persistent warning Screen Shot 2018-03-09 at 9.34.19 PM by gcarterrogers, on Flickr The system is built with a super micro X8DTL-iF with 2 Xeon E5620, 8 GB ram. Does anyone have any idea what could cause this warning? The system seems to work fine despite the warning, but I would like to know if it will lead to future problems.