Update file info from tags when rescanning files not working

[MikeGahrns]

Running the latest 5.1.0.2819 build.

Outside of MM5 I updated some .mp3 files. I wanted to have the MM5 db updated with the changes.

Under Tools, Options, Library I have CHECKED "Update file info from tags when rescanning files" and UNCHECKED "Only for files with changed timestamp or size".

In MM5 I do a File->Add/Recan files to the database and the changes from the changed .mp3's are not incorporated into the MM5 db.

When I do the rescan in MM5, it take approx 1 minute for 23,000 files, which is about the same time as MM4 takes when "Only for files with changed timestamp or size" is CHECKED. In MM4, when "Only for files with changed timestamp or size is UNCHECKED, the scan takes about an hour.

I suspect that MM5 is skipping over all of the files when it does the rescan even though I tell the UI to rescan all files.

BTW, MM5 at the end of the scan says "Updated 23,000" files, but I don't think it updated any.

[Lowlander]

How did you edit the files outside of MediaMonkey? Did MMW4 see the changes?

[MikeGahrns]

The file edit was I changed some properties with MM4, that MM4 will write into tags in the .mp3 file. So yes, the MM4 sees the changes.

MM5 when first building its db is reading the info from the tags correctly on first build of the db

e.g. With MM4 I added something to field custom1, and when MM5 builds its initial db it reads and has the info in custom field1. If with MM4 I subsequently change field custom1 in the .mp3 and then rescan with MM5 (with the option to rescan everything, not just new size or time) the change to field custom1 is not picked up. And as I mention, the rescan is very fast. When I do a rescan with MM4 to rescan every file it takes about 60x longer

[Lowlander]

I'm unable to reproduce. Changed the value in MMW4, did a rescan with timestamp option enabled (as MMW4 changes this by default) and the change was picked up. Changed another value in MMW4 with timestamp disabled, scan was slower, and change was picked up.

Are you sure you're scanning the correct files and that MMW4 is set to save them to the files? For testing you may want to narrow the scanning scope to just that location.

[Rob_S]

For a simple test to reproduce this, I edited one file album name using windows explorer under details.

MM5 2819 picked up the change on its startup scan.

Just for comparison, try editing one of the non-custom fields to see if that makes a difference.

[MikeGahrns]

Thanks Rob and Lowlander.

I think I have found where the issue is.

In MM4, I was running "Playlist in Mainwindow". It adds playlists to the custom1 field.
If I run MM5, on first scan, it will show in custom1 all the playlists the song is in. This implies to me that custom1 is being correctly written as a tag in the .mp3 file.

If I use MM4, and move the song into different playlists, "playlist in mainwindow" updates the custom1 field accordingly. However, when I do the rescan in MM5, the custom 1 field is not updated. I noticed that in file explorer, the "date modified" of the .mp3 is not updated either. So I am not sure how "playlist in mainwindow" is updating the tags in the custom1 field in the .mp3s. It seems that the custom 1 tag is somehow being updated, but the .mp3 file's date modified is not.

If I use MM4 and manually update the custom 1 field, then the file's date modified is changed, and MM5 will show it correctly.
If I use MM4 and manually update a different field like composer, and also use "playlist in mainwindow" so that custom1 is updated with new playlists, then the date modified of the file is changed, and on rescan MM5 will pick up the new composer and also the new playlists that "playlist in mainwindow" added to the custom 1 field.

It seems like when "playlist in mainwindow" is updating the custom 1 field, somehow the tag in the .mp3 file is being updated, but the .mp3 files date modified is not being changed. I wouldn't have thought this was possible. But as best I can tell, when in MM4 I add an .mp3 to a playlist, "playlist in mainwindow" will update the .mp3 with a new custom 1 tag, but the date modified of the .mp3 is not updated. On MM5 first build of the db, it will correctly have all of the info in custom1, but it will not be able to pickup changes in MM4 made by "playlist in mainwindow" since it somehow updates the files .mp3 tag without changing the date modified of the file. I do see that file date access is changed. The file system has a lot of different "dates" and wonder if this is coming into play.

In MM4, when a field like custom1 is changed, how does that change trickle down to get stored as tag in the .Mp3?

It seems like if I manually change something through MM4 UI it will get written to the tag, and the file will have an updated "date modified". If done programmatically through "playlist in mainwindow", it seems that the tag is updated in the file, but the file date modified is not and what might be the underlying cause of what I am seeing.

[Lowlander]

Addons don't always have tag changes saved to the actual file. This is likely the problem you're having.

You can use Ctrl+S (Synchronize Tags) to force save changes to the file in MMW4.

[MikeGahrns]

Thanks Lowlander.

Ctrl-S to force synch of tags worked. When MM5 did the rescan, it had the new values from custom1. I also noticed that the date modified of the .mp3 was also updated after the Ctrl -S.

I am curious now....
When add-on apps like these update things, is there an MM4 background progress the gradually updates and writes the tags to the file? I don't think I ever used Ctrl-S to force updates of tags to the files, yet it seemed that most (if not all) had the correct value in the custom 1 tag when MM5 built its initial db. It was just testing an immediate change in MM4 and seeing MM5 not pick the change up that led me to thinking there was an issue with MM5 rescan.

Thanks again for your quick diagnosis of the issue!

[Lowlander]

No, but any tag changes in MMW4 will save all tag changes.

[MikeGahrns]

Ahh...

99.999% of the time I would have spent some time cleaning up my library and manually done some other tag changes. So if those manual tag changes forced the update of the add-on changes then that would explain what I am seeing.

Thanks again!