Version 1.27.0.5849 - kills Media server

I’m wondering if this is a general problem with 1.27.0.5849 or if the error only occurs rarely?

Has anyone heard of working updates from 1.26.2.5797 to 1.27.0.5849 in Windows?

It isn’t. It merely highlights an existing damage of the database.
There are database schema changes necessary for the new version to work.
A database which is already defective cannot be converted and thus won’t work at all with the new server version.

1 Like

ok, thx for the explanation @OttoKerner

can you please help to fix my database?

what I’ve done so far:

  • 1.27.0.5849 installed via web gui
  • Received “something went wrong” error
  • 1.27.0.5849 uninstalled via Windows uninstaller
  • 1.26.2.5797 installed → Library was available again
  • Checked for corruption with “C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe” com.plexapp.plugins.library.db “PRAGMA integrity_check” → result: “database disk image is malformed”
  • tried to repair the database with “C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe” com.plexapp.plugins.library.db “.output recover.out” “.recover”
  • checked again with PRAGMA integrity_check → result was still “database disk image is malformed”
  • Did a database optimization (in web gui “Settings → Troubleshooting → Optimize database”)
  • checked again with PRAGMA integrity_check → result is now “ok”
  • installed 1.27.0.5849 again but still got the “something went wrong” error
  • so uninstalled 1.27.0.5849 and installed 1.26.2.5797 again.

Do you have any ideas what else to try?
Many Thanks :slight_smile:

Perform the “manual” repair procedure which is detailed a bit further down the linked article.
Perfrom the repair also on the older backup database files and see if one of them is able to be converted.

If the conversion fails on all 4 of them, there is unfortunately nothing that can be done. You’ll have to remove the database completely and start over.

I too started having this issue this morning. I believe I upgraded a couple days ago.

I tried uninstalling 5849 and installing the previous version. This didn’t help as it wouldn’t load my library in PMS (running on Windows server 2019). I then reinstalled 5849 again and everything seems to be working properly.

Curious if this is happening with just large libraries (80+ TB), or if people with just small libraries are having this issue as well?

Also is there anything in common here with the database issues between everyone that’s posted?

I haven’t had any issues with this server since I set it up in 2019.

Fingers crossed it’ll stay happy from now on.

A number of issues can cause database corruption, improper computer reboots, anti-virus interference, backup tools, or about a dozen other known sources. The biggest thing is to check and correct the database issues if fixable. Sometimes though the database cannot be fixed, and needs re-created.

Same issue here after upgrading on DSM 7.1. Tried a number of things, only fix ultimately was uninstalling 1.27 and reinstalling 1.26.2 so far…

did you do a pragma check?

What fixed mine was a downgrade back 1.26, manual repair of the database and then upgrade to 1.27.

@OttoKerner

The Attempt to Repair… instructions here are incomplete and currently do nothing!

.recover does not modify the original DB file. The instructions as-written have no effect.

As with .dump, .recover emits SQL statements that must be subsequently .read.

This text is all incorrect:

Please note that this will output a lot of information to your screen. You can speed up the process by passing the output to a file instead of the screen. You can remove the “.output recover.out” portion if you really want to look at the lines of SQL statements. Please note that the contents of the output will look similar to the output from the .dump command mentioned further below, but it is not the same. DO NOT use this output file for any other reason. You may delete the output file once the recovery is done.

Updated commands:

"C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe" com.plexapp.plugins.library.db ".output recover.sql" ".recover"

del com.plexapp.plugins.library.db

"C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe" com.plexapp.plugins.library.db ".read recover.sql"

# Show count of lost_and_found rows:
"C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe" com.plexapp.plugins.library.db "SELECT count() FROM lost_and_found"

# Optionally delete lost_and_found table:
# "C:\Program Files (x86)\Plex\Plex Media Server\Plex SQLite.exe" com.plexapp.plugins.library.db "DROP TABLE lost_and_found"

My smelly opinion:

When a DB file is corrupt, .dump tends to fail with “ROLLBACK; – due to errors”. Although the output can be edited, .dump is intended to produce backups of good files, not perform data recovery on damaged files. .dump may work if only indexes are damaged, but it isn’t superior to .recover.

If the .recover instructions are corrected, the Manually Repair … instructions using .dump can be removed from the document, simplifying it.

@Volts
Good information - thanks.

Unfortunately too late for me, because after all the tips from OttoKerner didn’t work, I decided to recreate the media libraries. Unfortunately a lot of work if you want them to be beautiful :confused:

1 Like

One caution on using the .recover.

Depending on how many tables were corrupted or how many times the .recover command has been run against the corrupteded database their could be multiple numbered lost_and_found tables bloating the overall size.

In Linux it is easy enough to pipe the .dump command to sed to auto remove the rollback and commit ie:

/usr/lib/plexmediaserver/Plex\ SQLite com.plexapp.plugins.library.db ".dump" | sed -e 's|^ROLLBACK;\( -- due to errors\)*$|COMMIT;|g' |  /usr/lib/plexmediaserver/Plex\ SQLite com.plexapp.plugins.library.db.dump
1 Like

That’s why I included DROP TABLE lost_and_found.

But any form of recovery is meatball surgery, sending the soldier and their amputated leg back out on the field to keep fighting.

When a database is structurally corrupt that means something bad has happened. Even if some good data can be extracted, it should be assumed to be incomplete or have referential issues.

The right choice is to restore from a good backup.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.