Random swapping covers

Bug #1607097 reported by Daniel Schürmann
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Committed

Bug Description

I have two tracks which are randomly swapping covers.
It can happen that the Library row shows one cover and the Big cover art shows the other.
After restarting Mixxx it can be the other way round.

Reloading the cover from the file, does not change anything.

Tested with Mixxx 2.1-pre-alpha r5830

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

Both cover have the same hash "166"
It looks a bit short, my maximum hash is "65478"

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

I think that can be solved, by comparing the new cover, and the existing cover with the same 16 bit CRC byte by byte.
If they are not equal, we can add 0x10000 to the CRC. This way we can distinguish them later.

What do you think?

Changed in mixxx:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Daniel Schürmann (daschuer)
milestone: none → 2.1.0
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Using the CRC as unique ID is a failure by design.
I think we should move to a location as unique ID. The CRC can be used to detect changed covers.

All files with the same embedded cover art will have the location of the first occurred track with this cover. If the CRC of the cover at the ID location changes, all other files have to invalidate this ID and fall back to its own location or an other track with the same cover.

We have to make sure that the case works flawlessly when a user exchanges the cover.jpg in a folder.

Any idea?

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

Should this be fixed for 2.1 or postponed?

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

I would recommend to postpone it, because it is more or less an inconvenience and requires substantial changes. Maybe we can come up with a clever strategy how to detect and update existing database entries on the fly.

Cover art from the audio file will be imported together with the rest of the metadata. Since writing metadata back into files is still disabled, re-importing both from the external audio file is dangerous. But we can reload just the cover image, either automatically as required or by providing a new user action.

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

Okay, removing the 2.1 milestone then. If you or Daniel want to commit to fixing it for 2.2, go ahead and assign the bug to that milestone.

Changed in mixxx:
milestone: 2.1.0 → none
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Due to lack of progress, marking Triaged and clearing assignee. Feel
free to revert if it is in fact still in progress :).

Changed in mixxx:
assignee: Daniel Schürmann (daschuer) → nobody
status: In Progress → Triaged
Changed in mixxx:
milestone: none → 2.3.0
assignee: nobody → Uwe Klotz (uklotzde)
status: Triaged → In Progress
Changed in mixxx:
milestone: 2.3.0 → 2.4.0
Changed in mixxx:
status: In Progress → Fix Committed
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:

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.