"Timer" still runs while buffering content

I can confirm this issue (BQ)

hmm this seems like a bug in the media-hub platform service since podbird just hands over the audio stream url to it and lets it handle everything like the cache, playback etc. Adding media-hub to this bug project.

This bug will capture the fact that media-hub and qtubuntu-media do not report to the client app when a playback stream is buffering. Once this is added, Podbird can know when the backend is buffering and take appropriate action such as not updating the progress timer.

Jim - I'm not sure that's quite the issue here; Podbird only reports the play position that media-hub supplies, the underlying problem is that media-hub is still advancing the play position even when it's not getting new data fast enough over the network (without playing anything back) so it actually ends up skipping part of the audio file. If you play a track and then lose data coverage for 10 seconds due to poor signal when the signal returns the audio playback is 10 seconds further into the track (i.e. you've missed 10 seconds of playback).

@Michael: we haven't done much optimization for the network streaming applications in media-hub yet, so I'm not surprised to see a bug like this. It's been on the ToDo list to better handle and actually report when buffering the streaming media. Although with your case I'm not sure why the position continues to increment even when playback is stalled due to a buffering situation. GStreamer should have paused the pipeline in that case. Can you clear out your media-hub log and then get podbird into this situation and attach the media-hub log to this bug?

My soundcloud app is also affected by this one, also right now I have no way of knowing if the track is being buffered or not since once the playback state turns to 1 it never changes to 0, that's probably because our backend does not have the buffering signals.