Bug 9125 - Decoder (and play) should start on stream end even if threshold not reached
: Decoder (and play) should start on stream end even if threshold not reached
Status: RESOLVED WONTFIX
Product: SB 2/3
Classification: Unclassified
Component: Audio
: 86
: PC Other
: -- normal (vote)
: 8.1.0
Assigned To: Felix Mueller
:
Depends on:
Blocks: 8861 9220
  Show dependency treegraph
 
Reported: 2008-08-12 12:46 UTC by Alan Young
Modified: 2010-05-07 10:52 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Young 2008-08-12 12:46:51 UTC
If the player gets end-of-stream (the connection is closed) on the audio stream, and it was a short stream and was shorter than the buffer threshold set in the strm-s command, then the player does not autostart playing the track. It needs a kick, from an strm-r for example.

In the case of short tracks, SC can try to set the threshold low enough so this problem does not occur but this is difficult to get right all the time, probably impossible. It would be better if the player firmware simply ignored the threshold once the stream has been closed and autostart if necessary.
Comment 1 Jim McAtee 2008-08-20 13:58:38 UTC
Could bug 8802 be related?
Comment 2 Andy Grundman 2008-08-20 14:08:17 UTC
Yes probably.
Comment 3 Alan Young 2008-08-20 21:42:42 UTC
Yes, 8802 is related, although 8802 could be resolved for most cases (but not all) by other means.
Comment 4 Felix Mueller 2008-10-20 03:20:14 UTC
Alan: Could you be a bit more specific what you mean by:

"It would be better if the player firmware simply ignored
the threshold once the stream has been closed and autostart if necessary."

Does that mean you would like a player to autostart if there is something in the buffer, the player is not yet playing and the stream has been closed? Or are there more condition that need to be met before a player does autostart?

I am unsure, but couldn't that lead to situations where a crappy network connection would cause the stream closing and then some small music part starts playing which would sound bad? Is that your intension?
Comment 5 Alan Young 2008-10-24 03:12:01 UTC
Yes, "autostart if there is something in the buffer, the player is not yet playing and the stream has been closed" and the autostart flag is set true.

Sure, it will give crappy results with a crappy network, but if things are that bad then the whole experience will be terrible. In any case, SC will still try to start the fragment - it is just not always reliable. The goal of this change would be to make things more reliable.
Comment 6 Felix Mueller 2008-11-04 03:46:57 UTC
Moving out bug that won't make it for 7.3
Comment 7 Felix Mueller 2008-11-06 09:39:32 UTC
Doh, there will be no 7.4 - moving it to 8.0
Comment 8 James Richardson 2009-06-10 13:36:13 UTC
Targeting based on engineering discussion
Comment 9 SVN Bot 2009-08-18 09:15:27 UTC
 == Auto-comment from SVN commit #7130 to the jive repo by ayoung ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7130 ==

bug 9125: Decoder (and play) should start on stream end even if threshold not reached 
SP version of this fix, which just needs to start the audio because SP does decode-while-paused.
Comment 10 Alan Young 2010-05-07 10:52:52 UTC
All new Squeezebox products are likely to be based on the SqueezePlay platform.
We do not plan to implement any further enhancements to the ip3k firmware or
which are targeted specifically at ip3k-based products.