First thing I would recommend is repair of MM database. The behavior you describe is strange, inconsistent, and does not make much sense, there is no tagging on playback or app closing. I guess the audio file on the disk is untouched (check it really miss the main tags in Explorer) and the problem ...

Hi, we tried with RDP and with virtual PC and cannot reproduce. It is likely problem with some specific system and drivers, as it looks like some system call is hanging and blocking correct app close. Could you please generate debug log (see 4b) here ), zip it and attach to user ticket or send link ...

The main problem was with libraries containing many linked artworks saved to files. Such were still not handled correctly during rescans in the last builds, including 3209, and were slowing down every rescan a lot, should be ok in the next build.

Thanks! I was just prepared to try the same, as from your last log it looked it is somehow caused by the artwork files.
It should not last so long anyway, I will check it.

ruebennase56: by "Vanilla 3209" is meant separate portable clean installation. You can install last version (3209) as portable to some empty folder, run it, set the same preferences of scanning in Options - Library, scan your 5000 files and then restart MM and try rescan, whether this time it will ...

ruebennase56: Can you please generate new debug log for me with rescan of files (on your current installation, where you experience slow rescans - i.e. scans of files already present in your DB). Note, that with DbgView running you cannot measure time, because logging slows things down a lot. Test ...

Even with the changes in options a rescan still takes about 45min :'( Do you have DbgView running? Sending debug messages also slow things down a lot. Then in case you have checked option "Update file info from tags when rescanning files" you should have also "Only for files with changed timestamp ...

Build 3206 is as slow as build 3203. Just noticed the reason - you have "Analyze files for duplicates" in Library options set ON! This option causes, that MM has to compute checksum from the contents of each file and it needs significantly more time, as it reads a lot more data for every file. Try ...

There is really something odd in the last builds, causing slower scanning, inserted to bug database: https://www.ventismedia.com/mantis/view.php?id=21954

ruebennase56: and do you mean really rescan of previously scanned files? The fix was related to files already present in DB, which were not changed since then, and even then slowed down rescan a lot.

Btw. it seems scanning of (new) video files is somehow slow, analyzing.

Fixed, in the next version rescans should be significantly faster even for libraries with many linked external artworks.

The speed is slowed down most probably because you have a lot of artworks in external files, and new versions check these external files on rescan. But thanks for the log, I think I have idea how to speed it up (besides option to switch this check completely off), will try soon.

innergeek: it seems it was only coincidence, that MM was looking at these files just before crash (probably were visible in some view). But I noticed in your log many errors during parsing files with opus extension, they are in folder named ".... [flac]", what are these files exactly? Could you ...

I can confirm, that Music app in iOS 26.2 seems to not support disc/track numbers with slash, ignores them and use alphabetical sorting then.

Problem was fixed, it should be a lot better from the next beta build. Scan time could be somehow slower, because new version now checks also existence of external artworks during rescan (we consider to make it optional too), but the main problem was related to the unwanted "updated" flag assigned ...