Thanks.. that was more consistent with my experiences but I do use wifi a lot.

In any case.. before your reply I'd already gutted pyRadio. I'm about 90% or so done with completely rebuilding the way the backend works. I'm much more comfortable with this method anyway.

Originally the radioplayer thread and main pyRadio UI class were running completely asynchronous of each other. The UI when you would hit a button would merely set a variable and the player thread running an almost infinite loop with 0.5 second sleeper would see it, reset it, and do something. In theory.

I knew when I started it was a horrible design but I couldn't think of a way around my biggest problem. In PyQt4 if the main UI thread locks, the whole damn Ui stops updating. I couldn't, for example, load the UI with a loading screen, automatically start the login process, then if you've already played a station before grab a playlist and start the song. So you ended up waiting that entire time before pyRadio's initial UI even showed up. I could just see people clicking pyRadio 8 times thinking its not doing anything while waiting.

So I worked this convoluted system of giving the radio thread variables and it throwing back signals to my app. It was sub-optimal, at best.

Now I've redone it completely. Instead of variable/signals I am calling the radios functions directly (like I originally wanted) but in order to keep the UI from locking my network calls are getting called via a singleShot timer with like a 100 ms wait . Still probably not the best way to do it, but it certainly makes a helluva lot more sense in the code. No more Ping Pong.

This should reduce the random gremlin in the code as well. We'll see. At this rate I should have pyRadio back to feature complete by tomorrow sometime and upload it. You should notice nothing, except I'll be redesigning the create station process while I'm at it.