Database corruption issues on a database only a couple of days old

General Discussions
1

On November 7th, about a week ago, I completely deleted the Plex directory and started from scratch due to database corruption issues. Today I went through the logs and found many of the same errors that prompted the original database recreation where showing up in the logs mere days after it was newly created.

There have been no shutdowns, no power outages, no anything that I can think of that would corrupt a database. I’ve also manually optimized the database at several times and I have enabled scheduled tasks to “Optimize database every week”.

I created a Perl script to go through the logs and consolidate each type of message collapsing each as much as possible by substituting in generic # for numbers, etc. I then sorted them by the number of times they appeared. Also attached the original logs.

What is happening that could be causing the database issues to repeat immediately after re-creating the database?

Format:
[Number of Occurrences]: Log item with # substituted for numbers to collapse the entries

INFO

[295]: SQLITE#:#x#, #, statement aborts at #: [select * from metadata_items limit #] database schema has changed

WARN

[7080]: Range could not be satisfied # - # (total size=#)
[114]: NAT: PMP, got an error: Not Supported by gateway.
[28]: SLOW QUERY: It took #.# ms to retrieve # items.
[9]: Sync: local sync directory /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sync+ does not exist
[6]: PubSub: Received notifyConnectivity event with incorrect async identifier (#, expected #)
[3]: Unable to load episode file [seasons/#/episodes/#.xml]
[2]: Held transaction for too long (…/Library/FullTextSearch.cpp:#): #.# seconds
[1]: Held transaction for too long (…/Library/DatabaseFixups.cpp:#): #.# seconds
]1]: Held transaction for too long (…/Library/MetadataItem.cpp:#): #.# seconds

ERROR

[69]: [Transcoder] [mpeg#video @ #] Invalid frame dimensions #x#.
[22]: Unable to find title for item of type #
[19]: [Transcoder] [mpeg#video @ #] # motion_type at # #
[13]: Error issuing curl_easy_perform(handle): #
[11]: Throttle: timed out trying to read chunk #
[4]: IVA: Error downloading trailers for source #.
[3]: SQLITE#:#x#, #, duplicate column name: originally_available_at
[3]: SQLITE#:#x#, #, duplicate column name: grandparent_guid
[2]: [Transcoder] [mpeg#video @ #] ac-tex damaged at # #
[2]: [Transcoder] [mpeg#video @ #] mb incr damaged
[2]: HTTP # downloading url https://meta.plex.tv/t/theater?language=en&subtitleLanguage=en&redband=#
[2]: HTTP # downloading url https://meta.plex.tv/t/video?language=en&subtitleLanguage=en&redband=#
[2]: [Transcoder] [mpeg#video @ #] skip with previntra
[1]: [Transcoder] Error while decoding stream ##:#: Invalid data found when processing input
[1]: [Transcoder] [ac# @ #] frame sync error
[1]: [Transcoder] [ac# @ #] error decoding the audio block
[1]: [Transcoder] [mpeg#video @ #] Warning MVs not available
[1]: [Transcoder] [ac# @ #] bandwidth code = # > #

2

These are the settings I changed when resetting Plex last week. I don’t see anything here that would cause the issues above:

Settings:

Web:
	General
		Automatically Sign In
Server:
	General
		Enable Plex Media Server debug logging:  Disabled
		Update Channel:  Public
	Remote Access:
		Manually specify public port:  32600
	Agents:
		Movies/Shows
			Local Media Assets
	Library:
		Update my library automatically
		Run a partial scan when changes are detected
		Update my library periodically:  daily
		Empty trash automatically after every scan
		Allow media deletion
		Generate video preview thumbnails:  never
		Generate chapter thumbnails:  never
	Network:
		List of IP addresses and networks that are allowed without auth:  192.168.1.0/255.255.255.0
	Transcoder:
		Use hardware acceleration when available:  Enabled
	Languages:
		Automatically select audio and subtitle tracks
		Prefer audio tracks in:  English
		Subtitle mode:  Always enabled
		Prefer subtitles in:  English
	DLNA:
		Disabled
	Scheduled Tasks:
		Backup database every three days:  Enabled
3

@Reed97123 said:
On November 7th, about a week ago, I completely deleted the Plex directory and started from scratch due to database corruption issues. Today I went through the logs and found many of the same errors that prompted the original database recreation where showing up in the logs mere days after it was newly created.

There have been no shutdowns, no power outages, no anything that I can think of that would corrupt a database. I’ve also manually optimized the database at several times and I have enabled scheduled tasks to “Optimize database every week”.

I created a Perl script to go through the logs and consolidate each type of message collapsing each as much as possible by substituting in generic # for numbers, etc. I then sorted them by the number of times they appeared. Also attached the original logs.

What is happening that could be causing the database issues to repeat immediately after re-creating the database?

Format:
[Number of Occurrences]: Log item with # substituted for numbers to collapse the entries

INFO

[295]: SQLITE#:#x#, #, statement aborts at #: [select * from metadata_items limit #] database schema has changed

WARN

[7080]: Range could not be satisfied # - # (total size=#)
[114]: NAT: PMP, got an error: Not Supported by gateway.
[28]: SLOW QUERY: It took #.# ms to retrieve # items.
[9]: Sync: local sync directory /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/Transcode/Sync+ does not exist
[6]: PubSub: Received notifyConnectivity event with incorrect async identifier (#, expected #)
[3]: Unable to load episode file [seasons/#/episodes/#.xml]
[2]: Held transaction for too long (…/Library/FullTextSearch.cpp:#): #.# seconds
[1]: Held transaction for too long (…/Library/DatabaseFixups.cpp:#): #.# seconds
]1]: Held transaction for too long (…/Library/MetadataItem.cpp:#): #.# seconds

ERROR

[69]: [Transcoder] [mpeg#video @ #] Invalid frame dimensions #x#.
[22]: Unable to find title for item of type #
[19]: [Transcoder] [mpeg#video @ #] # motion_type at # #
[13]: Error issuing curl_easy_perform(handle): #
[11]: Throttle: timed out trying to read chunk #
[4]: IVA: Error downloading trailers for source #.
[3]: SQLITE#:#x#, #, duplicate column name: originally_available_at
[3]: SQLITE#:#x#, #, duplicate column name: grandparent_guid
[2]: [Transcoder] [mpeg#video @ #] ac-tex damaged at # #
[2]: [Transcoder] [mpeg#video @ #] mb incr damaged
[2]: HTTP # downloading url https://meta.plex.tv/t/theater?language=en&subtitleLanguage=en&redband=#
[2]: HTTP # downloading url https://meta.plex.tv/t/video?language=en&subtitleLanguage=en&redband=#
[2]: [Transcoder] [mpeg#video @ #] skip with previntra
[1]: [Transcoder] Error while decoding stream ##:#: Invalid data found when processing input
[1]: [Transcoder] [ac# @ #] frame sync error
[1]: [Transcoder] [ac# @ #] error decoding the audio block
[1]: [Transcoder] [mpeg#video @ #] Warning MVs not available
[1]: [Transcoder] [ac# @ #] bandwidth code = # > #

There is no evidence of any database corruption. The database schema messages are normal and arise when database schema is updated

If you have specific issues, please first ensure debug logging is enabled on the server
See https://support.plex.tv/hc/en-us/articles/201643703-Reporting-issues-with-Plex-Media-Server
and when issues arises, take a screenshot and note down time and download the logs
https://support.plex.tv/hc/en-us/articles/200250417-Plex-Media-Server-Log-Files
and raise a separate forum topic for each issue

4

Hi @sa2000. Thanks for responding. I appreciate you assessing the situation, but your analysis is in direct conflict from feedback from @ChuckPA in several other topic posts. His assessment was that these type of messages constituted “serious trouble” and “If allowed to continue, PMS will start failing completely”.

I’ve re-posted a few recent ones that highlight the differing assessments below:

@ChuckPA said:
You have several issues.

I. Database needs optimizing

Here you can see 4 queries were well beyond the time limit. If allowed to continue, PMS will start failing completely.

Nov 05, 2017 21:31:09.840 [0x7f8bcc7ff700] WARN - SLOW QUERY: It took 270.000000 ms to retrieve 24 items.
Nov 05, 2017 21:31:09.876 [0x7f8bd27fd700] WARN - SLOW QUERY: It took 300.000000 ms to retrieve 39 items.
Nov 05, 2017 21:31:11.164 [0x7f8bd27fd700] WARN - SLOW QUERY: It took 260.000000 ms to retrieve 24 items.
Nov 05, 2017 21:31:11.197 [0x7f8bdc7ff700] WARN - SLOW QUERY: It took 310.000000 ms to retrieve 39 items.

II. Apparent database corruption or failed database update when installing new version.

If PMS didn’t complete upgrading the database for the new version, this will happen and is the most likely situation. If the machine had a hard shutdown/power off, this type condition also can occur.

Nov 06, 2017 03:42:11.354 [0x7f8bcc7ff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 06, 2017 03:42:11.362 [0x7f8bcc7ff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 06, 2017 03:42:11.370 [0x7f8bcc7ff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 06, 2017 03:42:11.377 [0x7f8bcc7ff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 06, 2017 03:42:11.490 [0x7f8bcc7ff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed

@ChuckPA said:
Reed,
Please look at Plex Media Server.log lines 976 → 1031. The database is in serious trouble again. Did you build all sections at once without optimizing between sections?

As example:

Jun 07, 2017 09:13:08.081 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 280.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:08.313 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 230.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:12.125 [0x7ffbccbfe700] WARN - SLOW QUERY: It took 250.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:12.368 [0x7ffbccbfe700] WARN - SLOW QUERY: It took 260.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:15.128 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 230.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:15.338 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 220.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:18.525 [0x7ffbccbfe700] WARN - SLOW QUERY: It took 230.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:18.751 [0x7ffbccbfe700] WARN - SLOW QUERY: It took 220.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:22.197 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 210.000000 ms to retrieve 0 items.
Jun 07, 2017 09:13:22.408 [0x7ffbc87fb700] WARN - SLOW QUERY: It took 210.000000 ms to retrieve 0 items.
5

If you have a problem need logs with debug logging enabled covering launch

No problem can be investigated form logs that have debug logging disabled

It does not follow that there is database corruption when you see
INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
In fact this is normal behavior to do with the way Plex Media Server access the database after a schema change to check the connectivity of the 20 database sessions it has. These errors flush out other errors and confirm there is a connection to the database - that is the purpose of this dummy test query

The slow transaction is a potential issue and there is currently a known problem with how tv shows items are selected and work is in progress to optimize how that is done - but without proper debug logs i cannot tell if it is anything to do with that

If the upgrade fails then there would be very specific error messages indicating that the schema update failed / aborted and that is not visible in the logs you provided

6

I’ve already turned on the debugging and I’ll let it collect some data before posting it again.

My end goal is to understand which messages are serious and which are not. I’ve had issues which have rooted back to database corruption many times and so being able to detect this before they get bad is important to me. This seems problematic when two different Plex Team Members are giving divergent opinions as to the severity of the messages. Would it be possible to get some unity in the assessments from Plex?

7

@Reed97123 said:
I’ve already turned on the debugging and I’ll let it collect some data before posting it again.

My end goal is to understand which messages are serious and which are not. I’ve had issues which have rooted back to database corruption many times and so being able to detect this before they get bad is important to me. This seems problematic when two different Plex Team Members are giving divergent opinions as to the severity of the messages. Would it be possible to get some unity in the assessments from Plex?

These warnings INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed were discussed with the development team very recently and they are ok and do not indicate an issue. May be your dialogue with @ChuckPA on this was before that discussion with the development team

As mentioned earlier - one needs context for errors and warnings and without debug logging, there is no context

If there is a problem with the database schema update then the logs covering the launch of Plex Media Server would be needed

8

Attaching logs with debug turned on.

9

@Reed97123 said:
Attaching logs with debug turned on.

There was no database schema changes needed for the main Plex Media Server database and so no warnings on launch. The database schema change - if needs to be done - would be done on first launch of the version introducing the change.

(for the future if logs needed to include launch - make sure you restart the server after you enable debug logging - in the provided logs above, you enabled debug logging in-flight and so there was no debug logging for the launch sequence - not an issue in this case as there was no database schema updates to be done)

The db warnings in the log are to do with the overnight scheduled tasks where the EPG database gets recreated regularly and yes there were warnings but these are expected as the EPG database gets created from a skeleton db template and then the schema is replaced - going through a schema migration which then leads to the warnings when the database sessions are checked for being available through the dummy sql request we discussed

Nov 15, 2017 04:19:26.915 [0x7fb5c87ff700] DEBUG - Butler: Done doing work.
Nov 15, 2017 04:19:26.918 [0x7fb5c67fe700] DEBUG - Opening 5 database sessions to library (tv.plex.providers.epg.onconnect:2), SQLite 3.13.0, threadsafe=1
Nov 15, 2017 04:19:26.918 [0x7fb5c67fe700] DEBUG - Installing Library Database from [/usr/lib/plexmediaserver/Resources/com.plexapp.plugins.library.db] to [/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/tv.plex.providers.epg.onconnect-f8eb83b4-06ae-43bd-a6d7-04881bce5899-loading.db]
Nov 15, 2017 04:19:26.977 [0x7fb5c67fe700] DEBUG - Running migrations.
Nov 15, 2017 04:19:26.978 [0x7fb5c67fe700] DEBUG - Running forward migration 20151111185126.
Nov 15, 2017 04:19:26.979 [0x7fb5c67fe700] DEBUG - Captured session 0.
Nov 15, 2017 04:19:26.979 [0x7fb5c67fe700] DEBUG - Captured session 1.
Nov 15, 2017 04:19:26.979 [0x7fb5c67fe700] DEBUG - Captured session 2.
Nov 15, 2017 04:19:26.979 [0x7fb5c67fe700] DEBUG - Captured session 3.
Nov 15, 2017 04:19:26.979 [0x7fb5c67fe700] DEBUG - Captured session 4.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Completed forward migration 20151111185126.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Running forward migration 20150819235734.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Captured session 0.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Captured session 1.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Captured session 2.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Captured session 3.
Nov 15, 2017 04:19:26.988 [0x7fb5c67fe700] DEBUG - Captured session 4.
Nov 15, 2017 04:19:26.996 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.004 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.012 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.020 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.027 [0x7fb5c67fe700] DEBUG - Completed forward migration 20150819235734.

These are not errors and harmless

So basically logged messages such as INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed do not mean there is an issue

10

That solves the info message.

What should I think about the other roughly 9 warnings and 18 errors listed?

11

@Reed97123 said:
That solves the info message.

What should I think about the other roughly 9 warnings and 18 errors listed?

Looking at the errors - there is one set relating to the database

Nov 15, 2017 04:19:27.214 [0x7fb5c67fe700] ERROR - SQLITE3:0x10, 1, duplicate column name: grandparent_guid
Nov 15, 2017 04:19:27.219 [0x7fb5c67fe700] ERROR - SQLITE3:0x10, 1, duplicate column name: originally_available_at

and this was whilst doing a schema update -

Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Running forward migration 20160616000000.
Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Captured session 0.
Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Captured session 1.
Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Captured session 2.
Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Captured session 3.
Nov 15, 2017 04:19:27.213 [0x7fb5c67fe700] DEBUG - Captured session 4.
Nov 15, 2017 04:19:27.214 [0x7fb5c67fe700] ERROR - SQLITE3:0x10, 1, duplicate column name: grandparent_guid
Nov 15, 2017 04:19:27.219 [0x7fb5c67fe700] ERROR - SQLITE3:0x10, 1, duplicate column name: originally_available_at
Nov 15, 2017 04:19:27.224 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.233 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.242 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.251 [0x7fb5c67fe700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Nov 15, 2017 04:19:27.259 [0x7fb5c67fe700] DEBUG - Completed forward migration 20160616000000.

Basically new columns were going to be added to a table but they were already there - no harm done

There will always be errors / warnings. it does make it more difficult to investigate but that is not meant to be for users and if you have an issue then logs would be checked when you post them

I will deviate a bit from the subject of your forum topic and cover one of the errors - that has nothing to do with the database

Nov 15, 2017 07:43:55.404 [0x7fb5d73f9700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.198 (http://169.254.0.215:8060/)
Nov 15, 2017 07:43:55.405 [0x7fb5d2bff700] DEBUG - HTTP requesting GET http://169.254.0.215:8060/
Nov 15, 2017 07:44:10.427 [0x7fb5d2bff700] ERROR - Error issuing curl_easy_perform(handle): 28
Nov 15, 2017 07:44:10.427 [0x7fb5d2bff700] DEBUG - HTTP simulating 408 after curl timeout

This was a device on the network announced itself through SSDP discovery that it was available on IP 169.254.0.215 and port 8060 - but when Plex Media Server asked the device for the info, it did not respond - not a big deal

12

@sa2000 said:
There will always be errors / warnings. it does make it more difficult to investigate but that is not meant to be for users and if you have an issue then logs would be checked when you post them

If I could be 100% sure that errors in the logs corresponded to real problems, I could easily scan through the log files with a cron job each day. If I found errors, I could stop Plex, copy the last database backup to be the current database, then restart Plex. I’d send myself an e-mail that there was a database problem that was detected and fixed and it would require very little of my time and attention and there’d be a superior Plex usage experience because I wouldn’t have to spend a lot of time debugging myself and then posting to debug the problem. This would also allow me to correlate database corruption with recent events that might have caused the issue.

Right now errors based on database corruption bubble up randomly and at first I don’t even know what their cause is. Maybe it’s a software bug, maybe it’s a database issue, maybe it’s a settings issue. So I have to spend time trying to fix, debug, then ultimately posting about it, get someone’s attention and have them look at the logs to determine the problem. If it is a database issue I don’t know if the issue occurred 2 months ago or 2 weeks ago. I have no idea if I restore a database backup if it has the issue as well. I’d simply have to try each of the databases and hope that I notice which one has the issue. If the issue occurred 2 months ago, I have no idea what the event 2 months ago caused the issue. If I can’t find a backup that doesn’t have the issues I have to start from scratch which is time consuming.

This isn’t theoretical. In the time I’ve been using Plex, I’ve had database corruption issues at least 4 times in recent memory. With the current methodology it is essentially impossible for me to promptly detect and therefore impossible to correlate with events that might have originally caused the problem.

From my perspective it would save your debug time and it would save me a lot of time if the log error messages actually correlated with real errors. Is it actually so difficult to only print an error message if it is a true error? I just can’t wrap my head around why this would be as difficult as you are making it out to be.

13

If the database fails the PRAGMA Integrity check it would not be backed up by scheduled tasks

The backup happens every 3 days.

You can write scripts to look at the backup files and if you spot that it did not happen when expected then you can alert yourself with the type of tools that you are using

This would allow you to catch it within a few hours as scheduled tasks run within a defined window and the backup happens every 3 days. You could run your script at the end of this window and check the dates of the backup files

Is the database on local drive ?

14

That’s an interesting proposal and I considered using something like it, but it has a specific weakness.

While some database issues will cause a PRAGMA Integrity check to fail, not all database issues cause it to fail. For example, in the latest database corruption issue I was experiencing, as part of the debug I ran sqlite on my database and despite being corrupted, it reported that the database passed.

What I had been thinking was running the sqlite check myself in cron and then restoring if it fails. However, based on my past experience I wasn’t sure it would cover 100% of the corruption issues.

15

Also, as a side thought. In the case where I need to re-create the database. It would be fantastic to be able to export/import Plex settings so that I could quickly set everything up the way it was before the corruption. Currently all the Plex settings are part of the database that gets wiped when there are issues. Being able to export them to something like an xml file and then being able to read them back in would speed things up like 10x for database rebuilding.

16

what is the difference between export tables and backing up the database? If the database has data corruptions not detectable by the integrity check then you would be exporting corrupt data

There are tools for exporting

See http://forums.plex.tv/discussion/277427/info-some-powerful-and-useful-third-party-tools-to-help-manage-your-plex-media-server

and there is this tool which has function to export all tables

17

I was envisioning the export to only have settings for Plex, not a dump of media that can be regenerated automatically by Plex.

When the database is reset I need to go in and setup all the libraries, specify the paths for the libraries, click on all the options for each of the libraries, set the numerous settings for the server, re-enter all the TV shows that should be recorded. It’s not a huge amount of information, but it takes most of an hour to get it all entered. This should easily be able to be exported from the DB into something like a human read-able xml file. How would I know that isn’t corrupted? I’d look at it. It shouldn’t be more than a couple of pages.

Then if the database is corrupted and I need to start over. I import my settings and bam, it’s done. Plex has my server settings and the libraries defined and can do the scans to rebuild the stuff it manages.

I looked at each of the items you have listed. Looks like a lot of good development, but I may need to write my own tool, because I didn’t see anything exactly like what I was looking for.

It’s been roughly 7 years since I wrote code to interface with a DB, but I enjoyed it last time, so it could be an interesting side project.

18

The 2nd link I gave you which I said exports db tables - that tool has not been maintained and at the moment it aborts when it picks a virtual table

19

What items are contained in the ‘db tables’?

20

@Reed97123 said:
What items are contained in the ‘db tables’?

What a question

Millions of things and bits of information of the Plex Media Server environment and setup and media

I would not expect a user to want to know. It is a very complex set of interlinked data

You can take a copy of the database and use an sqlite3 browser to browse the tables