After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 469490 - Audioscrobbler plugin randomly stops submitting
Audioscrobbler plugin randomly stops submitting
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Other Extensions
git master
Other Linux
: Normal normal
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-23 06:01 UTC by Martey Dodoo
Modified: 2008-02-13 07:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot of the error message (77.46 KB, image/png)
2008-02-13 06:13 UTC, Asaf
Details
The problem gets a little crazy (190.42 KB, image/png)
2008-02-13 07:41 UTC, Asaf
Details

Description Martey Dodoo 2007-08-23 06:01:01 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.
Comment 1 Martey Dodoo 2007-08-23 06:11:44 UTC
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)
Comment 2 Andrew Conkling 2007-08-24 15:57:06 UTC
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.)
Comment 3 Martey Dodoo 2007-08-27 03:56:42 UTC
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.
Comment 4 Martey Dodoo 2007-11-21 07:27:16 UTC
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.
Comment 5 Pepijn van de Geer 2007-12-05 17:10:32 UTC
I think my patch attached to bug #501405 solves this issue.
Please test it.
Comment 6 Andrew Conkling 2007-12-07 21:57:03 UTC
*** Bug 502375 has been marked as a duplicate of this bug. ***
Comment 7 Pepijn van de Geer 2007-12-07 22:04:06 UTC
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..
Comment 8 Andrew Conkling 2007-12-07 22:05:42 UTC
(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.
Comment 9 Asaf 2008-02-08 05:46:14 UTC
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.
Comment 10 Asaf 2008-02-08 08:26:21 UTC
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 
Comment 11 Andrew Conkling 2008-02-08 21:11:18 UTC
(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?
Comment 12 Ruben Vermeersch 2008-02-10 15:04:19 UTC
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.
Comment 13 Asaf 2008-02-10 19:49:27 UTC
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.
Comment 14 Ruben Vermeersch 2008-02-10 20:09:04 UTC
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/
Comment 15 Andrew Conkling 2008-02-11 02:16:11 UTC
..and if you need more help, feel free to hit up the mailing list. :)
Comment 16 Asaf 2008-02-13 05:36:13 UTC
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.
Comment 17 Asaf 2008-02-13 06:13:09 UTC
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
Comment 18 Andrew Conkling 2008-02-13 06:24:27 UTC
(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?
Comment 19 Asaf 2008-02-13 06:45:14 UTC
yes, I attached the error before, and it was in the terminal, this one is in a message box.
Comment 20 Asaf 2008-02-13 07:41:24 UTC
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.
Comment 21 Andrew Conkling 2008-02-13 07:45:35 UTC
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.