PDA

View Full Version : Big pause in front of every song with sc 7



jimbof
2008-06-01, 08:59
I've recently upgraded my squeezecenter from 6.5.4 to 7.0.1 and now when I start playing a song it takes ~10 seconds to start playing. Now admittedly the server is running a c7 (1.2 ghz) and its having to transcode the file from aac to mp3, but it didn't used to do the pause in 6.5.4, so the hardware should be capable of it. Are there any changes I can make to try and speed things up - knock down some buffering somewhere perhaps?

bpa
2008-06-01, 09:02
What OS ?

If using Windows - try changing the convert rules to using faad instead of mov123. You can do a search to find this issue discussed and the use of faad.

jimbof
2008-06-03, 13:27
I'm on linux and already using faad. Experimentation reveals that mp3 gives no pause at the start, so it is something to do with the transcoding and or buffering. Given that once the song starts there are no dropouts the machine seems capable of realtime encoding, so I am baffled by the 10 second pause at the start. Its annoying me to the point I'm thinking about getting a new server!

bpa
2008-06-03, 13:32
Can you get a log of starting a track with logging (Settings/Advanced/Logging) player.source set to DEBUG. Once music stops the track.

This will generate lots of text so save the log in a plain text file (not a DOC or RTF), zip it up and attach to a post.

ntom
2008-06-03, 17:43
I am using Windows but when I upgraded to 7.0.1 I encountered buffering problems and noticed a similar issue. Furthermore with 24/48 & 24/96 I found that I got severe stuttering which might well have been to do with buffering (as well as network capacity).

I changed the display setting so that I could see the buffer display on the SB and there does appear to be a delay at the start of a song as the buffer fills, and stuttering occures when the network cant keep up but this seemed much worse with 7.0.1. In my case there may have been other network factors at the time but I changed back to 6.5 and the performance issues vanished. I haven't yet had the opportunity to try SC7 again.

jaffacake
2008-06-04, 00:20
I find a significant pause when using SC7 on low performance hardware, such as my NAS. On a high powered windows server, things are much improved.

I also find the delay increases if 2 or more players are synced.

Could you consider changing all your music over to mp3 to avoid the need to transcode?

pfarrell
2008-06-04, 08:01
jaffacake wrote:
> I find a significant pause when using SC7 on low performance hardware,
> such as my NAS. On a high powered windows server, things are much
> improved.

Its fine with medium power Linux server.

> Could you consider changing all your music over to mp3 to avoid the
> need to transcode?

No way, not ever. Replace the underpowered server instead.


--
Pat Farrell
http://www.pfarrell.com/

ntom
2008-06-04, 16:58
I find a significant pause when using SC7 on low performance hardware, such as my NAS. On a high powered windows server, things are much improved.

I also find the delay increases if 2 or more players are synced.

Could you consider changing all your music over to mp3 to avoid the need to transcode?

Interesting observation as I was not sure how much of my problem was network related & how much was server.

Is there any reason why I might see more problems with SC7 than SS6.5 ? Has much changed that would actually add much load on the server -certainly reloads seemed to take longer.

jimbof
2008-08-09, 11:29
Sorry for the (massive!) delay in replying - work interfering with real life. Anwyway I've attatched a log - the big pause is here:

[08-08-09 20:20:16.2200] Slim::Player::TranscodingHelper::tokenizeConvertCo mmand (387) Using command for conversion: "/usr/bin/faad" -w -f 2 "/home/samba/Music/B-52\`s/The B-52\`s/08 6060-842.m4a" | "/usr/bin/lame" --resample 44100 --silent -q 5 -b 0 -x -r - - & |
[08-08-09 20:20:16.4010] Slim::Player::Source::playmode (412) 00:04:20:12:32:86 New play mode: play
[08-08-09 20:20:16.4516] Slim::Player::Source::playmode (581) 00:04:20:12:32:86: Current playmode: play
[08-08-09 20:20:18.8871] Slim::Player::Source::readNextChunk (2331) Sending 0 bytes of silence.
[08-08-09 20:20:36.4493] Slim::Player::Source::trackStartEvent (1605) Got a track starting event
[08-08-09 20:20:36.4508] Slim::Player::Source::trackStartEvent (1621) Song 7 has now start

Any ideas gratefully received!

bpa
2008-08-09, 15:38
At the end of the conversion there are some suspicious character s"& |"

There are not in the distributed files.
Did you add them ?
Can you remove them and test

jimbof
2008-08-10, 04:18
They aren't there in the conversion file. I would guess that this bit of code in TranscodingHelper.pm is sticking them on:

if (!defined($noPipe)) {
$command .= (Slim::Utils::OSDetect::OS() eq 'win') ? '' : ' &';
$command .= ' |';
}

Trying with mp3's and the 10 second pause vanishes:

[08-08-10 13:17:52.2026] Slim::Player::Source::playmode (581) 00:04:20:12:32:86: Current playmode: play
[08-08-10 13:17:54.1494] Slim::Player::Source::readNextChunk (2331) Sending 0 bytes of silence.
[08-08-10 13:17:56.9920] Slim::Player::Source::trackStartEvent (1605) Got a track starting event


Very frustrating!

jimbof
2008-08-10, 05:01
Experimentation reveals that taking lame out speeds it up enourmously - a 2 second pause. But given that once the song gets going the machine seems quite capable of transcoding in realtime I dont understand the reason for the pause.

bpa
2008-08-10, 05:16
Change the lame compression to quicker (i.e. 9 not 5) but worse and see if delays are lessened.

Other possibility if input is not 44.1kHz (e.g. 48kHz) then resampling may be taking a lot of processing.