Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random swapping covers #8618

Closed
mixxxbot opened this issue Aug 22, 2022 · 10 comments
Closed

Random swapping covers #8618

mixxxbot opened this issue Aug 22, 2022 · 10 comments
Labels
Milestone

Comments

@mixxxbot
Copy link
Collaborator

Reported by: daschuer
Date: 2016-07-27T21:57:53Z
Status: Fix Committed
Importance: Medium
Launchpad Issue: lp1607097


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

@mixxxbot mixxxbot added the bug label Aug 22, 2022
@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2016-07-27T22:03:59Z


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

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2016-07-27T22:13:24Z


http://doc.qt.io/qt-5/qbytearray.html#qChecksum

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2016-07-29T19:31:10Z


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?

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2016-07-30T09:01:37Z


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?

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2017-11-11T16:11:55Z


#996

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2017-11-11T16:12:41Z


Should this be fixed for 2.1 or postponed?

@mixxxbot
Copy link
Collaborator Author

Commented by: uklotzde
Date: 2017-11-11T21:09:09Z


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.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2017-11-11T22:10:44Z


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.

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2018-09-20T18:40:23Z


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

@mixxxbot
Copy link
Collaborator Author

Issue closed with status Fix Committed.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@mixxxbot mixxxbot added this to the 2.4.0 milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant