Bug #331

Scrobbler 2.0 often doesn't work, freezes the player

Added by CJ Kucera almost 7 years ago. Updated almost 7 years ago.

Start date:
August 05, 2013
Due date:
% Done:


Estimated time:
Affects version:


I'm still trying to track this down more conclusively and find a reliably-reproducible case, but wanted to get it in the tracker anyway.

Since upgrading to Audacious 3.4, the Scrobbler 2.0 plugin has seemed to be extremely unreliable to me. When it screws up, it has a tendency to hard-freeze Audacious (usually at the start of a new track) - the GUI will freeze and not re-draw if it loses and gains focus, and I have to kill audacious with a SIGKILL in order to kill it. Typically in those cases I'll discover that the plugin hasn't actually scrobbled a number of previous tracks as well.

I had very similar issues when trying to set up the plugin in the first place, too - the "Check Permission" button would end up not working and would eventually hard-freeze the process. It took me five or six tries before I finally got a successful "OK" authorization in the plugin, and each failure previously had resulted in me having to "kill -9" the Audacious process.

There's never anything useful on the console when this happens. I suspect that this probably has something to do with the servers not responding properly (or timely, or something) to Audacious' requests, and maybe the new plugin simply isn't handling the problems gracefully? Like perhaps the requests are timing out but the Scrobbler thread just keeps blocking on the connection.

Anyway, that's just conjecture of course. I'll continue to see if I can figure something more reproducible. Perhaps I can find something useful in a packet sniffer...

I should mention that I am seeing this in the Fedora 19 x86_64 package of audacious-plugins, but I did check the .spec file and there's no significant patches applied to the vanilla source (and the scrobbler 2.0 plugin itself is completely untouched). I could compile from a pure vanilla state if you prefer.


#1 Updated by Luís Picciochi almost 7 years ago

Thanks for the report.

Please start audacious with the -V flag, save the output to a file and then attach it here.
When audacious freezes, please attach to it using gdb and get a full trace for all threads using "t a a bt f". Then also attach the output to the report.


#2 Updated by Michael Schwendt almost 7 years ago

Before trying to attach gdb, run "debuginfo-install audacious-plugins" as superuser root.

#3 Updated by CJ Kucera almost 7 years ago

Of course, ever since submitting the bug, I have yet to actually experience this again. I've got the debuginfo packages installed properly, so I should be able to get a reasonable trace for you the next time I see it, assuming that it happens again, anyway. Thanks!

#4 Updated by CJ Kucera almost 7 years ago

Bah, well - you may as well just close out this bug. Since that first round of persistent issues, I've been unable to reproduce this. So either it was some weird transient network thing, or some other strange issue on my box. At any rate, with nothing to really go on, it probably doesn't make much sense to keep it open.

#5 Updated by John Lindgren almost 7 years ago

  • Status changed from New to Rejected

Okay, closing.

Also available in: Atom PDF