Bug 1024 - Syncing doesn't work correctly for SB2 in a sync group with SB1
: Syncing doesn't work correctly for SB2 in a sync group with SB1
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Sync
: 6.0.0
: PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Richard Titmuss
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-10 14:03 UTC by Vidur Apparao
Modified: 2008-08-18 10:53 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 Vidur Apparao 2005-03-10 14:03:56 UTC
From Richard Titmus:

I have also noticed some sync problems with SB2/SS2, they are:

- as Felix mentioned sometimes only one song is played. From the debug in SS2 is
looks like the STMd and STMu messages are not being sent  when the underrun
occurs, this is because the streaming socket has not been closed by the server.
(The underrun status messages are now only sent when the stream is closed). This
bug seems to depend on where the syncs was setup. SB2/SS2 sync to SB1 does not
work. SB1 sync to SB2/SS2 does work.
Comment 1 Richard Titmuss 2005-03-18 01:43:39 UTC
I have not had time to create a patch yet, but this is the problem:

When players are sync'd the sync group only moves on to the next track when all
players have finished the current track. The server knows the track is finished
when it receives a buffer underrun (STMu) from the player.

On SB2 and SS2 the STMu event (and STMd) is _only_ sent when the stream is
closed by the server. The existing code drops the streaming connection in
Slim::Player::Source::gotoNext, but this only closes the connection for the
master client in the sync group. If a SB2 or SS2 is a slave client, the
connection is never dropped, a STMu event is never sent, and the playlist does
not advance.

Two possible fixes:

1) Drop connections to the whole sync group in Slim::Player::Source::gotoNext. I
don't think this will work, and risks closing the connection before the track
has been streamed to all players.

2) Extend the $client->chunks in Slim::Player::Source::nextChunk to include an
'end of stream' marker.When this marker is passed into Slim::Web::HTTP the
client connection is then forgotten. This marker will be added to the chunks for
all players, ensuring all the connections get closed.

Question is what is a suitable marker? undef is used to mean nothing to read at
the moment. Other options I suppose are numeric 0, zero length string, or
passing an arrayref of (chunk, eosmarker).


Comment 2 Richard Titmuss 2005-03-22 15:15:18 UTC
This looks good to me. Just tested with SB1, SB2 and Softsqueeze2 all synced.