Upgraded Server - used db backup to restore - missing TV settings?

[ebr 14958]

What Luke said is almost certainly the problem.

 

If your items were put in the system a while ago and those items had a particular ID from a global provider (say, IMDb) but not the other one (TMDb) then the user (watched) data would be stored using the first ID.  Then, when you built a new system, if the IDs found were the opposite (TMDb) then the user data would be tied to it instead.

 

That would explain why it appeared both that our restore and the manual database restore did not work.  They both worked, they just were using different IDs than you have now.

 

The only thing we could do to eliminate this potential problem would be to force all data to be tied to a specific provider's ID (either IMDb or TMDb).  The problem with that is that the system would not work at all if the selected ID was not available.

[gleep52 15]

I understand the ID thing to a degree.  But why does it not affect anyone else IF that were the case - wouldn't it always be hit or miss?  

 

Maybe the IDs should be stored as part of the backup so the user's data ties back to the ID, so it would work every time... no?  The only way I can see this is that there is a terrible "bug" with the backup and restore process or I wouldn't have wasted over a day reinstalling and testing.  

 

Even if you forced everyone to use one source (say IMDb), and then if the value was still null to use the second source (TMDb), that still wouldn't be a 100% accurate way to "restore" a server.  It could still come out wonky if you restore it 10 times in a row, especially over a year or so time frame.  

 

One solid 100% sure way to get the restore right every time, is to backup the IDs (and all the data like my restore did this time - even saved my TV scheduling setup).  I personally don't care if the backups get large since I only keep a few.

 

BUT, if you really think that re-scanning all the libraries and eating up all that precious time is the only way to go - at least implement an ID tagger so that the scanning process can tag the global provider's ID appropriately to match up with the user's restored values.  So for example, saving the ID in the nfo file (or a totally new file), so that when the scanner processes the initial scan, it knows what ID to assign as the value because it was already put there upon original scanning.  That way the IDs would match from the global provider, and the user's backup data.

 

Thoughts?

[gleep52 15]

In the mean time - I'd like to make a simple script that will zip up the emby-server folder and store it on a separate PC.  Is there a command to stop emby?  I'll need to stop the service so I can backup all the files and they aren't locked.  I tried "net stop emby", but apparently it's not a normal system service.  Can I taskkill "MediaBrowser.ServiceApplication", or will that cause problems?  Is a stop-process/wait-process in powershell a better method, or just as dangerous as the taskkill option?

[Luke 37233]

The reason why others may have had more success is because it's possible their metadata already had the full set of provider id's. for instance, whereas in your case, it sounds like you had only one of tvdb/imdb, etc, and the initial scan on the new server filled in the other one. When that happened, that may have ended up changing the user data key for that particular series.

[gleep52 15]

Well, I never made any changes to my providers - so it was the same on both installations - and the problem still exists.  Can't we tie the IDs into the backup one way or another?  I listed two options above, are those not valid options?

[Luke 37233]

We already do save the provider id's into nfo files.

[gleep52 15]

Well if that's the case (and I do save the info and artwork into folders in my library), then how did this whole SNAFU happen?

[gleep52 15]

In my batman vs superman.nfo file I see this:

 

<imdbid>tt2975590</imdbid>

<tmdbid>209112</tmdbid>

 

Is that not the IDs we're talking about?  If the IDs are already there, then how did this happen?

[Luke 37233]

Because most likely the re-scanning process in the new server went and filled in missing metadata that brought in new provider id's. And it's possible that the ones that got filled in happen to be the highest priority id's on which to key the user data.

[ebr 14958]

This will only happen to people with either fairly old metadata or who, at some point in time, changed default settings for the metadata.

 

We already do the things you are suggesting above to make this as resilient as possible - which is why it works for most situations.

[gleep52 15]

Had a thought (wanted to post it so it didn't die of loneliness) - I think we're barking up the wrong tree here.  If the nfo file has the IDs in them already - and rescanning my library didn't fix it - wouldn't that mean the nfo ID values changed then?  Because after I copied the whole emby-server\ folder (minus \system folder) over from my old system - all problems were solved.  So the nfo ID didn't change after library scans, and something in the plugin backup process didn't assign the right IDs to my user's data profile so I think that's why this is all a mute point.  I think there is something else not working.  Server 2016 seems to have some weird quirks with local permissions and I wonder if that has something to do with it... 

 

Now, could I get some help with post #53 please?