Thanks for confirming!
This is actually a separate bug, it’s like this with the current release and has been for a long time. I’ll file an issue to get that fixed too.
2 Likes
I’m quite sure that bug has been around since Plex introduced the new scanner/agent quite some time ago (although others would disagree, saying a later bug) I use the soundtrack CD from Forest Gump as my test album for the big test, as I have an almost ridiculous amount of genres attached to each track, and it has always only shown the first track’s genres since day one.
Wouldn’t the proper fix for that specific use case be the support of per track genre support rather than album/artist which plex currently does ?
BTW… would love to see track level genre support 
1 Like
Yeah, track-level genres would be great, would really help with smart playlists.
But this is something else: genres have always been album-level in Plex, but before the switch to ffmpeg as the tag reading library (almost year ago I think?), Plex used to add all genres for all individual tracks to the “album genres”, not just those of track 1.
That would be cool right.
1 Like
I posted sometime ago in this very thread we had lost all but the first tack’s genre at the album level.
The images do show (I think) that the genres were no longer being “rolled up” to the album level as they were before the change to ffmpeg.
as an optimist, I’m gonna take that as “we’re actually looking at that” 
1 Like
Finally got the free time to try this out, and so far, so good. Good job, everyone!
It’s a “tad” frustrating that Plex only applies the genre(s) of the first track at the album level, but an improvement, non the less. Thanks again.
Congrats to the team on the fix. I haven’t tested it myself since I no longer rely on the scanner service for genres but I appreciate the hard work. For what it’s worth, my plex-genres-from-tags script also only checks the first track, since track-level genre tagging is rarely used and even more rarely supported. I assume the results of the two methods are nearly identical.
Surprised you would say that. Every tag editing software I use is essentially at the track level - that is, tags are written to each track individually, and not to some vague, non existent album category (except in Plex)
1 Like
@drzoidberg33 – Any chance the recent couple of updates to the server in the Beta channel include this fix for ffmpeg, so I can update the credit detection capabilities? There’s no mention of it in the release notes.
No, not yet. It will be a little while before this lands in a release.
For my own future reference, will I have to manually uninstall the server to “downgrade” to the latest beta update? (installed experimental version is 1.31.2.6700 and latest beta is 1.31.1.6733)
I’m not in a hurry to have some of the fixes/updates outlined in the release notes, but maybe future updates might strike my fancy as necessary improvements.
I’ve manually uninstalled the server several times over the years, and never had a problem with a “downgrade” or “upgrade” after that. However, I’ve seen a lot of posts recently with unable to connect to server or reclaiming the server, and I’d rather avoid the potential problem if possible. 
That’s true, but I don’t think I’ve ever seen a client that expects them to vary per track within an album. It’s one of the idiosyncrasies of music tagging. I avoid doing it just to make life simpler.
Clearly, you are not a DJ Track-level genres are essential for us.
Auto-taggers like OneTagger are used a lot by people who need to do track-level tagging.
Of course, auto-taggers that use databases with only album-level years or genres like Discogs or MusicBrainz, cannot do it.
I see ffmpeg just released version 6.0. My linux distro hasn’t incorporated it yet, and I haven’t bothered to install it manually. Has anyone tried it? I presume it has the fix mentioned in this thread.
Version 6 for windows, does not have the fix. Or if it does, I can only get it to show one genre in MP3 files. Maybe I need a different command to show more genres…
No, this ffmpeg patch still has not been reviewed yet, despite being submitted back in August 2022.
Seems to me almost everyone is missing the point, that some data is relevant to each track and some is only relevant to the album. Genre and Year are 2 tags that apply to both, the latter being perhaps unrelated between track and album, but for the former, the album should probably be tagged with an amalgam of all the genres for all its tracks.
However, it seems that everyone (users and developers alike) have their own opinion of whether to have track OR album versions of any particular tag. No-one seems to have embraced the fact that for some tags, BOTH are required.
None of this is particularly hard to grasp, but even those involved in the creation of the very rules by which the rest of us have to abide seem to have never actually used the systems they are deciding on. The first MP3 tags were provided with only a single option, so e.g. only a single genre could be applied and the problem compounded by trying to enforce a minimal list from which a genre could be selected. Hopelessly inappropriate and only someone ignorant in the use and categorisation of music could ever have considered it adequate.
The net result is the mess we are all now in, so many years later with everyone arguing about the best way to bodge multiple values into music files’ tags and in the case of the software developers, often failing to even implement what they say should be how it works, apparently refusing to provide adequate (or any) documentation about how it is supposed to work and taking YEARS to fix what doesn’t.
I was working on databases in the music industry before the arrival of MP3s and had I been asked I could have easily explained what was required, They didn’t ask however and obviously asked the tea lady instead. 
1 Like
Oh, there are specific tags for the release (TDRL Release Date) and the track (TDRC Date). But software developers ignore them. Musicbrainz Picard in particular auto-writes the album release date in the track Date field, and writes nothing in the Release Date field. Plex does not read the Release Date field, only the track date - but uses it for the whole release.
Apps like Apple Music/iTunes and Navidrome (at the moment) only read the track date (TDRC), but at least they also use it as a track date: in those libraries an album can have songs with different dates.
And then there’s the mis-use of TDOR Original Date field, which the id3 spec says it holds the date of the original in the case of a cover, remix or live version. But Picard ignores that and writes the earliest album release date in that field instead.
As an app developer you need to make a choice: do I follow the specs, or do I try to guess how people do it “wrong”?
