GNOME Bugzilla – Bug 469490
Audioscrobbler plugin randomly stops submitting
Last modified: 2008-02-13 07:45:35 UTC
When I start Banshee, the Audioscrobbler plugin works fine. After about ten songs, the plugin stops submitting to last.fm. One song will remain in ~/.config/banshee/plugins/AudioscrobblerQueue.xml. If I click on the Audioscrobbler entry in the Tools menu and disable and then re-enable song reporting, AudioscrobblerQueue.xml will fill up with the previously missing songs (including the currently playing song, assuming that it has been playing for long enough that it would normally be reported. After that, however, songs are still not submitted from AudioscrobblerQueue.xml, and the disable-reenable trick does not work. This behavior happens on SVN trunk (although I am using the pre-ng-merge branch right now). I tried running banshee --debug, but it displayed no useful output.
Actually, when Audioscrobbler is disabled/re-enabled, the following is reported with banshee --debug: Debug: [8/23/2007 2:04:28 AM] (Audioscrobbler stopping protocol engine) - Failed to get the request stream: System.Net.WebException: Aborted. at System.Net.HttpWebRequest.EndGetRequestStream (IAsyncResult asyncResult) [0x00000] at Banshee.Plugins.Audioscrobbler.Engine.TransmitGetRequestStream (IAsyncResult ar) [0x00000] in /home/martey/code/others/banshee-pre-ng-merge/src/Plugins/Banshee.Plugins.Audioscrobbler/Engine.cs:280 Debug: [8/23/2007 2:04:30 AM] (Audioscrobbler starting protocol engine)
Which distribution are you using? Are you using NetworkManager for your network connection? If so, with a static or dynamic IP? (I'm thinking here of bug #349586.)
I am using Ubuntu Gutsy. I am using NetworkManager, but I have a dynamic IP (through wired ethernet). Unlike bug #349586, streaming from radio stations work. The fact that the songs are neither being placed in the queue XML file nor sent to last.fm is the main issue that concerns me; this should not happen.
The latest revision of the stable branch is still having this behavior, despite the fact it displays "Warning: [11/21/2007 2:01:05 AM] (Cannot connect to NetworkManager) - An available, working network connection will be assumed" when started in debug mode.
I think my patch attached to bug #501405 solves this issue. Please test it.
*** Bug 502375 has been marked as a duplicate of this bug. ***
I don't think that NM has anything to do with this bug. Sometimes the plug-in just waits endlessly for the RequestStream that never arrives. I've added a timeout in my patch mentioned in comment 5. If the connection times out and the plug-in tries again all is well again. So bug #502375 might not be a duplicate..
(In reply to comment #7) > I don't think that NM has anything to do with this bug. > So bug #502375 might not be a duplicate.. My mistake; I had been looking at this bug and the other and had pasted the incorrect one. Sorry about that.
I can confirm this behavior as well. If there is any output I can send I will be happy to. It seems to be quite random.
And here is the debugging info I get: ** Running Banshee in Debug Mode ** ** Running Mono with --debug ** Debug: [2/7/2008 9:42:37 PM] (Loading audio profiles) - /usr/share/banshee/audio-profiles Debug: [2/7/2008 9:42:38 PM] (GStreamer pipeline does not run) - audioconvert ! xingenc bitrate=128 ! id3v2mux Debug: [2/7/2008 9:42:38 PM] (GStreamer pipeline does not run) - audioconvert ! fluwmaenc bitrate=64000 vbr=false ! fluasfmux Debug: [2/7/2008 9:42:38 PM] (Default player engine) - GStreamer 0.10 Debug: [2/7/2008 9:42:38 PM] (Audio CD Core Initialized) - Debug: [2/7/2008 9:42:38 PM] (Testing device for DAP support) - /org/freedesktop/Hal/devices/volume_uuid_59BD23B742F40242 Debug: [2/7/2008 9:42:38 PM] (DAP has not been added) - /org/freedesktop/Hal/devices/volume_uuid_59BD23B742F40242 Debug: [2/7/2008 9:42:38 PM] (Testing device for DAP support) - /org/freedesktop/Hal/devices/volume_uuid_C634253F342533B9 Debug: [2/7/2008 9:42:39 PM] (DAP has not been added) - /org/freedesktop/Hal/devices/volume_uuid_C634253F342533B9 Debug: [2/7/2008 9:42:39 PM] (Enabled multimedia keys support) - Using org.gnome.SettingsDaemon Information: [2/7/2008 9:42:39 PM] (Starting Smart Playlist Auto-Refresh) - Time-dependent smart playlist added, so starting one-minute auto-refresh timer. Debug: [2/7/2008 9:42:39 PM] (Audioscrobbler starting protocol engine) - Warning: [2/7/2008 9:47:38 PM] (Audioscrobbler upload failed) - invalid authentication Failed to get the response: System.Net.WebException: Error getting response stream (ReadDone1): ReceiveFailure ---> System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Connection reset by peer at System.Net.Sockets.Socket+SocketAsyncResult.CheckIfThrowDelayedException () [0x00000] at System.Net.Sockets.Socket.EndReceive (IAsyncResult asyncResult, System.Net.Sockets.SocketError& errorCode) [0x00000] at System.Net.Sockets.Socket.EndReceive (IAsyncResult result) [0x00000] at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x00000] --- End of inner exception stack trace --- at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x00000] at System.Net.WebConnection.ReadDone (IAsyncResult result) [0x00000] --- End of inner exception stack trace --- at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000] at Banshee.Plugins.Audioscrobbler.Engine.TransmitGetResponse (IAsyncResult ar) [0x00000] in /home/family/banshee-stable/src/Plugins/Banshee.Plugins.Audioscrobbler/Engine.cs:310
(In reply to comment #5) > I think my patch attached to bug #501405 solves this issue. > Please test it. Can anyone test this patch to see if it helps?
I've committed the patch from bug 501405, if anyone cares to build stable and test it, please let us know if it solves the issue. Then we might be able to close this one as well.
I'd be happy to, but I don't know what it means to check a patched build. If you can explain I will be able to do it. If you can also explain how generally I am able to test a patch that is committed I will also appreciate it. Thanks.
Asaf: I have integrated the patch into our source tree. If you could do a checkout of the current stable branch and test it, we'd be very thankful. The current stable branch is here: http://svn.gnome.org/svn/banshee/branches/banshee/stable/
..and if you need more help, feel free to hit up the mailing list. :)
Hi, Ok it seems to be working correctly now. I checked a few songs and it is listing them on last.fm I have a problem the first time I opened banshee, it wrote something like: cannot upload audioscrobbler... something.lastfm I showed this in a message window, not in the terminal (I did not open through the terminal). I know I should have written it down, but... habit I just clicked OK. The next time I opened banshee it did not happen. So, maybe it was something to do with the first opening of a new install or something. If it shows again I will write down the info. Other than that I think that the scrobbling works. Maybe if someone else can confirm that it is working you can close the bug. Thanks for the help.
Created attachment 105120 [details] screenshot of the error message Here it happened again. I am attaching a screen shot since it does not allow to copy paste. It is still scrobbling BTW in spite of the message. Hope this helps
(In reply to comment #17) > Created an attachment (id=105120) [edit] > screenshot of the error message And you only have gotten this error since applying the patch from bug 501405?
yes, I attached the error before, and it was in the terminal, this one is in a message box.
Created attachment 105125 [details] The problem gets a little crazy Here you can see that the problem is getting a little crazy. It sends the message every few minutes, makes banshee jump up (I moved the windows, they are actually stacked on one another) so it is impossible to work on something else and listen to music. I think this bug is critical because of that. If there is any test you need I will be happy to do it.
Thanks for testing the patch. I mentioned the error on bug 501405, and I think that's where the discussion of this error should continue (since it seems to have been caused by it). Since it at least fixes the scrobbling problem, I'm going to tentatively mark this as FIXED. The patch's bug report, however, will remain open pending some work to be done on it. If anyone can reproduce the behavior here, feel free to reopen this.