Bug 11888 - Player should reconnect to a remote stream if the connection ends before the known duration
: Player should reconnect to a remote stream if the connection ends before the ...
Status: RESOLVED WONTFIX
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: 7.4.0
: All All
: P3 major (vote)
: ---
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-23 11:07 UTC by Adrian Smith
Modified: 2011-01-24 00:39 UTC (History)
2 users (show)

See Also:
Category: Feature


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Smith 2009-04-23 11:07:26 UTC
BBC iplayer streams and other listen again streams which have a known duration and which we can scan through should automatically reconnect and pick up the stream at the last known playing point if the connection to the stream fails.  This is seen as an end on stream by StreamingController for direct streaming, so we should provide a hook to allow the connection to be reestablished at this point. 


--- Slim/Player/StreamingController.pm  (revision 26169)
+++ Slim/Player/StreamingController.pm  (working copy)
@@ -1790,10 +1790,19 @@

        $log->info($client->id);

-       # TODO - handler hook
-
        unless (_isMaster($self, $client)) {return;}

+       my $song = $self->streamingSong();
+       my $handler = $song->currentTrackHandler();
+       if ($handler->can('onPlayerEndOfStream')) {
+               my $action = $handler->onPlayerEndOfStream($self);
+               if ($action eq 'return' ) { return; }
+               if ($action eq 'reconnect' && $song->duration && 
($self->playingSongElapsed/$song->duration < 0.99)) {
+                       # reconnect if less than 99% streamed as the stream 
ended early (due to network failure?)
+                       return _eventAction($self, 'JumpToTime', { newtime 
=> "+0", restartIfNoSeek => 1 });
+               }
+       }
+
Comment 1 Alan Young 2009-06-09 01:30:32 UTC
Andy, do you know if stream servers that accept seek (range request) indicate this in general in their responses (with or without range headers)?
Comment 2 Andy Grundman 2009-06-09 09:00:38 UTC
Yeah they are supposed to send the header "Accept-Ranges: bytes" but not required to.

      Origin servers that accept byte-range requests MAY send

          Accept-Ranges: bytes

      but are not required to do so. Clients MAY generate byte-range
      requests without having received this header for the resource
      involved. Range units are defined in section 3.12.

      Servers that do not accept any kind of range request for a
      resource MAY send

          Accept-Ranges: none

      to advise the client not to attempt a range request.
Comment 3 Alan Young 2009-06-10 07:47:36 UTC
So, for a known-fixed-duration stream we could use the presence of this header as part of the can-seek logic, and (only) auto-restart prematurely-completed streams in that case.
Comment 4 Adrian Smith 2009-06-10 11:22:29 UTC
Alan - since raising this I've implemented reconnect in the iplayer plugin - its the reason for the extension to the underrun handler.  It would be good to make any changes compatible with that...
Comment 5 Alan Young 2009-07-10 08:31:08 UTC
Change 27486 should resolve this for achievable cases.
Comment 6 Alan Young 2009-09-16 09:02:50 UTC
== SVN commit #28542 to the slim repo by ayoung ==
== https://svn.slimdevices.com/slim?view=revision&revision=28542 ==

Fixed bug 13361: Napster always repeats the same track 
Fixed bug 13967: On Boom: Short podcasts (and perhaps other media types?)
repeat bits.
Reopen bug 11888: Player should reconnect to a remote stream if the connection
ends before the known duration 
bug 3161: Need more aggressive auto-retry for internet radio

Revert change which attempts to resume fixed-length remote streams that appear
to end prematurely, and which attempts to reconnect to remote streams that
appear to be radio. The algorithms for detecting whether a stream has indeed
ended prematurely are not sufficiently accurate in either case.
Comment 7 Andy Grundman 2009-09-16 13:47:43 UTC
*** Bug 14085 has been marked as a duplicate of this bug. ***
Comment 8 Alan Young 2009-09-29 03:08:50 UTC
Update hours
Comment 9 Alan Young 2011-01-24 00:39:04 UTC
Unfortunately, the duration of a remote stream cannot be known accurately. Streams often end before their reported length. restating them just causes the track to be repeated.