Can not change "Originally Available" date for a Movie: Part Deux; Now Stuck at "1900" (PMS 5762)

[WillL]

I just updated to PMS beta 1.26.1.5762 to address the recent issue of manually set Originally Available dates not saving. The dates now save properly on the Edit screen, but display as year “1900” in my Library. Anyone else seeing this?

Server Version#: 1.26.1.5762
Player Version#:

[dane22]

Unlock the the date and save
Then go back and set the desired data

[Volts]

It still seems wonky to me, @dane22.

It looks like a reasonable epoch time is written to the database, but then it’s displaying wrong.

Not sure I quite understand what’s going on.

[Volts]

When you edit Originally Available, originally_available_at is now being set correctly.

However, metadata_items.year is set to 1900.

That’s what’s displayed in the Library view when browsing.

[dane22]

I just found out via testing

And no idea if this is how it’s supposed to work or not, so simply wanted to provide a work around

[Volts]

I don’t think that workaround addresses the described issue?

Any manually saved Originally Available date results in 1900 being saved to metadata_items.year, AFAICT.

I think it’s only cosmetic, .year is never used for anything but display?

[Volts]

I’m not suggesting anybody should do this, because I haven’t really tested the edges very well.

UPDATE metadata_items SET year = 
STRFTIME('%Y',originally_available_at,'unixepoch') WHERE year <> 
STRFTIME('%Y',originally_available_at,'unixepoch') AND metadata_type IN (1); 

[Volts]

@dane22 I haven’t confirmed this myself, but it sure smells like a closely related issue -

Can’t update album release date: “Your changes could not be saved.”

Server Version#: 1.26.1.5762 Player Version#: 1.43.4.2971-aa2133cc It looks like this topic was brought up before but I am experiencing now. I tried modifying the year for a particular album and it says I cannot save the changes, as pictured. [Screen Shot 2022-04-26 at 4.57.02 PM] If I change the month and year, it appears to save but the shown result is the wrong year, as shown. [Screen Shot 2022-04-26 at 5.05.14 PM] [Screen Shot 2022-04-26 at 5.05.32 PM] If I change it back to 1970-01…

[PGalati]

@Volts

I think it’s only cosmetic, .year is never used for anything but display?

I certainly use it for smart playlists for decades of music.

[dane22]

It’s sadly 00:43 here in Denmark, so off to bed

But on my plate for tomorrow to dig into

[Volts]

Yeah, uh, cosmetic … but also, used for Smart Playlists.

It’s the same issue, and the same thing works for Albums/Tracks, but again I haven’t tested it much.

UPDATE metadata_items SET year = 
STRFTIME('%Y',originally_available_at,'unixepoch') WHERE year <> 
STRFTIME('%Y',originally_available_at,'unixepoch') AND metadata_type IN (9,10); 

[dane22]

I’ve logged this issue for the developers to look at.

[Volts]

Hey a new PMS!

Plex Media Server

Plex Media Server 1.26.1.5772 is now available to Plex Pass users in the Beta update channel. FIXES: (Metadata) Manually setting the Originally Available date on an item would result in an incorrect year being stored (#13508)

(Thank you @dane22 & @ridley)

[Volts]

I notice that this update didn’t fixup all pre-existing mismatches between year and originally_available_at. I was surprised by weird year values for a large number of TV episodes - things I haven’t updated recently.

It appears that Refresh Metadata doesn’t forcibly update all mismatches either. (It does when Originally Available At is modified.)

So I’m considering running this:

UPDATE metadata_items
SET year = STRFTIME('%Y',originally_available_at,'unixepoch')
WHERE
(
 originally_available_at IS NOT NULL
 AND
 (
  year IS NULL
  OR year <> STRFTIME('%Y',originally_available_at,'unixepoch')
 )
);

Edit: I made a backup and did it. I’ll let you know if anything explodes.
Edit a month later: Nothing explodes. I’ve used it again to fix more bad dates from the agents.

[Volts]

@Plan-B I saw your comment in another thread. If you’re comfortable running a SQL update against your database, the above will shotgun-correct the year based on the saved originally_available_at.

[Plan-B]

@Volts Thanks for this. I’m very tempted to try it. I haven’t touched SQL in over a decade so I’m gonna give it a couple of PMS update cycles to see if they figure out a way to fix broken/mismatched years.

[Volts]

I was surprised this version didn’t update year already. It’s possible a future update will do so, or a future update will do so as part of the normal periodic optimization process.

If not, you don’t need to be an SQL expert. If you can find your Plex SQLite binary and your com.plexapp.plugins.library.db database file, the SQL statement can be copied & pasted.

LMK if you decide to do that and want a walkthrough.

[Plan-B]

@Volts I realized I had more media stuck at 1900 than I realized when I viewed all titles and sorted by year. So I tried the SQL update and couldn’t figure out how to get it to work.

I started by running:
.open "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/com.plexapp.plugins.library.db"

Then did a simple copy/paste of your update and got:
Error: no such table: metadata_items

I had to find a time when I was pretty sure no one was going to try and watch anything. So I might try again later and see if I can figure out what went wrong (probably didn’t open the DB file correctly).

[Volts]

Is that the database file location? I would guess here maybe:

ls "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db"

Stop Plex and make a backup first.

[Plan-B]

Oh wait. Duh. You’re right! I mis-copied the path. I just ran it again and everything seems to be properly aligned now. Thanks!