similar to this topic, but it is closed, and for linux servers.
Plex can find the match, with an automatic match or using the search options. Neither method seems to actually match the album. The files are tagged with MusicBrainz Picard, and have all of the embedded metadata for release group, album ID, etc.
This pic shows the album should be matchable. Refreshing the metadata for the album does not find the match, it remains unmatched. However, if you refresh the metadata for the artist, the album will be matched.
I add albums to Musicbrainz regularly, and I used to be able to match the albums a few days after I had added them to my music library using the “Match” option (giving the Plex servers time to sync their data)
a couple of related questions…
Plex used to show in the XML for unmatched albums a guid that said guid="mbid:"(or something similar to that) for unmatched albums and tracks. I’m guessing it was reading the embedded metadata. Now it seems to ignore it, and uses guid="local"
Secondly, Plex music doesn’t seem to refresh the metadata for “Artists” during the scheduled maintenance. If it did, wouldn’t the albums be matched then, the same as a manual refresh of the artists does?
attached logs, where I tried to match the album “Don’t Feel Sorry for Me / Little Coquette” by “Jimmy Beasley” and then forced a match using “Refresh Artist”
(File removed)
Thanks for looking at the logs, but all you have done is verify exactly what I said.
The process failed when I tried to match it manually. I believe this is the relevant lines:
Nov 03, 2020 07:47:57.425 [9920] ERROR - Music: Album exchange failed.
Nov 03, 2020 07:47:57.425 [9920] ERROR - Music: Processing match for GUID mbid://735fc192-3600-4f0d-a440-7740ab5931c7 failed.
When I re-freshed the artist (not the album), a few minutes later. the album was instantly matched. Refreshing the album has no affect, it will not be matched.
Nov 03, 2020 07:54:12.763 [10084] DEBUG - Refreshing child item 'Don't Feel Sorry for Me / Little Coquette' with agent tv.plex.agents.music
Nov 03, 2020 07:54:12.763 [10084] DEBUG - Matching 'Don't Feel Sorry for Me / Little Coquette' (ID 713111) with agent tv.plex.agents.music
They aren’t. They are in a sub-folder of the folder “Plex Videos” named “Albums” and the music library is pointed to that folder The folder “Plex Videos” is a catch-all for everything Plex related, which also has several TV and Movie folders, with video libraries pointed to the respective sub-folders
Of course not, I added that album to the Musicbrainz database on Oct 29, 2010.
I did not try to match the album until November 03, to allow the Plex servers time to sync their data with the MusicBrainz data base. The album was in my library, but only using the local embedded metadata. (the album was added to the library on Oct 29, as well).
Before adding the album to my library, the files were tagged with MusicBrainz Picard, which also applies tags for the release and release group. mbid://735fc192-3600-4f0d-a440-7740ab5931c7
is the release for that album.
As an aside, and possibly another glitch, even though that particular album says it’s matched (I only get a “Fix Match” option now) it still shows up on the unmatched albums when I filter the music library.
By the way, all of those albums in the screenshot are albums I added to the MusicBrainz data base, and have passed through the voting process of 7 days at least a week ago.
The fact that the albums remain unmatched in one place, and appear matched in another view is annoying, It doesn’t affect my library - all of the files are playable and sortable by genre, artist, release date, etc. But there is something buggy, when it’s impossible to make an unmatched but perfectly matchable album to MusicBrainz disappear from the unmatched filter list.
Since you got a match instantly to the same album, I’m thinking that Plex holds onto the “unmatched” status it initially got when I added the album someplace in the database. It was indeed unmatchable that day. Which is why it appears matched in one view, and unmatched in another view.
It IS a dedicated music folder. There are only music files in the folder “Albums”
so it’s:
F:\Plex Videos
… \Albums ← Music library pointed here
… \Television ← TV Library pointed here
… \Movies ← Movie library pointed here
…\Home Movies ← Other videos pointed here
It’s not any different than having a structure like \users\myname\Media\Music with the music library pointed to the sub-folder “Music” is it?
I added the Albums sub-folder when Plex first switched over to the new music system a little over a year ago. The update from the old system to the new system didn’t go as well as it was supposed to, so I basically copied the files over from the old library, deleted the old library and started over.
If I had known I was gonna have trouble with the Music library, I would have named the folder simply “Plex” so that I could have all Plex related stuff in one place, with sub-folders below that for the various libraries. I just assumed changing the name of the folder after the fact so that it didn’t include the “Videos” part, would just give me a new headache.
I think the problem in the database for the “unmatched” is that initially, from the XML, the files have a guid of local://713111 (an example from the album above) That’s expected, because the file is not matchable at MusicBrainz, so it’s using local metadata. Once you get a match, by refreshing the “Artist” (refreshing album doesn’t work) the XML shows mbid://735fc192-3600-4f0d-a440-7740ab5931c7 so the album is matched. That change doesn’t seem to filter it’s way down thru the entire database.
I have quite a few albums that remain “unmatched” in the filter view. They show up with a 100% match probability, but stubbornly refuse to disappear from the filtered view. Some are months old, have been refreshed at the artist level, the album level, and I assume during the maintenance periods.
It makes me wonder if it’s worth the time to add albums to the database. I guess it ensures you get a match…
I’m pretty sure all of my albums are tagged correctly. They show up properly with the correct Album Artist, track artist and genres. I DO have albums that are not in MB database, and I don’t expect them to ever match until I add them. All are legitimate, but they are rips of 45 RPM singles I’ve made, or old compilation albums from the 1960’s and 70’s and older. Adding a “Various Artists” album to the database is time consuming, and I imagine I’m the only person in the world who has some of the old 45’s that I inherited from my parents, so it isn’t a priority for me.
In any event, the albums that are matchable are tagged with MusicBrainz Picard, which gets it’s info from the database and writes the tags to the file. At some point in time they might magically match, but forcing a refresh of metadata does not always work.
If you feel that a matchable album that won’t match is not a bug, then I’m OK with that. I don’t lose too much sleep over unmatched albums in my library.
I apologize. I meant no offence and I guess I misinterpreted your reply.
I was reporting a problem with matchable albums that don’t seem to actually match. Even if it is only a select few. Out of over 2600 albums, I only have about 20 that actually fit into this category, and about 300 albums I know are not matchable.
I’m not looking for an argument, and even if I was, I don’t know how to prove that the tags and filenames were unaltered from the time I placed them in the library. Eventually it matched with the original structure and metadata in some places, and not in other places, so we’re all good.
