Server Version#: 1.18.4.2171
Player Version#: 7.26.0.14578
So I have been making backups of my whole plex install in case something happens (like this) to be able to restore. The other day, I decided to run a integrity check on my database and fix any issues with it. It found some issues and I ran through the repair process and put that database in it’s place. However, I noticed that some of my albums were missing. I could go into the folder on my server and see the MP3 files but when I checked the folders in plex, it said there was nothing in these folders. No real way to scan them again, I tried to copy in the old database back in.
Once I copied over the database, I couldn’t get to my server anymore. I have now done this like 3 times and every time, once I place the new data over there, the server becomes unavailable. I have done this process over and over on my test machine a couple of builds back and it worked like a charm.
Does anyone know if anything has changed in this last build that would prevent me from restoring an older database? This is the WHOLE reason why I am doing this because of my VERY large music collection. I don’t have another 3 weeks to sit here and FIX all the cover art it never pulls in.
I can get any type of logs anyone needs to take a look at this because the WHOLE point of the backup process is to be able to restore when something goes wrong. I can get network logs, regular logs and anything someone would need to take a look at this. I am going to go through the process again and see if I can fix this without having to START from scratch… again!
Are you stopping PMS before you put the DB back? After you stop PMS, also make sure the shm and wal files are properly being removed. If not, remove these before restarting PMS.
Correct, I am stopping the plex server on the nvidia shield in the Plex app. I then copy over just the One or two DB files to the server and start it up again. This seems to have just started happening. I don’t know if there was something with the update or what. I have been working on this for the past 4+ hours to try to get it to work and see what I can come up with.
I create a new database with no libraries and that works just fine and copied that out. I then added one library with like 8 albums and copied that out. I can go from the original one to the new one and back. But as soon as I copy over another database (I have like 6 to choose from all the way back to 11/15 and start the server up. It never wants to connect. I will continue to work on this because it’s still quicker than rebuilding my music library.
If you have any thoughts or would like to look at some logs, just let me know.
It’s possible that the old backups were from a previous version of PMS and some migration isn’t working to update them to match the current version. If you can manually grab the PMS logs after restarting with the old DB, I can check if there is a problem.
Those might have been where the corruption was. When there is corrupt data, the repair procedure basically removes the entire entry so that info is lost.
So, I discovered that I would have folders but Plex did not see anything in them. Any possible way to like force re-scan of that data? Doing a scan and full metadata refresh did not bring those files back into plex.
The whole reason why I copied over a database in the first place is that after I did a repair and everything seemed to be working, I noticed that a couple albums that were sync’ed to my phone were not on the server anymore. I checked the data location and they were still there. I guess there was come corruption on these albums when I did the repair and it removed them like you said. So now, when I went into folders in plex, I could see the folders but it said there was nothing inside of them. I just want to force a re-scan for plex to see those files again.
Maybe I could copy them out of the folder and copy them back in so they get a new date on them for plex to pick them up. However, I got this other issue to deal with.
So I think I finally found a database that should work. I feel like something did change however because I have been doing this for months and never seem to have an issue. For an example, I backed up the database like 4 days ago so this one was working on the system just fine. I then did that repair on it and noticed I was missing some stuff. I should have been able to just go back to my original database from 4 days ago, but it didn’t like it.
Anyway, going to ask another question. Do you happen to know what the blobs.db is for? I mean it gets created and there are some items in there. Is it best to copy over both files or do I just need to one database file and the blobs file get recreated when you do this?
I believe the blob file has to do with EPG data, so this will get recreated as needed.
My guess is that the PMS updated between this time. PMS does a migration to update the DB. This may have revealed the corrupted data that had already existed but did not cause a problem with the previous version of PMS, but the new version doesn’t like it. Have you checked the backup for corruption?
Due to my large database, I think I am always going to have a bit of corruption. Seems like after a bit, it just gets that way. I am not doing beta’s anymore so I was on 2171 for several days before this happened so I would think that database would have been updated already. Some of the databases do have corruption to where building a new file from the Dump file creates a 0K file. I guess when that happens, that database is just broke. I am hoping once I copy over this metadata (2.5 hours), I will be back up and running!
I saw in your last log that the migration was not done. It’s also possible PMS had tried but failed so the changes never stuck.
Keep in mind that the DB might not actually be corrupted. It could just be bad data which can have similar symptoms. You can try manually checking some of your tables to look for bad data and just manually removing those fields instead of the entire line. I found this is most often caused by bad dates, so checking those fields would be a starting point.
