Bug 15203 - AAC Playback can not be synced with ip3k players
: AAC Playback can not be synced with ip3k players
Status: RESOLVED WORKSFORME
Product: SB Touch
Classification: Unclassified
Component: Audio
: unspecified
: PC Other
: P2 normal (vote)
: 7.5.0
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-28 03:12 UTC by Joerg Schwieder
Modified: 2010-02-24 02:00 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
log file of skipping (13.98 KB, text/plain)
2009-11-29 02:07 UTC, Joerg Schwieder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Schwieder 2009-11-28 03:12:32 UTC
I recently tried to play some AAC files on Touch and Transporter synced up. My server does the transcoding for Transporter and while I can sync up several ip3k players and it also plays fine on Touch alone, playing it on Touch and Transporter synced will lead to continuous interruptions of playback every few seconds.

Is this meant to work?
Comment 1 Alan Young 2009-11-28 09:59:37 UTC
Yes, it should work.

Can you get a server log at level player.source=info and player.sync=info ?
Comment 2 Joerg Schwieder 2009-11-29 02:07:23 UTC
Created attachment 6346 [details]
log file of skipping
Comment 3 Joerg Schwieder 2009-11-29 02:07:34 UTC
As could be expected it worked like clockwork yesterday when I tried to reproduce this.

No I got it back at least for one track. The way to cause it (and I believe that was also how it originally started) is to play the music and then - while it's already playing, confirming a firmware update on the Touch.
As soon as the Touch comes back online after the restart the choppy behavior starts. Yesterday it stayed for the whole album, today (with a different album) just for one track.

Log attached.
Comment 4 Alan Young 2009-11-30 00:19:23 UTC
Joerg, if you can reproduce this again, please can you add network.protocol.slimproto=info to the logging. although I'm not sure that that will tell us very much more - just confirm my suspicions.

It seems that the player is getting starved of data. The question is what is the cause of the starvation: (a) the player not reading the available data from the network, (b) network congestion stopping the data getting through, (c) the server not delivering the data to the network. Determining which of these is the case is hard. I guess that adding network.http=info as well is probably enough to see what is going on.

You might also try running with "--perfwarn 0.3" to see if there are other slow actions holding up the server.
Comment 5 Joerg Schwieder 2009-11-30 01:05:19 UTC
Sorry, I probably can't test this before next weekend and even then it will likely be Sunday.

My server isn't the fastest one on servers but on the player side: one is connected through WiFi and one through (GB) Ethernet, so I don't believe it's network traffic.

In this scenario, are both players playing the transcoded stream or is Transporter getting the transcoded and Touch the original stream?
Comment 6 Alan Young 2009-11-30 03:02:01 UTC
Both play transcoded.

Which is on Wifi?
Comment 7 Joerg Schwieder 2009-11-30 04:28:16 UTC
Touch is on WiFi.
Comment 8 Alan Young 2009-12-04 02:04:11 UTC
Update hours
Comment 9 Alan Young 2010-01-14 06:43:04 UTC
Joerg, any update? I have been unable to recreate this.
Comment 10 Joerg Schwieder 2010-01-18 11:21:24 UTC
Can no longer reproduce this with the current build.
Will give it another try when the next FW update for touch comes along.
Comment 11 Joerg Schwieder 2010-01-18 11:33:19 UTC
Wrote one minute too early, it's still there :(
Unfortunately I also turned off loggin too early :((
Will try more.
Comment 12 Alan Young 2010-02-24 02:00:28 UTC
Joerg, I'm going to close this for now. Please reopen if you can get some more evidence. I still cannot reproduce it. Alan.