squeezeslaves loose connection

[sable]

Hello!


I'm using vortexbox appliance with 4 zone ss_list.conf (so I have 4 squeezeslaves running). I play different music to two of them (for example pink & black), and after some time music may suddenly stop from one of them. Then squeezecenter looses connection with it (it dissapears from players list). It still appears in “ps ax | grep squeezeslave”. I haven't found the reason for this behavior. I've tried to run squeezeslave not from /etc/rc.d/init.d/squezeslave script, but manually (to see if it outputs any errors):


“squezeslave -m00:00:00:00:00:01 -o12 –retry”. But it seems it doesn't. It says “Connected.” Then it plays fine for some time. After that it stops playing. Then it dissapears from players list in squeezecenter.


What could be the reason for that? Have you played different music to different outputs on appliance for conciderably long time?


P.S. I did yum update squeezeslave, so I have 9.65 version.

[yeswork]

Hi,


I experienced the same issue.


I split the Realteck ACL 888 into multiple devices using the Vortexbox provided asound.conf and ss_list.conf. After a while (less than a day) the "green" squeezeslave I used the most, disappeared. I could then play the other "colors" and they would work. Rebooting was required to get the green back


The original asound.conf has no buffer settings and seems pass everything with defaults. The modified asound.conf sets a bunch of channels, rated, buffers etc. It seems they might not be so robust.


I went back to the original asound.conf and ss_list.conf (just one common device) and can play local squeezeslave for days (on one occasion for at least a week straight).

[andrew]

I am having the same problem. If anybody finds a solution for this please tell me and I will update the code. There is a new version of SqueezeSlave I just released. Can sombody test to see if this helps?

[sable]

It seems that this issue is not about squeezeslave itself, but about ALSA. One squeezeslave pointed to /dev/dsp works with no issues, right? So I think the issue is caused by ALSA. It seems to me, that theese outputs swap places from time to time, and squeezeslave get a error and “hangs up”. I've got no facts behind my suggestion, but i think we can try to somehow build a hard links to outputs (for example /dev/snd/green for “green” etc), and point squeezeslaves to those devices. I don't know why, but i think it could fix the problem. The problem is that I don't know how to do it /wp-includes/images/smilies/icon_smile.gif




PS: Andrew, new squeezeslave version, that you've mentioned is 9.65? If so, that does not helps, issue exists on that version too.

[mjmcport]

Has anyone found a solution to this? I can't get any of the squeezeslave players to show up consistently after doing a yum update a couple weeks ago and an update to version 0.7. I can get them to show up momentarily in squeezecenter, by calling them manually from the command line, but they disappear quickly and I don't get any sound out of the appropriate audio jacks.

[sable]

You can try to harvest some debug info:


http://forums.slimdevices.com/showthread.php?p=431097#post431097


I'm doing this right now, but for some strange reason none of my squeezeslave-debug's with log options enabled disappear for almost alrady an hour.

[sable]

It seems that strangely squeezeslave-debug's doesn't have the described issue. I'm running 4 of them simultaneously right now, and I frequently swith between them, adjust volume, change playlists etc. And I can't make them disappear.


It would be cool, if someone could do some testing too:


- download squeezeslave-0.9-65-lnx26-alsa-display-i686.tar.gz (http://sourceforge.net/project/downloading.php?group_id=105169&filename=squeezeslave-0.9-65-lnx26-alsa-display-i686.tar.gz&a=20727506) from sourceforge http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494


- put squeezeslave-debug into /usr/bin/squeezeslave-debug


- edit the file and change two lines in it:


AUDIOID=`/usr/bin/squeezeslave-debug -L | grep -i -m1 $1 |gawk -F: '{print $1}'|tr -d [:space:][:punct:]`


/usr/bin/squeezeslave-debug -dall -Y/storage/pictures/$AUDIOID.log -m$2 -o$AUDIOID -r10 >/dev/null 2>&1 &
- if squeezeslave disappears, we'll have a log file in /storage/pictures/$AUDIOID.log and could pass it to squeezeslave developers (URL of the topic on slim forum in my previous post)

[sable]

I think the solution is near! Squeezeslave-debugs versions seem not to have this bug. See what developer says and give it a try:


http://forums.slimdevices.com/showthread.php?p=431097#post431097

[Rickster]

Does anyone know if this issue has been resolved with squeeze slave version 0.975 or is the fix still to use the debug version?

[yeswork]

On a related issue. Yum update only brought me to squeezezeslave 0.965.




Any suggestions?

[wizardofoz]

The debug version has fprintf statements to stderr all throughout the code. This would appear to indicate a race condition that is masked by all the additional print statements in the debug version. I've long suspected this, but have not been able to track it down. That being said, I run the NON debug version for months at a time on Solaris and Windows and never have SS disappear from SC.

I'd suggest you compile a version to match your Fedora environment using the makefile.linux26-alsa-display makefile as your starting point. Post any issues here and I'll help you get a working version.






Hmmmm Andrew are you using a standard binary or a compiled for FC11 one?

[andrew]

I was building from scratch. But I think I am using the static binary now.

[yeswork]

Hi,




Did a yum update last night; fedora installed a bunch of updates. Previously robust squeezeslave is now "disappearing" after an hour or so of listening.


Before working much on a diagnosis, is there an easy way to get from 0.965 to the current 0.975 squeezeslave?




Yum only brings squeezeslave to 0.965.




Thanks

[Oook]

same here - just spent all day updating everything to current – and now the player in the vortexbox (squeezeslave) is gone – if I go to /etc/rc.d/init.d and type squeezeslave it starts (and gives me a connnected message) – but I can't get back to the command line. If I cntl-x the players stops..


Note I am using a standard vortexbox appliance and a duet – duet works fine


hard to explain to the SO - if you want music in this room - you have to go to this dir and type this etc... she is not happy

[andrew]

service squeezeslave status will tell you if it's running.


service squeezeslave start will start it if it's not.

[Oook]

That's good – but why doen't it start when I re-boot? is there something in the script that exits on the boot run but doesn't on the service command?


Just tried the service commands from the command line – neither do anything – no repy from the status or start and the player is not running




Last login: Fri Aug 14 17:10:39 2009 from 192.168.1.102
[vortexbox.localdomain ~]# service squeezeslave status
[vortexbox.localdomain ~]# service squeezeslave start
[vortexbox.localdomain ~]# service squeezeslave status
[vortexbox.localdomain ~]#


should this command be entered from the command line?


here is what happens in the dir




[vortexbox.localdomain /]# cd etc
[vortexbox.localdomain etc]# cd init.d
[vortexbox.localdomain init.d]# service squeezeslave start
[vortexbox.localdomain init.d]# service squeezeslave status
[vortexbox.localdomain init.d]# squeezeslave
Connected.
service squeezeslave status
service squeezeslave start




and then it is active


but now I can't get out – cntl c exits but then the player stops

[Rickster]

@ Oook


Have you tried running Squeeze slave 0.965 in debug mode as per Sable's post?


I have not tried it myself, but apparently it has resolved his problems.




@ Sable


Are your Squeeze Slaves still functioning without incident? http://vortexbox.org/wp-content/forum-smileys/sf-confused.gif

[Oook]

No - didn't try that (looked like a lot of work..)


BUT


I change the squeezeslave script - commemted out these 3 lines at the front



if [ ! -e /dev/audio ]; then
exit 0
fi


and then did a reboot


and it works!!


player showed up in squeezecenter (with the name squeezeslave - not the name it did have)


and everything has been working for well over an hour ...

[Rickster]

Oook,


Are you also running 4 separate squeezeslaves to create 4 zones?


Please let us know if it resolves the disappearing squeeze slave issue.

[Oook]

No - box standard - just one zone on the box and a squeezeduet - two in total - and it's still working - not sure what [ ! -e /dev/audio ] is checking - but thought something is stopping it from starting and the only other exit looked ok. So I took a punt

[Moonbase]

Hm, whatever that means, I get the following using SqueezeBoxServer 7.4-28198 on Fedora 11 and squeezeslave-debug from the "squeezeslave-0.9-65-lnx26-alsa-display-i686.tar.gz":

/usr/bin/squeezeslave-debug: unrecognized option '--r10'
proto state=1
slimaudio_output_init: PortAudio initialized
http_thread state 2
decoder_thread: STREAM_STOPPED first_time:1
paDeviceInfo->maxOutputChannels 2
paDeviceInfo->defaultHighOutputLatency 0
paDeviceInfo->defaultLowhOutputLatency 0
paDeviceInfo->defaultSampleRate 44099.814950
Expression 'SetApproximateSampleRate( pcm, hwParams, sr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1291
Expression 'PaAlsaStreamComponent_InitialConfigure( &self->playback, outParams, self->primeBuffers, hwParamsPlayback, &realSr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1865
Expression 'PaAlsaStream_Configure( stream, inputParameters, outputParameters, sampleRate, framesPerBuffer, &inputLatency, &outputLatency, &hostBufferSizeMode )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1986
/usr/bin/squeezeslave-debug: unrecognized option '--r10'
proto state=1
slimaudio_output_init: PortAudio initialized
http_thread state 2
decoder_thread: STREAM_STOPPED first_time:1
paDeviceInfo->maxOutputChannels 2
paDeviceInfo->defaultHighOutputLatency 0
paDeviceInfo->defaultLowhOutputLatency 0
paDeviceInfo->defaultSampleRate 44099.814950
Expression 'SetApproximateSampleRate( pcm, hwParams, sr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1291
Expression 'PaAlsaStreamComponent_InitialConfigure( &self->playback, outParams, self->primeBuffers, hwParamsPlayback, &realSr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1865
Expression 'PaAlsaStream_Configure( stream, inputParameters, outputParameters, sampleRate, framesPerBuffer, &inputLatency, &outputLatency, &hostBufferSizeMode )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1986
proto state=1
slimaudio_output_init: PortAudio initialized
slimproto_connect(127.0.0.1, 3483)
paDeviceInfo->maxOutputChannels 2
paDeviceInfo->defaultHighOutputLatency 0
paDeviceInfo->defaultLowhOutputLatency 0
paDeviceInfo->defaultSampleRate 44099.814950
Expression 'SetApproximateSampleRate( pcm, hwParams, sr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1291
Expression 'PaAlsaStreamComponent_InitialConfigure( &self->playback, outParams, self->primeBuffers, hwParamsPlayback, &realSr )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1865
Expression 'PaAlsaStream_Configure( stream, inputParameters, outputParameters, sampleRate, framesPerBuffer, &inputLatency, &outputLatency, &hostBufferSizeMode )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1986
decoder_thread: STREAM_STOPPED first_time:1

Also, this was only possible by commenting out the /dev/audio check in /etc/rc.d/init.d/squeezeslave (there seems to be no /dev/audio here).



squeezeslave-debug -L



gets me the following list:

Output devices:
* 0: Ensoniq AudioPCI: ES1371 DAC2/ADC (hw:0,0)
1: Ensoniq AudioPCI: ES1371 DAC1 (hw:0,1)
2: front
3: iec958
4: spdif
5: default
6: dmix


Any ideas?

[Moonbase]

Using output device “5″ (default) seems to at least get me some audio. Still squeezeslave 0.9-65 looses connection within the first song played. Squeezeslave 0.9-78 the same.


The only thing that works for some time is the 0.9-65 “squeezeslave-debug” but this one stutters quite often.

/usr/bin/squeezeslave -m00:04:20:00:00:01 -o5 –-retry >/dev/null 2>&1 &

(Don't be alarmed: To keep script changes at a minimum, I simply copied squeezeslave-debug over squeezeslave.)


Interestingly, stuttering is less when I write to a log file – this would indeed point to some racing condition that gets somehow better by the debug version outputting lots of stuff … (as Ralph already suspected).


But ONLY if I start squeezeslave manually — starting through

service squeezeslave start

results in an “OK” but still squeezeslave doesn't run.


Not even

/opt/vortexbox/ss_wrapper.sh 5 00:04:20:00:00:01

works.

[Moonbase]

A-ha! Got it:


Seems /etc/rc.d/init.d/squeezeslave looks for output names, not numbers! So my usage of "5" above resulted in finding the "3: iec958" output which has #3 and resulted in the parameter "-o3" being generated (instead of "-o5").


Output #5 on my card is listed as "5: default", so I use

/opt/vortexbox/ss_wrapper.sh default 00:04:20:00:00:01

now and all is well so far.


Except having to use the debug version of squeezeslave and the stuttering, of course.

[yeswork]

Good for you!




What you did, using “default,” matches with how I fixed some issues I orginally had with squeezeslave. I use an external USB Ceative Sound “Card” and playback became much more reliable when I used the explicit name “Creative” in the script. Glad something similar works for you.


On a continuing unresolved note. How did you get squeezeslave 0.978 onto your vortex device; did you have to compile it? Yum brings me to 0.965, and I have occasional loss of squeezeslave which requires a reboot of my vortexbox. I'd like to use the latest version of squeezeslave that has been released.


Thanks for sharing your progress notes.

[Moonbase]

Got me… Since I was too lazy to install all the dev-libraries onto my VortexBox and re-compile it myself, I used a pre-built Linux binary for 0.978 that Ralph linked to somewhere. Only, I can't remember where… either on sorceforge or somewhere over in the slimdevices forums… Sorry.


You might want to google for "squeezeslave-0.9-78-lnx26-alsa-display-i686.tar.gz".


Then again, 0.978 didn't fix anything and Ralph talked about some other things currently broken and being worked upon, so I'm using 0.965 (from the yum update) still and patiently wait for the next “official” repo update.