You listen to classical music? Don’t you know that Plex does not consider such as “real” music.
It appears that Plex tries VERY hard to tag any classical music it finds as anything but what it is. I have had Rachmaninoff tagged as rap albums.
Also as you have found if you have had the audacity to try to correctly match and tag classical albums Plex will correct that mistake as soon as it can.
I try the best I can to make Plex ignore my classical libraries for anything except playback. I would rather have the correct title and nothing else that the crap matches that Plex usually provides.
Sure, Plex music should at least allow “by composer” for classical music but that’s not the point.
When you hit “refresh” all agents refresh metadata EXCEPT for “local media assets” agent. This one insists on watching belly dancers first before doing any additional work. I wish I could do the same in my household
Which file time are you talking about? In Windows at least, and I think it’s the same for Linux, there are 3 timestamps for every file - Created date/time, Modified date/time, and Accessed date/time.
I’m guessing you’re probably talking about the Modified date/time. But are you aware that most tag editing tools (Picard, MP3Tag, Puddletag) have settings to allow the Modified time to be preserved when saving tags? So the Modified date/time is not a reliable parameter for determining when tags have been updated.
But are you aware that most tag editing tools (Picard, MP3Tag, Puddletag) have settings to allow the Modified time to be preserved when saving tags? So the Modified date/time is not a reliable parameter for determining when tags have been updated.
That’s unfortunate, because the scanner uses heuristics like this to know whether or not files have changed. If it literally had to parse tags for every single file, it would increase scan time easily by a factor of 10x - 100x.
@beckfield ~ you’re clearly the resident dance instructor here, so I’m totally willing to chat with you more in detail to see if we can’t figure out some tweaks to improve things. Let’s keep chatting.
As it turns out, my tag editors were both set to preserve the modified date of files when tags were edited and saved. So I turned the setting off and repeated my previous experiment. This time, ‘Refresh Metadata’ did not pick up the change, but ‘Scan Library Files’ did.
It will take some more testing to determine if this will be the case for all tags. But if that is the root of all the Plex Dance issues, we should have had this conversation 3 years ago.
The fact that tag editors can be configured to preserve the Modified timestamp is still a challenge.
TBH, if you have the last-modified stamp set to remain unchanged even after modifications, then it’s no wonder the scanner doesn’t pick up changes. As Elan says, the only way to work around that would be to have Plex scan the entire metadata for every file every time it does a scan - which would take hours. So this seems entirely reasonable.
I guess this is where the question “why does the Plex Dance exist” comes in. If there was an option to manually tell Plex to disregard everything it knows, and completely rescan the metadata for a selected subset of media (a file, series or whatever) then users could use this function instead of having to manually dance the files out and back in again. Does it not make sense to add such a feature, Elan? It seems like the implementation would be trivial, but it would probably solve 80% of the “my media isn’t matched correctly, but I can’t get Plex to pick up changes” issues on the forum.
That may be the perfect solution. It would also avoid the extremely long scans @elan mentioned.
We already have the ‘Refresh Metadata’ command at the Artist/Album level, and ‘Refresh All Metadata’ at the Library level. We have ‘Scan Library Files’ at the Library level. All we need is a ‘Force Rescan Files’ (didn’t we used to have this?) at the Artist/Album level. ‘Force Rescan’ differs from ‘Scan Library Files’ in that it does not consider the timestamp of the files. It should respect locked fields in Plex, however.
This is all contingent on if the Modified timestamp is the only thing that has been causing all this trouble.
I just repeated the test using a file from a different album. I removed some information from the TIT2 tag, allowing the timestamp to be changed, and verifying that it was changed. Plex’s Scan Library Files and Refresh Metadata both failed to recognize the change.
I’m going to be off line for the next 3 days. I’ll pick this back up on Monday.
We have to be careful with terminology here, in terms of “rescan the metadata” Scanning and metadata are handled by two different parts of the system.
I once worked on a piece of code to allow totally re-scanning a thing (e.g. artist, album, movie) from scratch, and the actual code was working, before I realized it was more complicated than I’d thought, since the items might be in a play list, or a play queue, or other areas in the database, and we wouldn’t want to necessarily “break the links”.
From a UX perspective, it’s also tricky to add yet-another-option above the existing refreshing, scanning, deep refreshing, etc.
So I’d say it would only make sense if there ended up being a real need for it, which I’ve argued over the years there wasn’t. But I think this is why we’re having this conversation, and for once it looks like we’re making some progress.
We did in fact have such an option (good memory!). We needed it because the scanner had some bugs in its optimizations (or said another way, it was possible for it to be wrong in fairly common circumstances). The new code, which walks through every directory and looks at basic file attributes should be 100% right, except for cases when—my phrasing—one goes out of one’s way to fool it
I just went and checked the code, and found this comment:
// There are no more critical hints for tracks, because
// we allow editing them in the interface (e.g. track index),
// and we don't want that editing to lead to re-matching during
// subsequent scans.
//
I think what this implies is that changing a track’s tags (the ones used to determine critical hints) will not result in the file being re-scanned. I’m not certain I remember why exactly we did this, except that it in the timeframe of the premium library and enhanced editor.
However, in your case I would have expected changing a track title to be handled by the local media agent (if it’s the highest priority agent). Upon looking at that code, it looks like we’re only grabbing sort titles, genres, and embedded artwork.
No doubt about that! The wording will need to be specific and almost self explanatory.
I’m going to put my two cents in here. I don’t think anyone here who has dealt with the Plex Dance would mind at all if a command (aka PlexDanceMe) could do exactly what the PlexDance does now… To delete all references to said file in a simple quick command without the need to move media around. Cause as it stands now, that’s exactly what happens with the PlexDance, removes from play list, play queue, or other areas in the database. We loose nothing and gain much.
That actually sounds great! I would update to that version the moment I found out that feature was implemented.
BTW, thanks for chiming in. It really does mean alot you show interest in this topic.
+1. This could always be an advanced feature, and with an appropriate “Are you sure” dialog box it would be fine. You wouldn’t run it on the entire collection, just a season or series, perhaps. But I think it would massively help. Breaking the links isn’t ideal, but currently the only option is to dance the media out and in again - which breaks the links anyway. So if that needs to be done, give it a button.
And btw, when I mentioned “scanning metadata” I was including filename, timestamp and other OS-level stuff in the same box as the actual media metadata itself. But yes, the nomenclature is important to avoid confusion.
Also the way I see it is if you are doing(about to do) a plex dance then something is wrong and you are trying to fix it. Why would one want to keep the “messed up” content in their play list, other areas of the database, etc. if it’s messed up to a point that we need to do the most extreme measure, The Plex Dance.
I wholeheartedly disagree. It makes absolutely no sense to put time and effort into codifying a workaround when we’re (finally) identifying the root cause of the problem.
I agree it shouldn’t ignore title! But as stated before, there is the split between agent and scanner which is still important, the agent has to be careful/avoid setting critical fields which the scanner looks at, otherwise they can get into a disagreement.
For title and many other tags, this shouldn’t be the case, clearly.
Okay, what I should have said is “Between the two of them, all metadata that Plex uses should be updateable, while respecting user-locked fields.” How’s that? And the other thread that I linked to lists all the metadata that I think you should be using.
Scanning and metadata are handled by two different parts of the system.
