Here's 2 free accounts. The 2nd one is the same account as the above video where it never finished buffering. It's just a day later.
I added a counter in on_gst_buffering to see just how many buffer messages Gstreamer was sending. For the mp3 stream I got 38 messages in a little under a sec before the buffer hit 100% for the aac stream I got over 1000 in the 5 secs it took to reach 100%. That seems excessive. Might be the root cause of the random pause bug. Pithos might just be being overwhelmed and the 100% message slips through the cracks. My new buffer logic checks the buffer % every 1/10 of sec during buffering regardless of how many messages are sent. Seems to work better.
Well @glennimoss I'm pretty much done with what I got going on. Highlights of my branch include. 1. More useful state awareness(Playing, Paused, Stopped or Buffering) 2. Got rid of the gstreamer tag handler and use the bitate and codec info provided by Pandora. 3. Use the duration info provided by Pandora for the UI.(continue to use Gstreamer in the background to detect ads.) 4. Disabled download buffering. 5. Turned the buffering behavior into more of a pull behavior. 6. Incorporated your _set_state logic.
Give it a try and let me know what you think. Oh debug mode doesn't work because the test server doesn't send the duration, bitrate or codec info. That would have to be fixed on their side. But it works rather well on a real Pandora account.