rhythmbox gui is blocked on song change

[Jeremy von Hoff]

With the autoqueue plugin active (which rules, by the way), the RB player is blocked, so the song title, new song notifications, etc. are all stagnant until the similar song search has completed, and the new song is placed in the queue. Then, the gui gets updated.

Can this be threaded so that we don't block the gui? In Lucid, the rhythmbox context panel (or whatever it's called) doesn't block the gui when it retrieves similar artists from last.fm. I figure there's some code in there that's ripe for stealing.

[Eric Casteleijn (thisfred)]

Hi, thanks! :)

This is an issue I've been thinking about.

It is certainly possible to make autoqueue threaded, in fact one of the first iteration was threaded. I never got it to work perfectly, but mostly for lack of trying. There are some issues that make it less than trivial: database access will need its own thread, but a lot of database writes are not asynchronous, (inserts need to return the new database id, for instance) so it would need some sort of callback construction. The reason I abandoned threads is that quodlibet (my main target) added support for coroutine plugins that yield control to the main loop often enough to make things seem async, while still not exploding my brain. (This is why there are yields everywhere, if you've looked at the code.)

Of course rhythmbox doesn't have this, so instead of adding the coroutine generators to a pool, in rhythmbox I just call them until they are exhausted. I'll put on my thinking cap and see if there is some way to make this work nicely in both cases, or at least have the threading code not be too invasive. If not, I may switch back to threading after all, since I agree having the UI freeze for long periods is bad.

I'll have a look at what the context panel does, but since RB is C, rather than python, it may be only broad ideas we can borrow, if it is indeed threaded.

[Eric Casteleijn (thisfred)]

Thanks to a pointer from my colleague Stuart, I found this:

http://live.gnome.org/RhythmboxPlugins/WritingGuide#Doing_things_the_right_way

Which gave me an idea for how to do this, and I think it worked: I already had support for executing code asynchonously and I more or less just hooked that up to the gobject idle_callback.

I have not yet tested it extensively, but it seems to work here (the ui does not become unresponsive for long periods anymore.)

Can you get trunk and test that this improves things for you? (This may or may not have an effect on bug #535149 as well, if so, please make a note of it there, if you could.)

(bzr branch lp:autoqueue)