Notices

Take all the time you need dude. The thing is I just shut it down from playing since my last post and I didn't experience any false starts or anomalies using a rock solid WiFi connection.

No cavemen showed up and I didn't do a dang thing but spend the night enjoying the music.

Clean-up the code so you can tweak it easier and track changes but, on the move it feels like the false starts are buffer issues. A false start seems to start playing very soon after the last song was played. There is no "seek" time like I perceive when it moves to a new song normally. It is almost like it is attempting to play the next song in a playlist or something.

I did notice that since this upgrade the amount of time, or the length of a song that is played when there is a false start is shorter. Sometimes only one or two music notes are played instead of 1 or 2 music bars like in the past.

Again, for me it only occurs on the road. Maybe cell tower handoffs are giving you issues.

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.

3.2 is up! Let me know what you think. Backend is completely redone.. and just tonight as I was ready to push it I found the gremlin. Last thing I put back into the rewrite was rotation and the skips started creeping up again. So, this rewrite was actually unnecessary because the gremlin was in something else . I probably wouldn't have ever found it if it weren't for starting over but.. meh. Like I said, I like this new way better .

I truly hope this sees the end of the "random" skipping..

Create station procedure has changed. No more re-using the station drop down to select a new station. It gets it's own dialog window. Let me know if you like it.

Your efforts are most certainly appreciated..

http://pastebin.com/nuKJTbQs

but.. yeah...

well.. that sucks. I hate segfaults... they give me nothing to work with .

Try resetting the config:

That can be run as user. Try that and run it again.

Smooth as silk so far on my end using WiFi. I use it on GPRS, out and about tomorrow, on pretty much the same route as I ran Friday with 3.1...

Smooth as silk before or after you removed the config files?

http://pastebin.com/jhQDeHa4

Here is it working properly after deleting those config files

http://pastebin.com/t6AmRiZP

..and here is it *not* working properly after closing the previous session and restarting.

http://pastebin.com/6qA9F1JR

..and here is it working properly again after I deleted *just* "lastplayed"

http://pastebin.com/2gG3751v

...and here is what happened when i tried it again after that last session. It segfaulted the first time, but resumed the same repeating behavior after i tried it again. This time, I hit ctrl-c inside the console to stop the program. I should note that this doesn't actually *kill* the program, and I have to manually go out to the window manager to actually kill it.

When you get stuck at the MAFW Position 0 .. skip to the next song. It usually wakes up after that. I've gotten that one once or twice as well and can't figure it out. Everything in my code seems fine, it tries to load the URL into MAFW.. but MAFW just hiccups for some unknown reason. I've also had it once or twice just stop playing mid song and looking at a terminal it goes to a BUFFERING and gets stuck at like 69 or 70 and never goes anywhere. I can usually get that to restart by pausing and then playing again.

These shouldn't happen every other time though.. that seems overly drastic. Not sure whats going on in yours.

Maybe if I put in a small 1-2 second pause/wait before loading the first song it might solve your problem. Perhaps I'm flooding MAFW too quickly.

ok, think we got leviathan3k straightened out.. his phone needed a reboot to refresh MAFW.