Export metadata export for .ogg files disabled

Bug #1868233 reported by Matthew Laney
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Committed
High
Unassigned

Bug Description

Both the Mixxx manual and the user interface are very misleading when it comes to writing tags out to files. Specifically, the checkbox in the preferences mentioned in section 4.6 is not mentioned anywhere else. The instructions provided earlier in section 4.2.1 indicate that if you choose the "Export to File Tags" option from the context menu, then the tag will be written. Furthermore, if you discover that option on your own in the user interface, it makes no sense whatsoever for it to not actually do the thing it is supposed to do. The fact that it does pop up a warning message that tells you the tags may not be written immediately but will be written when you close the program is even more misleading, because it's providing an additional confirmation that while the action may be delayed it will be taken eventually.

I lost a very large amount of metadata because when changing computers I told Mixxx to write all my tags to my files and then transferred the files to a new computer without transferring the Mixxx database.

I understand the desire to not have the default behavior be to edit the files. However, having a button that says it is writing to the files and then doesn't do it is much worse. I don't see any reason why when a user manually clicks a button to write tags that the tags would not be written. However, if there is a valid reason I don't understand for requiring the box to be checked in the preferences dialog, then the option in the context menu should not exist if the box is not checked.

Tags: metadata
tags: added: metadata
Changed in mixxx:
status: New → Confirmed
importance: Undecided → High
milestone: none → 2.3.0
Revision history for this message
Daniel Schürmann (daschuer) wrote :

It looks like we did not think about his use case. I am sorry you loose data.

What do you suggest to improve the situation?

The code of question is here:
https://github.com/mixxxdj/mixxx/blob/04396a7bbba7d592fd616db7af6ebdb84dc6d9db/src/preferences/dialog/dlgpreflibrarydlg.ui#L134
https://github.com/mixxxdj/mixxx/blob/9da873a777a147a3afadfb3a988ec42112359d1e/src/library/dlgtrackmetadataexport.cpp#L16

Does a changes test fix the issue?

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

After testing I cannot confirm a bug in our implementation.

If you _explicitly_ request metadata export by executing Metadata > Export To File Tags then file tags are written for all selected tracks independent of the preference setting.

The preference setting is only required to _implicitly_ enable export of file tags after modifying track metadata in Mixxx, i.e. to keep file tags in sync with the Mixxx library continuously.

I guess you didn't have write permissions for your audio files while trying to export the metadata explicitly. In this case the Mixxx log contains 2 warning messages per file:

Warning [Main]: MetadataSourceTagLib - Failed to save tags of file "/tmp/filename.mp3"
Warning [Main]: Track - Failed to export track metadata: "/tmp/filename.mp3"

Changed in mixxx:
status: Confirmed → Incomplete
Revision history for this message
Daniel Schürmann (daschuer) wrote :

For my understanding this a string issue.

The hints can be read, as if all metadata from the database is written to the track after Mixxx is closed. This is not the case. Only changes after setting the Export checkbox are written to the file. I can imagine that this can be worse in some translation where translations have been done out of context.

Revision history for this message
Matthew Laney (matthewslaney) wrote :

Hi Uwe,

Thanks for checking on this. After going through the logs, I learned that this is because my files are ogg. You intentionally disabled writing the tags due to a bug in taglib.

https://github.com/mixxxdj/mixxx/pull/2180

Thanks for being proactive with that fix so that we don't all have a bunch of corrupted files.

I still believe that it is problematic to have the failure be transparent. The vast majority of users will never open the log files, so if the failure is completely silent without opening the logs, it creates the situation I had where there's either significant confusion or potentially even lost metadata.

It seems that a fix for taglib has been made but a new version hasn't been released. Can there be some sort of warning in Mixxx about the lack of ogg tag writing support or can we adopt the taglib patch?

Revision history for this message
Matthew Laney (matthewslaney) wrote :

Also, to clarify, I don't know/remember what I did when I was messing with it late last night that got it to update the file tags, but after further testing and looking through the logs, it appears that the checkbox in preferences doesn't have any effect on whether or not it writes the tags for ogg files. It still gives the errors about the taglib bug regardless of whether the box is checked or not.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Bundling TagLib is not an option, we don't have enough resources for this.

It concerns me that their developer(s) don't take such a fatal bug for serious. But this is open-source, everyone is free to decide about getting involved or not. Sorry, I neither have the time nor capacity for yet another unpaid project.

Revision history for this message
Matthew Laney (matthewslaney) wrote :

Understood. I'll see if I can push them or help them somehow to make the release. Can we get some sort of warning in Mixxx and in the Mixxx documentation to indicate that OGG files aren't supported?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

https://bugs.launchpad.net/mixxx/+bug/1833190 is now closed.
We can take this bug as a reminder.

Changed in mixxx:
status: Incomplete → Confirmed
summary: - Misleading info in interface and documentation regarding tag export
+ Export metadata export for .ogg files disabled
Changed in mixxx:
milestone: 2.3.0 → none
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Unfortunately no fix expected in the near future: https://github.com/taglib/taglib/issues/864#issuecomment-631874581

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

TagLib 1.12 with the fix has been released. But it will take some time until it will be available for all platforms and distributions.

Revision history for this message
Be (be.ing) wrote :

Windows and macOS builds are now using TagLib 1.12 as of https://github.com/mixxxdj/mixxx/pull/3615

We do not control when Linux distributions will update taglib.

Changed in mixxx:
status: Confirmed → Fix Committed
milestone: none → 2.3.0
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Matthew Laney (matthewslaney) wrote :

Hi Daniel,

Can you please reopen this? This bug still exists in version 2.3.2 on OSX.

Changed in mixxx:
status: Fix Released → Incomplete
Revision history for this message
Daniel Schürmann (daschuer) wrote :

The post https://bugs.launchpad.net/mixxx/+bug/1868233/comments/11
Is not correct, it was fixed for the 2.4 branch, but not for 2.3.0

See:
https://github.com/mixxxdj/buildserver/blob/4a0e449335bcc2d5d1f0fe10d43b97df3cb4d347/scripts/macosx/build_taglib.sh#L14
and:
https://github.com/mixxxdj/buildserver/blob/32ec7c47ce859aa6554913f3cc26c9d6d4491bad/build_taglib.bat#L3

Unfortunately, we are no longer able to update the build environment with a reasonable effort,
So I suggest to use the 2.4 alpha version instead.

Changed in mixxx:
milestone: 2.3.0 → 2.4.0
status: Incomplete → Fix Committed
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.