Rating one track in an album applies the rating to all tracks in the album. 
Do those ratings persist if you refresh the app? Or do the track ratings get reverted back to the stars they had?
Yes, if I refresh immediately after clicking the rating, all track ratings are changed & persisted as that rating.
That is strange⊠Iâm having trouble reproducing the issue on my end. Does it happen with every album? Does it require specific steps beyond playing a track after rating a track?
It only happens with some albums, and can also happen with just a couple tracks in an album of many tracks. It doesnât require any specific steps beyond rating and playing. Looked at the file permissions and XML and I canât see any difference.
I think this only happens with âunmatchedâ albums.
@iceton try this:
on this album page, go up, right to the ellipsis ( . . . ) and click on it
pick âMatchâ/âFix Matchâ
in the resulting window pick âAuto-Matchâ
and then âPersonal Media Artistsâ
Then leave the âalbumâ page
and re-enter it
Repeat the test.
If track A is rated and track B receives the rating unintentionally, I donât see track Bâs key in any network requests, but B displays the rating and it persists on refresh.
@OttoKerner unfortunately that doesnât work. Tried as you described, refreshed the album page too. Same behavior as before.
I recently found this to be a problem as well. After some fiddling around I have not only been able to recreate the situation, but also to rectify it.
After much googling around and little results I stumbled upon this page. I tried OttoKerner and ericmatthys suggestions to no avail. I even went into the plex server logs and can only find instances of it changing one tracks rating, even though they clearly edited each of the specific tracks .xmlâs.
So some trial and error was needed in order to get to the root of the problem. I found two different albums where this error was occuring. I tried removing one of the problematic albums to a new directory and generated a fresh music library on the directory alone. Not surprisingly, it was still an issue.
Next I tried removing all formatting from the folders containing the problematic album. Remade test library. Same problem.
Next I tried putting each song in a different folder, and voila, each track retains itâs own separate rating without changing the other in the album. Obviously though, I donât want every single track in my library to have itâs own folder, so I was not yet satisfied.
I then put the problematic album back into a single folder, and stripped out all of the metadata from them. When added to the test library, this data-less was yet again rating the whole folder simultaneously.
Looking back through my problematic albums metadata, I noticed they were lacking track numbers. I inserted the proper track numbers into the ID3 tags, and reloaded them into the test library in a single folder. BOOM. Problem solved. Tracks now retain their own ratings, in a single folder.
Tested solution on other problematic folder. Also resolved.
I donât know what about the rating process in Plex is requiring track numbers to be present, but it kind of seems like it would be more ideal if it was using the media id instead. That would avoid this situation all together.
Hope this helps someone! 
1 Like
Iâll note that adding a track number manually into Plex does not effect this in anyway. It only matters if they had track numbers in the ID3 tags on import.
Therefore, after adding the track numbers to your ID3 tags, youâll need to do a Plex dance for that content in order for the content to rate properly.
Also note that if there is any letters in your track number (ie. âA1â, or âB3â) Plex will not grab them. Probably irrelevant, but Windows explorer displays track numbers with letters as 0. I recommend backing up your original track numbers into a different tag, and then replacing all letters with a number equivalent. (ie. Replace all "A"s with "1"s, al "D"s with "4"s). If this error is ever fixed you could then easily restore the original track ratings from the new tag youâve created.
Happy Plexing!
Nice investigation @Aethaeran. I checked with the server team and tracks in non-premium music libraries do use a unique identifier of the album + track index. Premium music libraries actually do have unique identifiers that do not rely on the track index though. Do you know if you are using a premium music library? I noticed your forum account has the Plex Pass badge, and as I understand it, this issue wouldnât affect premium music libraries.
I can confirm that I am using a non-premium library.
I would prefer not to change to a premium library as Iâve noticed it takes substantially longer to parse files than I like, even on minimal settings, to the point of crashing Plex Media Server, but thatâs a totally different subject.
I created a sample library both premium and non-premium, and can confirm that rating tracks works correctly in premium libraries.
I can also confirm that when one clicks ââŠâ on a specific track in their music library, and then clicks âGet Infoâ and then continues to click âView XMLâ that each Library, Artist, Album, Track and Media have their own unique identifier within the database.
I believe itâs a little something like this
librarySectionID = Library
grandparentRatingKey = Artist
parentRatingKey = Album
ratingKey = Track
ID = Media
In example, this is the XML pulled from one of my tracks, I pulled nearly identical ones from both the premium and non-premium sample libraries.
<MediaContainer size="1" allowSync="1" identifier="com.plexapp.plugins.library" librarySectionID="16" librarySectionTitle="Music" librarySectionUUID="1b790078-c796-4659-abba-42fcca54348c" mediaTagPrefix="/system/bundle/media/flags/" mediaTagVersion="1510653026"><Track ratingKey="192377" key="/library/metadata/192377" parentRatingKey="191813" grandparentRatingKey="191812" guid="com.plexapp.agents.none://191813/1?lang=xn" librarySectionID="16" librarySectionKey="/library/sections/16" type="track" title="Blackened" grandparentKey="/library/metadata/191812" parentKey="/library/metadata/191813" grandparentTitle="Metallica" parentTitle="...And Justice For All" originalTitle="Metallica" summary="" index="1" parentIndex="1" userRating="8.0" lastViewedAt="1512446909" year="2006" thumb="/library/metadata/191813/thumb/1511299436" parentThumb="/library/metadata/191813/thumb/1511299436" duration="402268" originallyAvailableAt="2006-12-01" addedAt="1511300509" updatedAt="1511390789" createdAtAccuracy="epoch" createdAtTZOffset="-28800"><Media id="269744" duration="402268" bitrate="133" audioChannels="2" audioCodec="mp3" container="mp3"><Part accessible="1" exists="1" id="320547" key="/library/parts/320547/1511390112/file.mp3" duration="402268" file="N:\My Music\Metallica\[1988] ...And Justice For All\01 - Metallica - Blackened.mp3" size="6700255" container="mp3" hasThumbnail="1"><Stream id="562237" streamType="2" selected="1" codec="mp3" index="0" channels="2" bitrate="128" audioChannelLayout="stereo" samplingRate="44100"/></Part></Media><Extras size="0">
</Extras></Track></MediaContainer>
What I donât understand is WHY it would use parentTitle & index rather than using parentRatingKey and ratingKey to apply changes to userRating. It seems like this would be the foolproof way to do it. I wouldnât doubt that this is how it is being done in premium libraries, and Iâm not sure why it would be excluded from basic libraries as properly rating track is the kind of basic functionality that all users deserve.
The actual request to rate a track does use the ratingKey. Iâm unsure of all the details related to why the shared guid causes this behavior under the hood, but Iâve raised the issue with the media server team to investigate further.
Much appreciated sir. I hope they figure it out.
My solution was very similar to this in that it appears to be an ID3 tag issue. I updated the ID3 tags correctly and it fixed the issue
