Bug 14156 - Resume does not continue from the place where paused.
: Resume does not continue from the place where paused.
Status: CLOSED FIXED
Product: SB Radio
Classification: Unclassified
Component: Music Services
: Include FW version in comment
: PC Other
: P2 normal (vote)
: 7.4.0
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-20 09:15 UTC by Caleb Crome
Modified: 2009-10-05 14:35 UTC (History)
4 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caleb Crome 2009-09-20 09:15:50 UTC
I don't know if this is podcast only, but if you add this podcast:

http://www.npr.org/rss/podcast.php?id=35

And play the first item.  Fast forward to somewhere in the middle and play normally.

Then pause, and resume.  Resume does not resume from pause location.  It skips some time -- maybe 10 seconds or more.
Comment 1 Andy Grundman 2009-09-20 10:06:02 UTC
I think it could be caused by inaccurate bitrate detection of the remote file.
Comment 2 Alan Young 2009-09-21 09:07:46 UTC
The problem with pausing a remote stream is that, after a while, the sender gives up and closes the connection. Sometimes the player notices that straight away, sometimes only after resuming. 

To try to cope with this, SC will now stop the player from streaming when paused as soon as the decode buffer is full. It remembers the time (how far into the track) at which the pause happened and then seeks to that position when you try to unpause. If the bitrate calculation is wrong, or variable, then this seek could be off by a bit. I thought most podcasts were CBR, so this should not be an issue.

A different option would be not to stop the streaming when the buffer fills but only when the player notices that the sender has closed the connection. The problem with this is that the player will, in general, not notice until after you resume. This then becomes a premature disconnect while playing, the enhancement to support which was recently reverted due to false positives caused by inaccurate bitrate calculations.

But actually, this may not be the problem here.
Comment 3 SVN Bot 2009-09-21 11:39:44 UTC
 == Auto-comment from SVN commit #28583 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28583 ==

Fixed bug 14156: Resume does not continue from the place where paused. 
Fix seek offset; stream bitrates are measured in kb/s (1000), not Kib/s (1024).
Comment 4 Alan Young 2009-09-21 11:41:07 UTC
Update hours
Comment 5 James Richardson 2009-10-05 14:35:36 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.