GNOME Bugzilla – Bug 720359
Banshee fails to scrobble iPod device
Last modified: 2014-01-23 14:41:38 UTC
Banshee every so often fails to scrobble tracks played on the iPod after connecting. Not a single track would have been submitted when the problem occurs. The only way to "fix" it is to delete the file "audioscrobbler-queue.xml" so new tracks will get scrobbled again. This, of course, causes a lot of unsubmitted tracks not being scrobbled any more. The terminal will be flooded with loads of the same exception when the problem occurs: ------------------------------------------------------------------- [Warn 23:08:42.496] Failed to process the scrobble response - System.ApplicationException: Unexpected character '<' at [1:1] (in `Hyena') ... ------------------------------------------------------------------- Attached you'll find the "audioscrobbler-queue.xml" file causing the issue. I have the feeling that it might be caused because I don't scrobble on a regular basis. So the queue will be large and a number of tracks will be too old to be scrobbled. This shouldn't prevent valid tracks from being submitted though. If my assumption is correct then tracks being too old should be removed from the queue.
Created attachment 264104 [details] scrobble queue
Hi Age, you're correct in saying that invalid tracks should not cause everything to grind to a halt. I was under the impression that all of the latest Last.FM patches were included with 2.6.1 but maybe I'm wrong. I am testing with 2.7.0 and while I do see errors I am able to process all 2100+ of your tracks without repeated errors. Let me dig into a bit and see if a later patch fixes your problem for you. Side note: It seems that our current request size limit for Last.FM is a bit too high. I am seeing the errors at below our current limit. I will test a bit and see if I can narrow in on a better limit to decrease or eliminate these problems.
Created attachment 266049 [details] [review] Decrease max allowed scrobble request size Based on testing with this large audioscrobbler-queue.xml file I feel that 6900 bytes is a better max allowed size for the LastFM request. I was seeing some 'Request URI too large' errors with this file until I lowered the limit. While we were handling the errors and trying to submit the scrobble request again we shouldn't be seeing them at all.
Phil, can you confirm that you were testing with banshee master?
Hi Andrés. Good catch. I had forgotten to fully update to the latest master. I am still using the gtk2 branch. I took a look and I don't see any LastFM-related patches that I am missing but the correct thing to do is to test with the latest code. I am going to need to figure out how to install everything I need the compile the latest master. I am running into issues with gstreamer1.0. Let me dig into it and I'll confirm when I've been able to complete my testing.
(In reply to comment #5) > I am going to need to figure out how to install everything I need the compile > the latest master. I got stuck on this as well when trying to compile master to see if the problem is still present. The Banshee website could use an update on this matter since Ubuntu will not have the proper deps in their repositories in the near future.
The reasons we haven't updated the website is: a) The gstreamer-sharp change is just in master, no release has gone out with it yet (2.9.1 will be the first gstreamer-sharp-by-default version). b) These are development releases anyway, so I think it's just easier that you guys ask in the IRC channel ;) The user-focused releases will be likely packaged on time so you don't need to spend time on this.. That being said, you can avoid this problem momentarily by using the old native backend, by passing --enable-gst-native to autogen.sh.
BTW guys, the way to get gstreamer-sharp is simple, git clone from http://cgit.freedesktop.org/gstreamer/gstreamer-sharp/ , autogen.sh --prefix=/usr && make && sudo make install ;)
Thanks for the info, Andrés. I was able to get all of my dependencies worked out and compile the latest master. I also needed to grab the latest gtk-sharp. I did a pre-patch and a post-patch test after updating to git master. The pre-patch test completed successfully but I spotted many 'request URI too large' errors, just as I saw before. We handled the exceptions and tried again and were was able to process all 2100+ scrobbles. Post-patch the errors go away and Banshee processes all 2100+ scrobbles with no hiccups. So while my patch removes the occurrence of the exceptions, which is a good thing, I cannot replicate Age's problem of the errors clogging up the submissions so that none go through. I looked back through the commits and I see this commit that specifically addresses keeping us below the LastFM limit when submitting scrobbles: https://git.gnome.org/browse/banshee/commit/?id=3baa467511ad6661dad1924b88d9a805fc2bb1b2 I can't see any reference to this being included in 2.6.1. I'm pretty sure that this one was not included. Andrés, is there an easy way to check to see what commits made it in? If it is not included with 2.6.1 then I'm betting that an upgrade to the latest master will solve Age's problem.
Phil, not sure I understand comment#9 entirely. I get that you found a commit which is only in master (and 2.9.0) and not stable-2.6 (or 2.6.1): https://git.gnome.org/browse/banshee/commit/?id=3baa467511ad6661dad1924b88d9a805fc2bb1b2 (yes, we decided not to backport this as it was a bit risky, as it could cause regressions). Then, when you say "post-patch", "pre-patch", what do you mean? You mean the patch that you have attached in this bug? If everything works ok with master, then we don't need this patch? Or do we need it?
Sorry for the confusion. Two things: 1) Updating to a newer version will be what resolves the problem for Age. That's the important piece of information. 2) My patch is simply a related improvement that I made while researching Age's problem. The patch lowers the submission size limit because I discovered that I was still sometimes seeing the 'request URI too large' errors, even with the latest git master. Including the patch will stop those errors from occurring. The errors were happening behind the scenes from the user so it's really just a small improvement to the LastFM submission efficiency. Hopefully I explained this better on my second try!
Alright, sounds good! I just committed the patch to master. Age, if you happen to see this again in master (or upcoming 2.9.1) please reopen the bug.
Confirmed, it works in 2.9.1 (git master). Thanks guys.
Brilliant! Please remember there's a way to confirm the fix, it's the VERIFIED status :)