I was just coming to post this. I see the same behavior: Year is set to 1900.
I just discovered this as well.
Odd. I’m not seeing any issue with dates displaying as 1900. Which view is this happening in? Is it a specific device or UI which is showing this?
Are these items which were edited in 1.26.0?
Can you share a screenshot?
So this still is not fixed exactly. I’m glad that yesterday I downgraded to version 1.25.8.5663. Instead of waiting for and hoping that the new 1.26.1.5762 would fix all issues, because it clearly hasn’t. I can’t speak for anyone else but I’m perfectly content to remain on version 1.25.8.5663 for a long time. I’m sick of new server updates creating issues. I’ll say again, Plex needs to properly test updates before making them public to download.
1 Like
Oh… This is not good.
1 Like
I agree, there’s still a similar-but-different issue going on.
I think this is entirely cosmetic.
New PMS:
1 Like
Awesome! Hopefully this update makes it past the beta testing phase.
I am looking forward to correcting some dates and moving on.
The issue is not completely fixed. Have you tried entering a date before the year 1900?
I’ve been using the release date field to carry years like 0001, 0002, … 0029 to give children’s audio plays a chronological order. This worked perfectly until Plex changed the data type of the released date field.
Using mp3tag to tag my media files with dates like described above made Plex adding those files with release date 0001-01-01, 0002-01-01 and so on. The date was (and still is for entries that I haven’t changed since than) displayed as “1”, “2”, … (see screenshot below)
Perfect for sorting audiobooks and audio plays for my little son as he doesn’t care about the real releasedate. He just wants to listen to his audiobooks in the correct order.
Now entering a date like 0029-01-01 manually in Plex shows this:
I can’t save that date at all.
Other dates like 1899-12-31 can be saved but…
… are converted into a date in the future.
Please please please restore the behavior as it was before changing the data type or at least allow the date to be changed manually.
I’m using Version 1.26.1.5772 on a Windows 10 machine.
3 Likes
is there a way to fix this? Im not sure how to edit metadata.
That would depend on the media type. For audio files like music, there are a lot of MP3 ID3 tag editors out there. A lot of them can support metadata tags for multiple formats (AAC, FLAC, Ogg, etc.).
I use an app called Subler to edit MP4 video file metadata but I think it’s only on MacOS. It’s pretty handy and easy to use, but I haven’t found any equivalent for Windows so I just do all my file organization on my iMac and use my Windows machines for video compression since I prefer XMedia Recode to Handbrake.
If you use the Matroska video file format (which I default to for movies & TV shows), the most common app that I know of is MKVToolNix, which is actually a suite of tools with some GUI accessible and some command line.
One really annoying thing I’ve noticed about the remaining year “1900” bug is that there isn’t a way to refresh & corrected the affected entries all at once. You have to edit the date to something else, save it, then edit it back again. So if you happened to scan in a lot of video when the buggy server version was out, there isn’t a good way that I’ve found to bulk repair the broken year display.
Keep in mind that there are (3) locations where Plex Music metadata can be stored. Within the local audio file, the Plex Database, and third-party metadata providers such as MusicBrainz. This is important to remember, given all locations have the ability to take priority over other sources depending on the server configuration and active bugs.
If Plex honored metadata that was stored within the Plex Database, there would be little need to muck around with files and third-party websites. Let’s be real, there are reasons to not modify file metadata for the sole benefit of Plex. Third-party websites will not accept external decision making, so the automation can only flow in a single direction and that leaves Plex at a recipient-only disadvantage.
The Plex Database should have the highest prioritization and be protected as a sacred data source. Local file metadata and third-party services can be left to perform an initial data population, and then cast aside until a manual task requests they can come out from their anti-bug prison.
So there is clearly something still going on with music, I am running 1.26.1.5772 and this seems to have corrected the 1969 thing, I just added an album - and I only use local mp3 tags…
So year 2013 in the tag, and this comes up with 2013-01-01 which makes sense. But plex shows that as year before… So seems related to this whole 1969-12-31 thing… Looks like its a day behind and so sees that year as year before.
1 Like
Thanks for the report. The number of bugs related to dates that made their way into a released version of PMS is a bit crazy to me… The situation has a real impact on users. I personally use dates as a data point a lot in all my libraries (movies, TV shows, music). So all of this forced me to downgrade to 1.25.9.5721.
I really hope all these bugs will be fixed with the next release.
1 Like
Can we highlight how the weeks it takes to rollout a bug fix seems to do more harm than good?
Where was the due diligence when the bug was initially introduced? Now that the magnifying glass is out in the development chambers, we are left to patiently babysit a bug that shouldn’t exist in the first place. Seriously, how does any version of Plex release without testing all of the metadata fields?
Plex Staff, read this and get back to us with your thoughts:
Yes, the lack of basic development techniques should be pointed out. No your scholarly merits are not protecting the product that feeds your family. Please do everyone a favor and take the interns off of the internal bug ticket.
Also, add manual editing for music Release Types:
It should not take more than 6 months to deploy a such a simple feature, one that seems to be missing due to negligence. I am baffled that this request has to compete with “wish upon a star” requests like adding Plex support for smart watches. Support and protect the metadata or bust.
1 Like
One way is to do major semi-annual releases, with beta only to select users, and discussion of the bugs in a restricted group.
I would not want that.
As bugs go, this date bug is minor for most users, and for those that it’s not, a downgrade path is available.
No one suggested semi-annual updates. CI/CD is perhaps the exact opposite in frequency. No offense, but I am not even sure where you got the idea that semi-annual updates would be acceptable for anything public-facing. Not even enterprise solutions move that slowly.
Any bug that messes with metadata is not minor. Users who claim they are not impacted do not understand the impact they face.
A downgrade path does not make sense for Plex. The Plex environment requires multiple services to work in tandem. That means as Plex Clients upgrade forward, older Plex Media Server versions become less relevant. There is also the issue with Database compatibility. Will a multiple version jump result in a corrupt database?
Once again, I don’t mean any offense, but your response was smothered in a lazy ambience.
1 Like
Our CI for a 3rd party API wrapper was able to catch the date error.
https://github.com/pkkid/python-plexapi/runs/6127614839?check_suite_focus=true#step:12:721
1 Like
