Item View Entries Are Incorrect for Shared GUIDs

Plex Media Server
, ,
1

Server Version#: 1.40.1.8227 (Affects older server versions as well)
Player Version#: Plexamp 4.10, Plex Web (Latest)

During my investigation for a different issue I saw quite a bit of weirdness with the play history for my library, though at the time the only example I had was with that one particular album and one of the underlying causes was resolved upstream which prevented me from investigating the actual cause further. I have a clearer idea of what’s happening at this point.

Recently I was playing the first few tracks from the following album while exploring the new Plexamp 4.10 update:

image

and noticed that the “Recently Played” entries that were showing up in Plexamp were referencing the correct tracks, but from wrong album:

image

I wanted to test if this was being caused by the new Plexamp update so I tested several other devices with older versions of Plexamp but the issue still occurs. It also occurs when playing the tracks via the Plex Web UI.

I decided to take a deeper look at my play history via the web dashboard and saw that the reported album was actually correct:

image
image891×440 45 KB

Upon clicking any of the entries that were affected in the Plexamp screenshots, it takes me to the wrong album in the Web UI - so it would seem that the actual history entries are messed up. Interestingly enough, the affected tracks all seem to share MusicBrainz IDs with the Greatest Hits album that I have. If I remember correctly, each play history item records the title, album, and artist names in plain text while also having guid references to the parent metadata items. Those GUID references are likely being saved incorrectly (as I found in the linked post); my best guess is that perhaps Plex Media Server is running a lookup based on the MusicBrainz ID of the track and using the first match (this would probably explain why depending on the order you added the albums to the library, the issue may or may not happen, since it would depend on the order of the metadata entries in the database).

Looking back at my play history for that particular artist, I can see each time that I chose to listen to that particular album for the duration that I’ve had that particular library (at least 2 years) - of which, all instances seem to have this issue which would lead me further to believe that this is a history recording issue on the server side.

At this point, I suspect that the other post that I had made essentially just tracks a number of symptoms that were caused by the issue I’m covering in this thread (hence why I made a new topic).

Additionally, the “History” view on Plexamp’s home view is now missing several entries (the attached image corresponds to the same time frame as the dashboard screenshot):

image

Related issue:

2

Upon further investigation it seems that both tracks share the same guid (which I believe may have been derived from the one of the MusicBrainz IDs (not mbid in the XML view, it may be release ID or recording ID in MusicBrainz own terms). The parentGuid is different (which makes sense since both entries belong to different albums).

Is there anything that can be done to address this overall issue, since incorrect history entries affect many of the history dependent features in Plexamp?

3

I’ve done some additional digging into how metadata_item_views is structured and it seems that it doesn’t contain a direct reference to the items parent (the album) at all, only a text string containing the parent_title (album title) in-line with the record. Furthermore, for media items that share the same guid (which seems to be the case here), there is no other information that can be easily used to derive the true parent item or even the actual media item itself.

What seems to be happening is that when Plexamp loads the history data, it pulls the first metadata_item entry for the guid for a given metadata_item_views which in case mentioned above has the potential to be entirely wrong. Plex Web’s dashboard, on the other hand, directly displays the inline parent_title, but if you click on a history entry it will jump to the parent item that matches the first metadata_item that matches the entry’s guid which, as previously stated, can be completely wrong. Even if it attempted to reverse look-up the parent item via parent_title, there’d still be be a chance to reference the wrong parent item if that particular artist contains multiple albums with the same name (see Peter Gabriel, Weezer, etc.).

There are a number of potential ways to address this issue:

  • Add the real metadata_item.id to metadata_item_views
  • Inline the real parent_guid into metadata_item_views
  • etc.

Of course, any steps taken towards resolving this issue would likely require retroactive fixes to be made to existing history entries when migrations are run; how feasible and / or complex this would be would vary depending on the approach taken. Furthermore, when library maintainers update, remove, or replace albums these IDs may be invalidated.

The circumstances in which this issue can affect libraries only seem to require that the library contain multiple releases containing the same tracks, which could potentially affect many users that contain “Greatest Hits” compilation albums alongside original albums.

I definitely would consider this issue to be something like a cross between a design limitation and a bug due to the impact that this can have on other aspects of Plexamp. Hopefully it can be addressed at some point.

4

Update: I’ve found more tracks that get’s recorded incorrectly. I have the following album where 2 of the tracks are technically also found under a different soundtrack album. Playing them from their original album reports that they were played from the soundtrack album.

image

image

5

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