Summary: | musicbrainz does not work anymore | ||
---|---|---|---|
Product: | [Applications] juk | Reporter: | Marco Krohn <marco.krohn> |
Component: | general | Assignee: | Scott Wheeler <wheeler> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | ciasaboark, marshcast |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Marco Krohn
2004-11-14 17:09:37 UTC
Not sure what to tell you; nothing has changed there since before KDE 3.3. Strange. Which libmusicbrainz version do you use? I'll try to investigate further within the next few days. I use the current libmusicbrainz and libtunepimp stable releases, but there haven't been new releases in several months. It's also of note that the trm tool is somewhat different from the MusicBrainz result query; there's a two step process to looking up tracks -- first it checks the audio signature against the TRM server and once it has that value it then makes another trip to the MusicBrainz server to query based on the value received from the TRM server. I believe that the trm command line tool only does the first step. > I use the current libmusicbrainz and libtunepimp stable releases, but there
> haven't been new releases in several months.
That is what I use:
libtunepimp2 0.3.0-2
libmusicbrainz4 2.1.1-3
I don't think that it is related to the libs, since I just downgraded from CVS
HEAD to KDE_3_3_1_RELEASE and it works again.
On my system there is also 2.0.2-9 version of libmusicbrainz. Perhaps there is
some chance, that the wrong lib is used. I don't think so, but I will remove
the old lib and compile HEAD again to see if anything changes.
Yeah, actually I noticed last night that it's not working for me either. I talked to someone else using the "official" client and they said it's not working at the moment either. So it seems to be a server issue, but the maintainer is on vacation for the moment, so it seems that we'll probably just have to wait until he's back. On Monday 22 November 2004 00:26, Scott Wheeler wrote:
> ------- Additional Comments From wheeler kde org 2004-11-22 00:26 -------
> So it seems to be a server issue,
It is my understanding that if it is a server problem then it should not work
for the "old" version of KDE 3.3.1. About 6 hours ago it worked(!) (with
3.3.1, but not with HEAD). Also I used "trm" from command line one minute ago
and it worked too.
philemon: /home/scott/projects/kde/kdemultimedia/juk> cvs diff -r KDE_3_3_0_RELEASE ktrm.cpp ktrm.h | wc -l 0 There hasn't been a single change to that code since before 3.3. -Scott On Monday 22 November 2004 01:00, Scott Wheeler wrote: > ------- Additional Comments From wheeler kde org 2004-11-22 01:00 ------- > philemon: /home/scott/projects/kde/kdemultimedia/juk> cvs diff -r > KDE_3_3_0_RELEASE ktrm.cpp ktrm.h | wc -l 0 > > There hasn't been a single change to that code since before 3.3. O.k. is it possible, that the query works, but the representation not? E.g. there have been two changes in musicbrainzquery.cpp since 3.3.1 I just checked again that 3.3.1 juk works for me right now > O.k. is it possible, that the query works, but the representation not? E.g. > there have been two changes in musicbrainzquery.cpp since 3.3.1 They didn't look significant, but I just reverted them locally for testing just to be sure and they didn't change anything. > I just checked again that 3.3.1 juk works for me right now Ok, just actually tried and sure enough it works in the branch. Weird. Ok, I'm convinced, looking into it now. :-) Ok, this is the commit that did it -- I'm still not sure why... I'll sort that out shortly. M +0 -1 jukui-rtl.rc 1.5 M +0 -1 jukui.rc 1.56 M +125 -120 nowplaying.cpp 1.8 M +72 -21 nowplaying.h 1.3 M +2 -8 playlistsplitter.cpp 1.187 M +8 -4 searchwidget.cpp 1.26 What's the status, is this fixed in 3.2.2? This was never broken in 3.2.x -- if you're seeing it there it probably just means that your packager didn't include musicbrainz when building the kdemultimedia package. Actually incidentally, I can't reproduce this in HEAD anymore, though I'm still not sure what actually caused the problem. On Friday 14 January 2005 18:21, Scott Wheeler wrote: > ------- This was never broken in 3.2.x -- if you're seeing it there it > probably just means that your packager didn't include musicbrainz when > building the kdemultimedia package. > > Actually incidentally, I can't reproduce this in HEAD anymore, though I'm > still not sure what actually caused the problem. I'm using Debian and it still doesn't work for me with the following packages installed: Setting up juk (3.3.1-2) ... Setting up libmusicbrainz4 (2.1.1-3) ... Setting up libtunepimp2 (0.3.0-2.1) ... Setting up libtunepimp-bin (0.3.0-2.1) ... I'm not actually sure what I did that fixed this, but it's working for me on both of my machines, so I'm closing this one for now. If you can still reproduce this with CVS please reopen. I just tried with juk 2.2.1 (kde 3.3.2) for what's it's worth and it doesn't work. Right, and as I said above -- this was a bug against the CVS version that never was in the 3.3.x version -- this was just in CVS HEAD (which will become 3.4). Just having MusicBrainz / libtunepimp installed doesn't activate it; it had to be there when the packager built JuK. Does it actually show up in your menus? Is your proxy configured properly? Did it work in previous versions? On Thursday 20 January 2005 17:44, Scott Wheeler wrote:
> ------- Additional Comments From wheeler kde org 2005-01-20 17:44 -------
> I'm not actually sure what I did that fixed this, but it's working for me
> on both of my machines, so I'm closing this one for now. If you can still
> reproduce this with CVS please reopen.
I can confirm that it works for me too -- thanks :)
On Friday 21 January 2005 19:21, Scott Wheeler wrote:
> ------- Additional Comments From wheeler kde org 2005-01-22 01:21
> ------- Right, and as I said above -- this was a bug against the CVS
> version that never was in the 3.3.x version -- this was just in CVS HEAD
> (which will become 3.4). Just having MusicBrainz / libtunepimp installed
> doesn't activate it; it had to be there when the packager built JuK.
> Does it actually show up in your menus? Is your proxy configured
> properly? Did it work in previous versions?
Sorry, I didn't know if it was supposed to get into 3.3.2 yet -- I thought
it did. So, no news to report then.
Well, MusicBrainz support was in 3.3. However this bug report was for something that happened after we branched away from 3.3 (to work on 3.4) -- the CVS version. This specific bug was not in 3.3. As I suspect from what you said, despite having libtunepimp / musicbrainz installed it wasn't installed on the packagers machine, so support for musicbrainz probably wasn't compiled in. On Monday 24 January 2005 09:53, Scott Wheeler wrote: > http://bugs.kde.org/show_bug.cgi?id=93266 > ------- Well, MusicBrainz support was in 3.3. However this bug report > was for something that happened after we branched away from 3.3 (to work > on 3.4) -- the CVS version. > > This specific bug was not in 3.3. > > As I suspect from what you said, despite having libtunepimp / musicbrainz > installed it wasn't installed on the packagers machine, so support for > musicbrainz probably wasn't compiled in. I'm still more confused about the circumstances of this bug, but just to be clear: I'm using JuK 2.1.1 with KDE 3.2.2 libtunepimp2 0.3.0-2.1 0 libmusicbrainz4 2.1.1-3 from Debian unstable. I am cc:ing ccheney@debian.org, debian-qt-kde@lists.debian.org who are the Debian package maintainers and perhaps can speak on this issue. I don't see the similar bug reported on: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=juk I'm now using juk 3.4.1-0ubuntu0hoary1 and libtunepimp-bin 0.3.0-3 with a trm that supports mp3's "Supported file extensions: .wav .mp3 .ogg .flac" However juk still fails. I'm noob, and have only just come accross the 'bug report' thing - well... in a way that i can understand & read it a little... congrats on such a fine system ;) Down to the 'nitty gritty' of it all - I have the same problem - it wasn't long before i got lost in the jargonness of this thread, and so I dont know how to reproduce or find out why, but if I ask for get info from internet, all i have ever had is an error message saying that juk cannot connect to musicbrainz. been like that since day 1. I'm running juk2.2 on Kubuntu, using -i assume- debian Stable repos, Although it came from the cd. I have apt-get updated, but still no joy. I've also uninstalled & re-installed juk. but still no joy any chance of a reply? No idea. Clearly musicbrainz tagging isn't working and I have no sense that it ever will again. Note that all of the reports of it not working presently are on [K]ubuntu. I've asked one of our Kubuntu folks to look at this, but he didn't get back to me. It works on all distributions that I have access to... On Saturday 10 September 2005 13:23, Scott Wheeler wrote:
> ------- Additional Comments From wheeler kde org 2005-09-10 19:23 -------
> Note that all of the reports of it not working presently are on [K]ubuntu.
I've asked one of our Kubuntu folks to look at this, but he didn't get back
to me. It works on all distributions that I have access to...
Good to know, the reason I left this comment is because I just tried Kubuntu
5.10 Preview Live to test this, and it still didn't work there. But if it's
now working for other Debian people (e.g., 3.1) then we do know its
Kubuntu.
Another semi-relevant note -- this bug was reported against the CVS version and was fixed before that version was released. So the original bug -- which I was able to reproduce -- is completely separate from whatever you're seeing at this point. libtunepimp in Kubuntu is not compiled against libmad, so musicbrainz does not work for MP3 files due to patent issues. It works fine for Ogg files. We would need either patent reform or a libtunepimp that worked with dlopened plugins which could be separated into a separate package to get round this. Appologies to Scott for the delayed reply. *** Bug 111969 has been marked as a duplicate of this bug. *** *** Bug 113479 has been marked as a duplicate of this bug. *** |