"Timer" still runs while buffering content

Bug #1448670 reported by Morgan
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Undecided
Unassigned
podbird
Confirmed
High
Unassigned
media-hub (Ubuntu)
Triaged
Medium
Unassigned
media-hub (Ubuntu RTM)
Invalid
Undecided
Unassigned
qtubuntu-media (Ubuntu)
Triaged
Medium
Unassigned
qtubuntu-media (Ubuntu RTM)
Invalid
Undecided
Unassigned

Bug Description

When I listen a podcast on a slow connection, i have the following issue.

I listen to the first 20 seconds, then the content needs to buffer and after ~ 10 seconds (time to load the content) my podcast start at 30 seconds and not 20 seconds (where it stopped).

It seems the "timer" still runs while buffering, it should stop for that time.

Tags: blocked
Revision history for this message
Alexander Dobetsberger (masternoob) wrote :

I can confirm this issue (BQ)

Changed in podbird:
status: New → Confirmed
Revision history for this message
Nekhelesh Ramananthan (nik90) wrote :

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.

summary: - Bug on slow connexion
+ Bug on slow connection
Changed in podbird:
importance: Undecided → High
description: updated
summary: - Bug on slow connection
+ "Timer" still runs while buffering content
description: updated
Changed in media-hub:
status: New → Incomplete
status: Incomplete → Confirmed
description: updated
Revision history for this message
Jim Hodapp (jhodapp) wrote :

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.

no longer affects: media-hub
Changed in media-hub (Ubuntu):
status: New → Triaged
Changed in media-hub (Ubuntu RTM):
status: New → Triaged
Changed in qtubuntu-media (Ubuntu):
status: New → Triaged
Changed in qtubuntu-media (Ubuntu RTM):
status: New → Triaged
Changed in canonical-devices-system-image:
status: New → Confirmed
Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
Changed in media-hub (Ubuntu RTM):
status: Triaged → Invalid
Changed in qtubuntu-media (Ubuntu RTM):
status: Triaged → Invalid
Revision history for this message
Michael Sheldon (michael-sheldon) wrote :

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).

Revision history for this message
Jim Hodapp (jhodapp) wrote :

@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?

tags: added: blocked
Jim Hodapp (jhodapp)
Changed in media-hub (Ubuntu):
importance: Undecided → Medium
Changed in qtubuntu-media (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Omer Akram (om26er) wrote :

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.

Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.