Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

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 last.fm 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.