Notices

Unfortunately so far this isn't looking hopefully. Been talking with the upstream dev and pianobar itself doesn't do any buffering and adding would be quite a bit of work.

What might end up happening is I completely re-write pyPianobar to tie into libpianobar directly (without using the full CLI pianobar package) - which should give me a little more control on *some* things.. but not sure how much or if it'll help this problem at all. It would probably help in fixing the timeout problem when listening to Pandora for too long straight.

I'm not entirely sure I want to take that on just yet though.

Ok, well, I came across a Python implementation of libpiano here. I currently have a working model that uses that, and sends the audio through gstreamer (I haven't figured out how to tie into MAFW yet).

I'm liking this method because no more hacks getting the album art.. Pandora actually returns it directly from their API. Quite a lot of information is there, actually. So it's looking like I might abandon both pianobar and pyPianobar and re-create a new project (identical to pyPianobar), that does not depend on pianobar at all. It'll be an entirely stand-alone python app.

The biggest issue right now is the XBMC implementation doesn't have thumbs up/down/create stations/etc.. already ported from libpiano's source.. So I will have to work on that. Basically it listens to music, shows the album art, and you can skip songs. That's about the end of it.

I am liking having control over what I'm seeing, and maybe (?) I can work with gstreamer to buffer properly and work better on bad 3G? .. but this is going to require quite a bit more work porting from libpiano's C to python.

Any ideas on what to name the new project (pyRadio?) would help too. I dunno.. just been messing around today, this is definitely in the "doable" category. I'll try the audio in crappier 3G areas and see if it plays any better than the current pyPianobar version.

You're the man! Glad to hear you're finding new ways to improve(which I didn't even think was possible at this time). I'd say if you're going to rename it, why not drop the "py" tag? Its no longer just a Pianobar front-end, so make it something of your own. Like FatalRadio or Station's Saint or something(those are probably terrible examples), but I'm just saying throw yourself some IP in there!

"py" is actually attributed to it's language that it's in. A lot of python-released scripts will call themselves pySomething to indicate they are python apps.

It's certainly not required by any means, it just comes from my Linux side I guess.

http://en.wikipedia.org/wiki/Python_...%29#Neologisms

Im currently running into a snag with this new build. I have added thumbs up/down to it, and adding tired and deleting stations will be easy (creating stations will be trickier).. but currently having issues tracking when the song is finished to play the next one. You can connect a bus to a signal in pyGST (gstreamer bindings) - but every time I do it segfaults for some reason. No error or crash messages, just segfaults. Very annoying.

If I get this working, you as an end user probably won't notice anything at all (unless someone gets me interface changes/tweaks that I decide to use) from the current pyPianobar to the new app, except that hopefully I can figure out the stutter on slower networks and I'll have more control over how the app actually works.

I just don't think continuing to call it pyPianobar v3 is really accurate since it only uses 2 files from pianobar (the keys), and it's a complete v1 rewrite of the software. Calling it pyPandora could have copyright/legal implications I'm thinking.

On that note: it was brought to my attention apps such as this may be against the ToS of Pandora. To date, they have not contacted myself nor the author of pianobar with any complaints to indicate they care - so I'll continue to operate under that assumption. I just wanted to put this out: It'll probably go a long way to keeping them ignoring us if users of these apps subscribe to the Pandora One and send Pandora some $$. While the radio to us is free, they still do have to pay royalties for the songs (as much as I hate DRM, it's not Pandora's fault and they have to abide by it as that is the current standard).

So, subscribe to Pandora, enjoy pyPianobar for now - and hopefully in the next short while I'll have a new, more flexible, *hopefully* lighter weight and better integrated Pandora Radio app for you all.

Well.. fixed that problem. That's about the ugliest code, ever, but gstreamer's bus require a gobject Mainloop. So even though this is entirely an QT app I need to have a gobject.mainloop running in a thread to keep it from segfaulting >.>. Silly.

This new build is nearly ready now, just need to add station management and tired and all of the current features of pyPianobar will be in the new - pure-python solution.

I've also been streaming 3G/3.5G at my house all day and haven't had any problems. But my home has never been a patchy spot. Work tomorrow will be the real test... it's like a dead zone in my building.

Can't wait to test this in my car!

It's done. Want to test it for a dew days.. there's some issues with gstreamer I haven't figured out. Sometimes music just stops playing through the speakers, at first I thought it was buffering but when it plays again it actually moved in the song (or sends the EOS signal and happily starts the next song).. or just pressing "next" starts the next song just fine. So either, with bad internet it downloads no audio but thinks it's still playing, or it just stops sending the audio.. dunno.

It's weird.. so I'm going to watch some debug output for a couple of days.. I took it for a drive and it seemed to hold up significantly better than pianobar did on 3G. But as I said, tomorrow will be the real test at work.

All features on it work.. creating stations, thumbs up/down/tired, FM TX, etc. I'm considering pyPianobar and pianobar both dead projects at this point. You guys got a couple days to get me a new UI (if you want one), or a name (otherwise we're going to get stuck with pyRadio ). I'm not going to let random stopping songs prevent me from uploading to Devel (it'll stop me from pushing to Extras obviously, but more testers are needed to find bugs I'm missing) - I need to re-flash my phone to an out-of-box state and figure out all the exact dependencies I need before packaging it too.

Nice thing is, using Pandora directly, there is tons of information received from their API that I've never known before. Everything from iTunes URL's to Amazon ID's, Low quality stream, etc. So putting in a "buy song" option and everything is actually possible and it'll open a browser to amazon. If you guys see anything on the main pandora flash app, or any of the other mobile pandora apps, let me know - more possibilities are here now..

Well.. I think I prefer this better. pianobar would play a second, stop, play, stop, very annoying and unlistenable.

This just stops if the network is not fast enough to fill the buffer. I watch gstreamer buffering and it stays at 0%.. not tremendously better but significantly less annoying through my headsets. Only happens in really bad areas too, in the normal areas where before pianobar would have issues its working fine.. so it's at least *somewhat* better with gstreamer. I'm still trying to find ways to control the buffer directly.. gstreamer still seems to be using some of it (you'll see it get up to 50% then back to 0% even though no audio played..) - so I want it to pause, wait for a 100% buffer, and play again.. but haven't quite figured that out just yet.

How does the new version work with regard to system events/alert tones? I know the display sleep/wake event interrupting audio was a bit of a mystery, but it was pretty minimal. Alert tones on the other hand make the current app pretty unlistenable if you're txting/im'ing or whatnot since it interrupts the audio completely for a few seconds every time you get an alert.

just wanted to sy i love this app and it ROCKS!