Library management is important for many use cases.
Libraries can become quite large. With all kind of automatisms (auto-adding media to library), there are cases where media can become “lost” (ie. hard to find) under rare circumstances.
Let me describe such a scenario where library management in Plex Media Server is not perfect:
Internal basics:
Each library item has three time-stamps when you look at the XML:
<MediaContainer … mediaTagVersion="1616494552">
<Video … addedAt="1616838821" updatedAt="1616838829">
<Media …>
<Part …>
<Stream …> </Stream>
<Stream …> </Stream>
</Part>
</Media>
<Extras size="0"> </Extras>
<Related> </Related>
</Video>
</MediaContainer>
The mediaTagVersion attribute is just that … a version number identical to all library items at any moment.
The XML key “video” contains the other two attributes: “addedAt” and “updatedAt”. “addedAt” is what we want to look at in our scenario.
Please note, that neither the “media” XML key nor the “part” XML key(s) contain time stamps.
There’s also a view state if an item has been viewed but for the showcase, this is not important.
Showcase:
If media is added to a library, the “addedAt” attribute of the “video” XML key is set.
If PMS identifies it as a NEW library item (ie. movie has not been added before), the addedAt attribute stays the same, and the updatedAt attribute is set to the moment of identification. That’s fine.
If PMS identifies it as an item that existed before (ie. duplicate of existing movie or movie that had existed but was removied before), it adds the media/parts of the new item to the existing container, using the “addedAt” attribute of the existing container, just updating the “updatedAt” attribute. The info of the original but now integrated item is lost (especially the timestamp on when this item has been added to the library).
All is fine for new movies, all is fine for real duplicates - this is expected behavior.
But if an item is identified FALSELY as an already existing library item (making it a false duplicate), a problem arises. The use will want to separate those items.
Once does that, he gets (at least) two items that are exact copies including “addedAt” attribute of the video container.
While being logical in itself if looked at isolated, now there’s no way back to the true timestamp of library addition of that item.
Plex works around this: if you match the now parted media manually, it sets the “addedAt” attribute. In most cases, this is just fine.
But in case of personal media, this is not expected, not good at all.
If you cannot match a movie (because there’s nothing to match or there are other reasons why you want to have it as personal media), then you of course must remove the false match at least, creating “personal media”.
Originally, I thought that it would just make it an “unidentified library item” once again, setting the “addedAt” attribute once again, but I was wrong.
If you remove the match, it keeps the “addedAt” timestamp (which is wrong in itself) and it becomes “personal media”.
Therefore, you cannot find it in a large library any longer (no unidentified filter works) and although the user knows the date he or she added it, the user cannot find the media for later manual matching by sorting by “library addition date”. Its “addedAt” timestamp is neither true nor has anything to do with that item.
Easy solution of this:
- set the “addedAt” date of any library item once a user manually removes a (false) match.
Correct solution for this:
- Implement an additional timestamp on the media/part level of any library item so you can set back the correct timestamps once the user splits up a duplicate or manually removes an item’s identification.
In short:
Everything is fine (or at least bearable) as long as matching works good. But Plex is also using the matching mechanism to create “personal media”. And in this case, Plex is not using the right way of handling “addedAt”.
Oh, and by the way: having a new filter “personal media” for any library would help, too.
