Bug 15727 - Skip to end of episode = timestamps are off, "rebuffer error" + playback hangs
: Skip to end of episode = timestamps are off, "rebuffer error" + playback hangs
Status: RESOLVED WONTFIX
Product: SB Touch
Classification: Unclassified
Component: UI
: 7.5.0
: PC Other
: P3 minor (vote)
: 7.5.x
Assigned To: Andy Grundman
: partner_important
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-17 14:43 UTC by dag
Modified: 2011-01-14 13:50 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments
excerpt from /var/log/messages (5.96 KB, text/plain)
2010-02-17 22:45 UTC, Michael Herger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dag 2010-02-17 14:43:30 UTC
One show that will do this is savage love, in popular channel "relationships"

play the episode, 
skip to the end, (let it play on for the last x secs etc)
notice the show will hang...
notice the timestamp info is "off" ie something like  35:36 + -59:45, and that the show doesn't skip to next show, and then you will get a "rebuffer error" popup.

Also the show will never resolve itself of this state you have to manually go back and start another show.

Seen this on a few other shows, will add to bug as I encounter. Bug is only with some shows, not all...
Comment 1 dag 2010-02-17 14:50:54 UTC
Correction - the player will eventually play the next show in the playlist (takes several minutes for it to break free of the "hung" state fyi)

Addition - replicated this issue with the show MSNBC Countdown
Comment 2 Michael Herger 2010-02-17 22:45:14 UTC
Created attachment 6540 [details]
excerpt from /var/log/messages

Alan, Andy - is this looking ok? Should this always be logged or is there something wrong leading to these lines?
Comment 3 Michael Herger 2010-02-18 05:36:15 UTC
Something's odd here: I can reproduce this while connected to test.mysb.com, but running a local copy of mysb.com it's working just fine. Tested with both a Boom and a Touch.
Comment 4 Chris Owens 2010-02-18 10:22:28 UTC
Andy to have a look.  Maybe Michael's issue is important, or maybe we'd need length data from the service.
Comment 5 Chris Owens 2010-02-22 09:18:56 UTC
It's just an error.  Is it that great a hardship to find another podcast and hit 'play'?  We make the best guess we can about the duration of the file, but sometimes we get it wrong.  Should we just disable fastforwarding through podcasts?

If we had an accurate duration, then we could make sure to stop the scan before an error appeared.
Comment 6 dag 2010-02-22 10:49:24 UTC
Yes the bug is classified as "normal" for a reason; it's not major / critical or blocker. It would be worth fixing if it was something simple that took 10 mins. It's also more important than say, a spelling error, so it's not "trivial" either.

Just my thoughts...

Downgrading for clarity 

Yes and keep the FF functionality :) thanks.
Comment 7 Chris Owens 2010-03-08 11:30:33 UTC
Moving lower-priority bugs to next target
Comment 8 Andy Grundman 2011-01-14 13:50:59 UTC
Not possible to always get the correct duration for remote files.