-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fail early in case Taglib 2.0 is found #12709
Conversation
fcd0804
to
9d7c566
Compare
Can we merge this soon? We really have to avoid brute force patches that make Mixxx build with Taglib 2.0 without proper testing- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how likely is it that this will cause issues for package maintainers? Is is reasonable to expect taglib>=1.11 to be available everywhere?
It is very likely that everyone has Taglib 1.11 above since even Ubuntu Focal 20.04 LTS has it. |
This will likely cause trouble for the Linux Arch and OpenBSD package maintainers, because they have decided to not put Taglib 2.0 in a separate namespace. This is not an issue for Tagging software out there, but it is an issue for all Media players that sync their internal database to the file tags. Fixing this seems to be the most pressing issue for 2.4.1 |
Great. so Mixxx 2.4.1 shipping taglib 2 is reasonable milestone? |
The issue is that all users of these bleeding edge systems can't even not use Mixxx 2.3.6. because of the binary incompatibility of Taglib 2.0. |
Co-authored-by: Swiftb0y <[email protected]>
115292f
to
4d02b1b
Compare
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. LGTM.
2.5 build fails on Arch currently. I installed taglib1 from the AUR, but it still fails.. |
Can you post the terminal output of the failure? |
|
diff --git a/src/track/taglib/trackmetadata_ape.cpp b/src/track/taglib/trackmetadata_ape.cpp
index c370c6a7f9..b4af3b5afb 100644
--- a/src/track/taglib/trackmetadata_ape.cpp
+++ b/src/track/taglib/trackmetadata_ape.cpp
@@ -59,7 +59,7 @@ bool importCoverImageFromTag(QImage* pCoverArt, const TagLib::APE::Tag& tag) {
if (tag.itemListMap().contains("COVER ART (FRONT)")) {
const TagLib::ByteVector nullStringTerminator(1, 0);
TagLib::ByteVector item =
- tag.itemListMap()["COVER ART (FRONT)"].value();
+ tag.itemListMap()["COVER ART (FRONT)"].binaryData();
int pos = item.find(nullStringTerminator); // skip the filename
if (++pos > 0) {
const TagLib::ByteVector data(item.mid(pos)); Works for me. But if you crashed on this likely means that mixxx builds agains taglib 2.0 |
What works for you? Building 2.5-alpha on an up-to-date Arch machine with taglib1 from the AUR?
2.0 is installed currently, hmm. FWIW/clarity, here is the file listing of both taglib and taglib1;
Edit: https://aur.archlinux.org/packages/taglib1#comment-955407 |
This should allow to use the new taglib1 package: #12760 |
This makes the build error because of Taglib 2.0 explicit.
#12708
I am strictly against hacking a support in to 2.4-beta, because it requires a good amount of testing.
Any issue will put user data on a risk
See also the discussion about the new " / " separator in multi-valued fields
#12613