Not updating track info from tags - broken?

[Anamon]

This post is outdated, please see the summary post further down in the thread for the actual bug report.

I am posting this here because I'm not sure whether it's a bug, or just me misunderstanding a feature. I am pretty sure though that the behaviour of MM3 in this situation differs significantly from MM2. I am currently running MediaMonkey 3.2.2.1300 Gold. The only extension I have installed is the Last.FM Scrobbler.

This relates to the checkbox option Update Track info from Tags when rescanning files in the Library Options dialogue. The way I always understood this option is this:

• If the checkbox is activated and tracks are rescanned, manually or with the File Monitor, MediaMonkey will read the tags of the files and, if they differ from the tags stored in MM's database, update the latter with the information from the files. This allows other applications to modify tags, and the MediaMonkey library to reflect these changes.
• If the checkbox is deactivated and tracks are rescanned, manually or with the File Monitor, the tags in the files will be updated to reflect the information stored in the MediaMonkey database, if they differ. This allows MediaMonkey to restore tags to the ones stored in its own database, in case other applications modified (or damaged) the tags within the files.

I have been using the latter option since MM2, effectively using MediaMonkey as a tag backup solution that would allow me to restore all my music's tags should any application or player mess them up, by simply telling it to resynchronise. I figure that I am one of very few people who choose this option, as I could find very little discussion about it in the forums.

Today I have tried out the Picard Tagger from MusicBrainz on one of my newly ripped album folders surveyed by the File Monitor. I let MediaMonkey survey the files first and add the original tags to its database. I then let Picard propose some changes and write them to the files; minor stilistic changes such as removing the leading '0' from track numbers or changing the capitalisation of titles. I would have expected the tracks to then show up under MediaMonkey's 'Unsynchronized Tags' leaf, with the changed fields marked, but they didn't. Instead, it took only a moment for MediaMonkey to update its track information to the one written by Picard Tagger, automatically and unasked, even though the "Update Track info from Tags..." option was disabled. I don't think it should have done that, and it in fact makes the "Unsynchronized Tags" leaf superfluous if it is going to copy the tags to the database anyway.

Is there anything else that I failed to consider, or is it possible that this option is actually broken in MM3? If so, I think it must have been for a while, because I have found an over two-year-old report of this problem in another forum thread (which I decided not to revive) from the early days of MM3 here.

[Lowlander]

I'm not entirely sure the File Monitor is meant to not pick up those changes.

[nohitter151]

The option in its entirety reads "Update track info from tags when rescanning files". File monitor is not mentioned in the option, and that option isn't available under "File monitor". I think that implies the option only applies when rescanning and has nothing to do with file monitor.

[Lowlander]

Yeah, but I think it's reasonable to assume that the File Monitor would fall under rescanning (startup scan is rescanning basically).

[nohitter151]

Yeah, but I think it's reasonable to assume that the File Monitor would fall under rescanning (startup scan is rescanning basically).

Yes, but I'm not talking about the startup scan (I agree that's a rescan). The point is that file monitor will update MM with track changes by other programs without any scan (just with file monitor enabled) and that the option does not apply in that scenario.

[Lowlander]

Are you saying that the startup scan of the File Monitor does follow those settings, but not while MediaMonkey is running? That seems confusing. In that case it should be better documented in the Help.

[nohitter151]

Are you saying that the startup scan of the File Monitor does follow those settings, but not while MediaMonkey is running? That seems confusing. In that case it should be better documented in the Help.

No. The file monitor is independent of the startup scan or any rescanning of any kind. What I mean is, the setting to not update the database with info from the tags applies only to any kind of rescanning, not to the actual file monitor.

[Lowlander]

Okay, I considered them part of the same as the startup scan is an option of the File Monitor.

[nohitter151]

Okay, I considered them part of the same as the startup scan is an option of the File Monitor.

I still don't think you get what I am saying. In the OP's case, for example, the tag changes probably are not coming from the startup scan, since he has the option set not to update tags on a rescan. Rather, what is probably happening is that he is using the Picard tagger on the same tracks that have file monitor enabled on them. MM detects those tag changes in real time (not with any rescan) because of the file monitor and imports the tag changes, because the option he has set only applies to rescanning (and the startup scan, etc.)

[Teknojnky]

monitored folders are real-time updated in mm, if you don't want them updated then don't monitor them.

startup scan and manual scan, you can have scan (to pick up new files) without picking up modified metadata, but unchecking the 'Update track info from tags when rescanning files' option.

it seems pretty clear to me.

monitored folders is not 'rescanning'.

startup scan, and manual add/rescan is 'rescanning'.

[Anamon]

In the OP's case, for example, the tag changes probably are not coming from the startup scan, since he has the option set not to update tags on a rescan. Rather, what is probably happening is that he is using the Picard tagger on the same tracks that have file monitor enabled on them. MM detects those tag changes in real time (not with any rescan) because of the file monitor and imports the tag changes, because the option he has set only applies to rescanning (and the startup scan, etc.)

Yes, this is exactly what I was referring to.

So the consensus is that the file monitor is not supposed to adhere to the option in question? It would irritate me a bit, because I was pretty sure (although not 100% positive) that this is not how it was in MM2.

And while you guys are right that the option label does not explicitly mention the file monitor, if you activate UI tooltips and hover over the option, the tooltip description actually says that the option applies to both manual rescans and files monitored by the File Monitor. So there is a problem either way, whether it is a bug that the File Monitor ignores the option, or the tooltip is incorrect. However, I don't see a real reason for why the File Monitor should behave differently.

In my view, the File Monitor is a convenience option to initiate rescans automatically instead of manually, but should otherwise behave identically. Maybe I am missing some special use case, but I can't think of a reason why people, if they say in the options menu that they don't want tag changes to be reflected in the MM database, would want this to be handled differently for monitored folders.

It would be great to get an official word from a developer on this: is it an intentional distinction, or an oversight?

[Anamon]

Edit: This is sort of a summary post, moved here from a separate thread and joined with the previous discussion, which used to be a topic in "Need help".

I thought this is as good a time as ever to formally report this as a bug, since the application clearly does not do what the documentation suggests. So to sum up: in short the problem is that the File Monitor, unlike manual rescans, does not respect the user's setting of the "Update file info from Tags" option.

Case 1 with manual rescan, here everything works as it should:

1. Add a file to MM's library and set artist tag to Old artist.
2. Ensure option Update file info from Tags when rescanning files is disabled.
3. Change artist tag to New artist using an external application such as Mp3Tag.
4. Rescan the file in MM using Add/Rescan files to the Library.

What should happen?
The track should still have artist Old artist in MM, but show up under the Unsynchronized Tags node. The New artist tag is only inferred when explicitly synchronising tags.

What actually happens?
Exactly what should happen.

Case 2, exactly the same procedure with a File Monitor, fails:

1. Add a folder to MM's File Monitor and set the artist tag of a track contained therein to Old artist.
2. Ensure option Update file info from Tags when rescanning files is disabled.
3. Change artist tag of the monitored file to New artist using an external application such as Mp3Tag.

What should happen?
The track should still have artist Old artist in MM, but show up under the Unsynchronized Tags node. The New artist tag is only inferred when explicitly synchronising tags.

What actually happens?
Without any notice, MM automatically infers the New artist tag and updates its library. The file does not show up under Unsynchronized tags ever. The Old artist tag is irrevocably lost.

The tooltip of the Update file info from Tags when rescanning files option states: "This causes all Tracks that are re-added (either manually by clicking 'Add Tracks...' or automatically via the File Monitor) to be updated [...]". It does not make a distinction in how the option should influence manual rescanning versus the File Monitor. Which is good because such a distinction would not make much sense.

I think this is a pretty serious bug since the main reason to disable the automatic inferral option is for people who, like me, want to use MM's own tag database as sort of a "backup" from which file tags can be restored to the ones set in MM, should an external application mess up the tags. This is the way the option should work according to documentation, and also the way it works when only manual rescanning is used. I am also pretty sure that it worked that way in MM2.

[zephyr]

Hi all,

I found this after noticing the continuously monitored files in my library were not reflecting the new BPM data added by MixMeister.

Is this still a known bug? V4.0.2.1462 portable. First I thought I just had lots of m4as that weren't being scanned, but on closer inspection (auto playlist music in M:\Music\Artists that isn't m4a) found this



This folder (M:\Music\Artists) is one of my 'scan continuously', but the modified timedate stamp wasn't picked up by MM4s File Monitor. Manually running the re-scan of this 100Gb portion of my library now... more info soon.

Any info re what happened with this BUG would be sweet. Cheers

Jonny

[zephyr]

As I refresh the auto playlist of unknown BPMs I see the tracks dropping, currently at 10564....10499...

The remainder after the library rescan will be scanned by the external tool, and I'll keep an eye on this bug. Thanks again.

Gonna run with startup file monitors to see if they are similarly affected. The bug seems to only affect files modified by MixMeister. I have no idea which IDv I'm using (I can't! It's enough with artists, albumartists, albums, bpms, playlists counts and ratings and bitrates and.... yeah we love good music)

Prior to BPM analysing the same file monitor was working successfully, as expected, bug free, while the amazing mini lyrics embedded the retrieved lyrics metadata.

Happy to take direction and try and obtain more specific data. Analysing...


Thanks!

Jonny

[zephyr]

Update: File Monitor is still working to continuously update lyrics tags obtained via MiniLyrics...

Manually scanning updates the tags of the files in the library.