Moving watched status does not work

Server Version#: 1.19.3.2764

Following this guide https://support.plex.tv/articles/201154527-move-viewstate-ratings-from-one-install-to-another/ moving from my old server to a new one does not work anymore. Both running the version above.

After importing the server throw a lot of “ERROR - Soci Exception handled: Cannot convert data to std::tm.” errors.

Looking at the data it seems like the change_at field is different on the old and the newly setup one.

One the old its epoch time, but one the new one its way too high for epoch.

OLD:

NEW:

These instructions are only ever going to work if there haven’t been any playback events on the new server, so you might as well copy the whole DB file to the new server instead.

I tried moving the whole database and files since I started to have program crashes. But that did not help. The database is very old (many, many years) and was destined for a full refresh, so I made a new one. Did something break and I should redo it since the changed_at isn’t epoch or is it fine? Already used weeks rescanning everything so I don’t really what to start again.

So we can assume that the invalid numbers are already present in the source database.

If you know your way around SQL, you might be able to fix these items quick and dirty (but nonetheless effectively) by setting all invalid numbers back to the current, valid epoch date.
Unverified example:
UPDATE metadata_item_settings SET changed_at = '1588872921' WHERE changed_at > '1588872981'

Use the epoch timestamp for “now” first, and add about 60 seconds or so in the WHERE clause.

Don’t try this without having a backup copy of the database file, naturally.

The “invalid” large integers are automatically generated in new database. It looks like an auto increasing integer and not a date field, they are all sequential. The old are “correctly” set to epoch. Importing the epoch ones gave the initial errors. So I updated them all and just set them to one of the large integers. It works okayish. Watched status is set, but no on deck are shown, no errors are shown in the log. Starting one of the previous changed to the same large integer; correctly puts it on deck and makes a new auto increased number. It looks like the underlaying principal for the field is changed in some later versions. I’ll try a new fresh install for testing tomorrow to see what that puts in this field.

Tested a new install on windows 10 Pro 64bit.
Plex server version 1.19.3.2764-ef515a800
Added a single library with one movie file during setup dialog.
Played that one file.
Here is the result:

This should be easily reproducable.
Looks like they changed the fundamentals on this field.

I was told this column doesn’t store an epoch timedate but an increasing integer value.

Are you by chance using the 3rd-party “plexAPI” software library?

I was using Tautulli on the old server.
On the new one I was trying to import the watched status to nothing was connected.

Did another test server. Same spec as before.
Clean install, go thru the inital setup, added one library containing one movie.
Shutdown the server
Imported the watched status from the previous test server

INSERT INTO “main”.“metadata_item_settings” (“id”, “account_id”, “guid”, “rating”, “view_offset”, “view_count”, “last_viewed_at”, “created_at”, “updated_at”, “skip_count”, “last_skipped_at”, “changed_at”, “extra_data”, “last_rated_at”) VALUES (‘1’, ‘1’, ‘com.plexapp.agents.imdb://tt0133093?lang=en’, ‘’, ‘2810000’, ‘0’, ‘2020-05-08 09:24:06’, ‘2020-05-08 09:23:56’, ‘2020-05-08 09:24:06’, ‘0’, ‘’, ‘22’, ‘’, ‘’);

That broke the server.
Line 633: May 08, 2020 13:09:56.103 [19108] ERROR - Exception fetching query for hub: sort=addedAt:desc (Cannot convert data to std::tm.)
Line 636: May 08, 2020 13:09:56.104 [19108] ERROR - Exception fetching query for hub: sort=viewUpdatedAt:desc&viewOffset>=300&viewUpdatedAt>=1579259396 (Cannot convert data to std::tm.)

Plex Media Server.log (767.1 KB)

That error indicates it’s the updated_at field, not the changed_at field causing the problem. Sort that column in order and look at the beginning and ending and check for any entries that do not look like a date.

As per the SQL statment above my test only have one record with updated_at = 2020-05-08 09:24:06

Where did you get that command for “Insert Into”? Was that from the export or did you generate that yourself?

I was able to reproduce the problem, the problem was not “updated_at” or “changed_at”.

The problems are actually “last_skipped_at” and “last_rated_at”.

In your statement, you used '' where there is no value. This is a blank field instead of a null. PMS does not like blank fields for any dates, nulls are fine. Change your '' to null and the errors should go away.

I’m not sure what happened with your original attempt. Just curious, did you follow the guide exactly by exporting and importing the data or did you generate your own query?

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