Metadata wirte to file tag fails sometimes in Win 10

[Daniel Schürmann]

The metadata export to file tag "sometimes" fails on WIN 10.
This was test on a virtual box Win 10 image.

There seems to be a file locking issue on windows that prevents to write the metadata at all testing wit plain 2.3.1:

Debug [Main]: MetadataSourceTagLib - Exporting track metadata into file "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3" with type 3
Critical [Main]: MetadataSourceTagLib - "Die Quelldatei kann nicht entfernt werden" - Failed to rename the original file for backup before writing: "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3" -> "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3_orig"
Warning [Main]: MetadataSourceTagLib - Failed to save tags of file "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3"
Warning [Main]: Track - Failed to export track metadata: "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3"
Debug [Main]: TrackCollectionManager - Saving track "C:/Users/dasch/Music/Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3" in internal collection
Debug [Main]: TrackDAO: Saving track 3 QFileInfo(C:\Users\dasch\Music\Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3)
Debug [Main]: TrackDAO: Updating track in database 3 QFileInfo(C:\Users\dasch\Music\Bata Illic - Ich möcht der Knopf an Deiner Bluse sein.mp3)
Debug [Main]: BaseTrackCache(0x1e30431cf30) updateIndexWithQuery took 0 ms

My first Idea was that this this is because of a looking up the file properties in windows explorer? But this also happens when I do not touch the file at all with other applications than Mixxx. It also happens after a fresh restart of Windows.
It is a Windows 10 Runnning in a virtual Box.

Interestingly the renaming works after I have loaded the track into a deck and edit the metadata while paying.

[Daniel Schürmann (daschuer)]

This is IMHO an important bug because if the metadata export does not always work, you cannot rely on it and the whole feature is kind of moot.

I am not sure what is the best solution, and if we are ever able to fix it entirely because on windows we don't know when a virus scanner kicks in or such.

For now I think we must not fail silently, leaving the inconsistent state.

We may revert the edit and issue a pop up or such.

Or make the dirty flag persistent to delay the metadata write across Mixxx restarts.
Ideas?

[Daniel Schürmann (daschuer)]

It seems to be a common issue that renaming a file after writing it fails because of indexer of virus scanner access.

I think this https://stackoverflow.com/questions/11021639/overwriting-files-in-windows-by-renaming-randomly-fails post matches our issue.

I am not sure if the ReplaceFileA Api function is able to work around it:
https://docs.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-replacefilea?redirectedfrom=MSDN

Maybe it fixes the issue of multiple file handlers when accessing the Windows API via QFile.

This will be at least a workaround for the birth time issue in https://bugs.launchpad.net/mixxx/+bug/1955314

[Daniel Schürmann (daschuer)]

The issue was a missing close() after reading the file stream properties. This is quick fixed here:
https://github.com/mixxxdj/mixxx/pull/4586 for 2.3
and cleaned up in https://github.com/mixxxdj/mixxx/pull/4584 for main.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10620