PDA

View Full Version : Unwanted 'synchronisation'



relen
2005-04-08, 17:07
So, I'm running SS6.0.1 on an RH7.2 system. I have one hardware SB1 and two SoftSqueeze 2.0b3s, one on a Mac G4 iBook and the other on an XP machine.

I call up a song on the SB1 using the remote and play it (a FLAC file as it happens, so it is being transcoded). While it's playing, I launch Firefox on the iBook and open the server page. As the screen draws, the music on the SB1 stops. After a short while (10-20 secs) it starts again. However there are now hiccups in the playback (lasting 0.5-3 secs or so), more or less in sync with the redraws of the RH pane (which is displaying the data for the SB1). I call up a different track from the server window and click play on it to force the SB1 to play it, which it does. With hiccups.

I close the server's browser window and the hiccups cease. Soon, the time/date screensaver starts to run on the SB1.

I open the SSQ2 on the iBook, bringing up the horizontal remote window as the vertical one partially overlays the display window (er... nevermind) and select a different album and play a track from it (also FLAC), by using the on-screen remote. It plays fine. I quit the SSQ2 and go back to the SB1 and wake it up. The display comes up showing not the album that's still playing, but the one I was playing on the SSQ2! I can navigate to the album that is actually playing and the track that first appears is the one that's playing. I turn off the iBook and the SB1.

Now I go upstairs and activate the SSQ2 on the Windows machine, where it is on-screen but "powered down". I click Power, then Play and then click Bright to bring the display back (the several idiosyncrasies of my WinXP SSQ2 are a topic for another time). The thing is displaying the track I called up on the SSQ2 on the Ibook! And it plays it when I press Play!

Needless to say, I have anything that smacks of synchronisation turned OFF, or I wouldn't be posting this.

As I write this, I'm listening to a different album on the WinXP SSQ2. Between two tracks, there's a brief snatch of something else. Is it... the track I was playing downstairs earlier?

Play intro to "The Twilight Zone" and fade...

Observations?
--Richard E

Greg Friedman
2005-04-09, 08:27
"relen"
<relen.1n72un (AT) no-mx (DOT) forums.slimdevices.com>
wrote in message news:relen.1n72un (AT) no-mx (DOT) forums.slimdevices.com...
>
> ...
> Now I go upstairs and activate the SSQ2 on the Windows machine, where
> it is on-screen but "powered down". I click Power, then Play and then
> click Bright to bring the display back (the several idiosyncrasies of
> my WinXP SSQ2 are a topic for another time). The thing is displaying
> the track I called up on the SSQ2 on the Ibook! And it plays it when I
> press Play!
>
> Needless to say, I have anything that smacks of synchronisation turned
> OFF, or I wouldn't be posting this.
>
> ...

A couple of us are seeing the same behavior along with other idiosyncratic
behaviors that I think are related. I logged this as bug 1289. It was not
fixed by the 6.01 update. While the description in the bug doesn't exactly
track your issues, I've see variations on the theme (including watching the
display on an SB1 track the navigations done on a SoftSqueeze instance) that
closely resemble what you've reported.

You can view the bug here:

http://bugs.slimdevices.com/show_bug.cgi?id=1289

Greg.

rtitmuss
2005-04-10, 13:53
relen wrote:

>I open the SSQ2 on the iBook, bringing up the horizontal remote window
>as the vertical one partially overlays the display window (er...
>nevermind)
>
Press the apple key (ctrl on windows) while dragging the remote window,
you can move it separately then.

>The display comes up showing not
>the album that's still playing, but the one I was playing on the SSQ2! I
>can navigate to the album that is actually playing and the track that
>first appears is the one that's playing. I turn off the iBook and the
>SB1.
>
>
This sounds like you have the mac address of your SB1 and Softsqueeze
players set to the same value? Check in the networking tab of the
Softsqueeze preferences. If this is the case then the slimserver will
only think you have one player, each player must have a unique mac address.

>As I write this, I'm listening to a different album on the WinXP SSQ2.
>Between two tracks, there's a brief snatch of something else. Is it...
>the track I was playing downstairs earlier?
>
>
Yes, this may occasionally happen. At the moment a bug lurks in the
Softsqueeze audio buffer where two tracks can try to play at the same
time. It does not happen normally, and so far I have not found what
triggers the problem. Restarting Softsqueeze will fix this.

Richard

relen
2005-04-10, 14:14
Press the apple key (ctrl on windows) while dragging the remote window,
you can move it [remote and display] separately then.

Thanks! I should have known that, I think... In fact I thought I'd tried it and failed... anyway it works fine.


Check in the networking tab of the
Softsqueeze preferences. If this is the case then the slimserver will
only think you have one player, each player must have a unique mac address.

I'm afraid all the devices, real and virtual, have different MAC addresses, so that's not it, unfortunately. Good thought though!

Thanks,
--Richard E

radish
2005-04-16, 14:24
Did anything come of this yet? I have found a similar problem. I have 2 players (one SB and one SB2) - let's call them A and B. I currently have them both playing, from different playlists, no sync is enabled. When B gets to the end of a track, it pauses (the display locks up) until A starts it's next track (so anywhere up to 3 or 4 minutes) and then continues as normal. While B is "stuck" I can use the remote to skip to the next track and press play to resume playback, but it will stop again at the end of that track. The only way I can prevent this issue is to have only one of my squeezeboxen playing at once - which is not really the point!

Cheers.

radish
2005-04-18, 14:24
Any progress on this? It's really annoying, and basically means I can only use one squeezebox at a time. Which kind of makes my investment in a second one useless. The bug report in bugzilla just seems to end with people saying they can't reproduce it - I can and I'd be happy to help out with debugging in whatever way I can.

Chris Laplante
2005-04-18, 14:40
Before modding it to have uniq mac addresses, I had the exact same
scenario when multiple slimp3slave players with the same mac were on
the same network. Could be totally unrelated, but I thought it worth
mentioning since the symptoms are the same.

-chris


On 4/18/05, radish <radish.1npdvn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> Any progress on this? It's really annoying, and basically means I can
> only use one squeezebox at a time. Which kind of makes my investment in
> a second one useless. The bug report in bugzilla just seems to end with
> people saying they can't reproduce it - I can and I'd be happy to help
> out with debugging in whatever way I can.
>
>
> --
> radish
>

relen
2005-04-18, 14:59
In my case the problem is not quite as described in the bug report but in the same general area - and I have already checked that all MAC addresses are different, so it regrettably isn't as simple as that.

--Richard E

radish
2005-04-18, 16:59
Thanks for the suggestions - the MAC addresses are different, and the web interface sees them as different players, with their own configs.

vidurapparao
2005-04-18, 17:34
Would it be possible for you to post debug output with the --d_source
debug flag turned on? Let me know if you need instructions for getting
the debug log.

Thanks,
--Vidur

radish wrote:

>Thanks for the suggestions - the MAC addresses are different, and the
>web interface sees them as different players, with their own configs.
>
>
>
>

Greg Friedman
2005-04-18, 19:46
Would it be possible for you to post debug output with the --d_source
debug flag turned on? Let me know if you need instructions for getting
the debug log.


Vidur - I'm the originator of bug 1289, which may be a variation of the same issue. I attached a log to that bug in which Player A came to the end of a song and, rather than advancing to the next song, Player B woke up from a paused state and advanced to its next song. Player A stayed stuck at the end of its song and did not advance until I used the remote control to go to the next track.

Please let me know if I can help track this down further.

Greg.

radish
2005-04-19, 07:33
Sure - I'll do it tonight and post.


Would it be possible for you to post debug output with the --d_source
debug flag turned on? Let me know if you need instructions for getting
the debug log.

Thanks,
--Vidur

radish wrote:

>Thanks for the suggestions - the MAC addresses are different, and the
>web interface sees them as different players, with their own configs.
>
>
>
>

radish
2005-04-19, 20:08
OK, I have attached the log as requested. Some notes as to what;s going on:

00:04:20:05:35:a4 is my SB1 ("Bedroom Squeezebox")
00:04:20:05:a3:c5 is my SB2 ("Playroom Squeezebox")

First I start playing a flac album on the SB2 (@ 2005-04-19 22:37:09.8597).
Then I start playing an ogg album on the SB1 (@ 2005-04-19 22:37:36.9062)
Around 22:40 the first track of the flac album finishes, and playback on the SB2 stops, SB1 continues playing the ogg album.
Around 22:46, the first track of the ogg album finishes and playback of the flac album on the SB2 restarts on it's second track. The SB1 continues to it's second track also.

And that's about it - hopefully the log will tell you something. Another thing I have noticed is that this only seems to happen when the SB2 is playing a native flac file - when I tried playing an ogg album on both the SB1 (transcoding to pcm) and SB2 (transcoding to flac) it _seemed_ to work correctly.

Let me know if there's anything else I can do to help.

radish
2005-04-20, 12:03
Vidur - let me know if you need any more information to track this down.

Thanks.

vidurapparao
2005-04-21, 09:51
The debug log definitely shows that the SB2 seems stalled from sometime
after 22:40:16 till 22:46:39. The former time is when we finish
streaming the FLAC track to the player, though it may be many seconds
before the SB2 actually finishes playing the track. The latter time is
when SlimServer receives a decoder underrun event from the SB2, implying
that the input buffer of the device is empty and it's ready for the next
track. Again, there should be a delta between the first time and the
point where we get the decoder underrun event - this represents the
audio in the SB2's input buffer which can be several seconds to minutes
long, depending on the bitrate of the audio and the bandwidth of the
network. However, that delta definitely shouldn't be over 6 minutes.

A question - were these two players synchronized and then unsynchronized
anytime prior to grabbing the debug log? I've attached a small source
code patch that provides a bit more debug output. If you need help
applying the patch, feel free to contact me off-list at vidur | at |
slimdevices.com.

Greg, the log you posted to bug 1289 isn't as clear about what's going
on. If you're able to recreate with the attached patch, I'd appreciate it.

Thanks for your help!
--Vidur



Index: Slim/Player/Source.pm
================================================== =================
--- Slim/Player/Source.pm (revision 3007)
+++ Slim/Player/Source.pm (working copy)
@@ -583,6 +583,7 @@
# A zero length chunk is a marker for the end of the stream.
# If we see one, close the outgoing connection.
if (!$len) {
+ $::d_source && msg("Found an empty chunk on the queue - this means we should drop the streaming connection.\n");
Slim::Web::HTTP::forgetClient($client);
$chunk = undef;
}
@@ -873,9 +874,11 @@
my $client = shift;

if (!scalar(@{$client->chunks})) {
+ $::d_source && msg("No pending chunks - we're dropping the streaming connection\n");
Slim::Web::HTTP::forgetClient($client);
}
else {
+ $::d_source && msg("There are pending chunks - queue an empty chunk and wait till the chunk queue is empty before dropping the connection.\n");
push @{$client->chunks}, \'';
}
foreach my $buddy (Slim::Player::Sync::syncedWith($client)) {

radish
2005-04-21, 10:59
Thanks for looking into this Vidur. I'll have a go at applying the patch and running another test tonight if I get time.

To answer a couple of your points:

These players were synched once, when I first got the SB2 maybe a couple of weeks ago. It didn't work quite how I liked (when synched the players introduced short gaps between tracks which weren't there if not synched) so I disabled it after like 20 mins. The server has been upgraded at least twice and bounced many times since then.

To clarify a little about what happens when the SB2 stalls - as it's approaching the end of the track everything is normal. Then, roughly 7 or 8 seconds before the end, the display locks up but the music still plays to the end of the track. The display remains stuck until it wakes back up again when the SB1 changes track. If I use the remote while it's locked I can skip to the next track manually and it works fine. But it will lock up again at the next transition.

The network is wireless, but with good signal strength and the bitrate is ~1mbps (FLAC).

I should also point out that the SB1 playback never has any problems, and if the SB1 isn't playing, neither does the SB2. This only occurs when both players are playing at once.

vidurapparao
2005-04-21, 11:25
The behavior you describe is consistent with my speculation of what
might be happening. When SlimServer completes streaming a track to the
SB2, it should close the streaming socket for that track. This is an
indication that there is no more data for that stream (the data itself
does not contain an end-of-stream marker). If, and only if, the
streaming socket has been closed, the device sends a decoder underrun
message when it finishes decoding the audio - this can be several
seconds to minutes after the socket has been closed, depending on how
much audio fits into the SB2's input audio buffer. The decoder underrun
message is an indicator to SlimServer that it should start streaming the
next track.

I'm speculating that the server isn't closing the streaming socket for
some reason, resulting in a severely delayed decoder underrun message.
The patch with the debug output hopefully will help me figure out why.

--Vidur

radish wrote:

>Thanks for looking into this Vidur. I'll have a go at applying the patch
>and running another test tonight if I get time.
>
>To answer a couple of your points:
>
>These players were synched once, when I first got the SB2 maybe a
>couple of weeks ago. It didn't work quite how I liked (when synched the
>players introduced short gaps between tracks which weren't there if not
>synched) so I disabled it after like 20 mins. The server has been
>upgraded at least twice and bounced many times since then.
>
>To clarify a little about what happens when the SB2 stalls - as it's
>approaching the end of the track everything is normal. Then, roughly 7
>or 8 seconds before the end, the display locks up but the music still
>plays to the end of the track. The display remains stuck until it wakes
>back up again when the SB1 changes track. If I use the remote while it's
>locked I can skip to the next track manually and it works fine. But it
>will lock up again at the next transition.
>
>The network is wireless, but with good signal strength and the bitrate
>is ~1mbps (FLAC).
>
>I should also point out that the SB1 playback never has any problems,
>and if the SB1 isn't playing, neither does the SB2. This only occurs
>when both players are playing at once.
>
>
>
>

vidurapparao
2005-04-22, 15:46
Greg and radish,

Any luck getting a new log with the debug output patch? If so, please
attach to http://bugs.slimdevices.com/show_bug.cgi?id=1289.

Thanks,
--Vidur

Vidur Apparao wrote:

>
> The behavior you describe is consistent with my speculation of what
> might be happening. When SlimServer completes streaming a track to the
> SB2, it should close the streaming socket for that track. This is an
> indication that there is no more data for that stream (the data itself
> does not contain an end-of-stream marker). If, and only if, the
> streaming socket has been closed, the device sends a decoder underrun
> message when it finishes decoding the audio - this can be several
> seconds to minutes after the socket has been closed, depending on how
> much audio fits into the SB2's input audio buffer. The decoder
> underrun message is an indicator to SlimServer that it should start
> streaming the next track.
>
> I'm speculating that the server isn't closing the streaming socket for
> some reason, resulting in a severely delayed decoder underrun message.
> The patch with the debug output hopefully will help me figure out why.
>
> --Vidur
>
> radish wrote:
>
>> Thanks for looking into this Vidur. I'll have a go at applying the patch
>> and running another test tonight if I get time.
>>
>> To answer a couple of your points:
>>
>> These players were synched once, when I first got the SB2 maybe a
>> couple of weeks ago. It didn't work quite how I liked (when synched the
>> players introduced short gaps between tracks which weren't there if not
>> synched) so I disabled it after like 20 mins. The server has been
>> upgraded at least twice and bounced many times since then.
>>
>> To clarify a little about what happens when the SB2 stalls - as it's
>> approaching the end of the track everything is normal. Then, roughly 7
>> or 8 seconds before the end, the display locks up but the music still
>> plays to the end of the track. The display remains stuck until it wakes
>> back up again when the SB1 changes track. If I use the remote while it's
>> locked I can skip to the next track manually and it works fine. But it
>> will lock up again at the next transition.
>>
>> The network is wireless, but with good signal strength and the bitrate
>> is ~1mbps (FLAC).
>>
>> I should also point out that the SB1 playback never has any problems,
>> and if the SB1 isn't playing, neither does the SB2. This only occurs
>> when both players are playing at once.
>>
>>
>>
>>
>
>

Greg Friedman
2005-04-23, 07:30
Greg and radish,

Any luck getting a new log with the debug output patch? If so, please
attach to http://bugs.slimdevices.com/show_bug.cgi?id=1289.

Thanks,
--Vidur



I applied your patch. I'll try to reproduce the problem and generate a log.

Greg.

Greg Friedman
2005-04-23, 07:54
I applied your patch. I'll try to reproduce the problem and generate a log.

Greg.

Bug 1289 has been updated with a new debug log with Vidur's patch. Let me know if you need more info.

radish
2005-04-23, 18:54
Sorry - I've been really busy. I'll have a go tonight and post results.

radish
2005-04-23, 20:23
OK - done. I didn't apply the patch as I upgraded to the latest nightly and the patch changes were already there. Test & results exactly as before, see bugzilla post for more details.

Oh, and not to be a nag, but I started another thread a while ago about flac playback problems (http://forums.slimdevices.com/showthread.php?t=13726) and didn't get any replies. This is also a consistent problem for me, and is really annoying. I'm not sure if it's related to this issue, but maybe. Are there any tests/logs I could post to help out with this issue too?