Bogg wrote:
> When I run the script with --nostop I get quite different results.
>
> When I stop the dac the sqlite stays listed on material / apps
> the pcp web says not running
This bit is rather strange. The --nostop option makes a rules file that
does not have a rule for when the DAC is removed. Because the script
will no longer attempt to kill Squeezelite, I would expect it to stay
visible in the list of players in Material (which it apparently is), but
I would also expect it to stay 'running' in the pCP web interface (which
it apparently is not). Strange.
Bogg wrote:
>
> and when I turn the dac back on it reconnects fine and works as
> expected.
> except the pcp web says it's not running - clearly not a problem.
Your log file shows that it's not actually restarting Squeezelite - it's
reporting the same failure after 5 attempts. However, since nothing had
stopped Squeezelite previously, the original process simply carries on
working. The fact that the pCP web interface says otherwise is odd. I
don't understand how it can get out of sync.
Bogg wrote:
>
> The problem is that unless I power off the sqlite through the web app
> etc then the rest of the sync group pauses for about 20 seconds every
> minute or so. And the sync ends up miles off when I do reconnect the
> dac.
> If I could change your script to just soft off (is that the phrase) the
> sqlite when the dac disconnects and soft on when it reconnects I think
> it would work for me. Is that odd or normal behaviour?
>
This is the very reason that I added the 'stop' option - I had the same
behaviour. I guess a 'soft' off would be another way to do that. And
in fact, a 'soft' on after reconnection would be a useful feature too -
I've noticed that sometimes my DAC reconnects but the soft power is off
- maybe it remembers the previous soft power state. I don't know how to
script a soft power change, but I'm sure it's possible.
Breaking this down, I think there are two problems at the moment.
Firstly - the original symptom - the restart command issued by the
script always seems to fail after 5 attempts, regardless of the
scenario.
Secondly, the pCP web interface doesn't seem to reflect the actual
Squeezelite process status.
I'm not going to have a chance to look at this again until tomorrow, so
I'll think about ways to diagnose this further. In the meantime can you
confirm that your pCP only has a single instance of Squeezelite, and
that it's configured only via the Squeezelite web page of the pCP
interface? The second problem above -could- suggest that you have a
separate Squeezelite process initiated by a User Command perhaps.
Starting Sqeezelite from a user command would mean that its status would
not be reflected in the pCP web interface.
One other thing you could try, again clutching at straws, is to run the
script manually rather than using the command line to restart
Squeezelite.
1) Re-run the 'install' option but without the --nostop option. This
should recreate the rules file with both options. Reboot.
2) Disconnect the DAC. This should kill the Squeezelite process.**
3) Reconnect the DAC. The expected behaviour would be for Squeezelite
to restart, but we know that in your case this is not working - it fails
after 5 attempts. At this point, instead of issuing the restart command
manually from the command line, run the script manually from the command
line:
Code:
--------------------
/home/tc/SQLITE-control.sh restart M6 1-1.2
--------------------
I can't really see why this would make a difference, since that's
exactly how the script would be called by the triggering rule, so I
expect the logfile to show the same failure after 5 attempts, but let's
see.
Could you also post the output of 'dmesg' after this test?
** Another odd thing is that the result of your 'ps | grep squeezelite'
command shows that Squeezelite is still running, even though it appears
to have stopped. You could experiment by manually killing the process.
The digits at the beginning of the 'ps | grep squeezelite' output
indicate the process id (4226 in your earlier example). From the
command line you could issue 'sudo kill -9 <process id>' (e.g. 'sudo
kill -9 4226'), to see if that changes the subsequent behaviour.
------------------------------------------------------------------------
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
