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