Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
Greg Erskine wrote: > Is it a one wire device? > > Have you loaded the appropriate w1-.tcz extension? The DHT11/DHT22 family are not one-wire devices. They can be bit-banged, from either the kernel (if you have the drivers) or from userspace. Turns out doing it from userspace works just fine. I tried the example code for reading the DHT11 which is provided alongside the (excellent) pigpio package, downloaded from here: https://abyz.me.uk/rpi/pigpio/examples.html It works great. Easy to add temperature (and humidity) sensing to any pCP. (pigpio, and its dev environment, are packaged as pCP extensions.) paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
Thanks -- yes, I already have config.txt configured correctly, with: "dtoverlay=dht11,gpiopin=24". There are no mentions of the overlay (or the string "dht" in the kernel log. But you did send me off to do more searching. I've been assuming that I want to use the kernel driver for the DHT devices, which would require the modules I'm looking for. I'm an old OS guy, and in general a kernel driver will be more efficient and/or more reliable than a user level driver. But it seems that many folks aren't happy (at all) with the quality of the current linux driver, and that user-level access to the gpio may actually work better. There are a couple of ways to do this -- with either python code, from Adafruit, among others, or with C code, using an example provided with the pigpio library. I'll give one of those methods a shot. (Though I'm still curious as to where to find the dht and industrialio modules, if anyone knows. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
I'm having a surprising amount of trouble finding the (presumably!) pre-built dht11 and industrialio kernel modules, which are needed for a DHT22 temperature sensor I'd like to add to one of my pCP boards. The DHT11 is supported by a dtoverlay, so I'd be surprised if the driver's dependencies weren't built. Having said that, I'd like to verify that the modules were indeed built, but can't find a copy of the kernel config file. Any pointers, on any of the above? I'm running the latest 8.2.0, linux 5.15.35-pcpCore-v7 pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
mr-b wrote: > > Is there any way to have a notification of pCP updates ( or other > component updates) e.g. like LMS? > If you have a way of monitoring a website for changes (there are free services for this, and android apps, and fairly simple shell scripts), then you could set up to be notified when either https://docs.picoreplayer.org/releases/ or https://repo.picoreplayer.org/insitu/ is modified. That's what I do. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] How/where is .filetool.lst created?
Okay. Non-published repo? Really? That definitely make pCP an outlier! :-) Good to know, though -- I'll stop looking. ;-) My local mods aren't all that big. Mostly a few long-running scripts that I start from "User command #1", which lives in /home/tce. I think I also needed to have /root/.asoundrc saved. I forget why, at the moment. I think it might have had to do with USB audio and hotplugging. I've done my upgrade (7.0.1 --> 8.0.0 --> 8.0.1) and it all seems to have worked fine. It looks as if .filetool.lst was changed, buy my additions were preserved. I guess if it's expected that packages might modify it, then it makes sense that its contents would be preserved on upgrade. That's perfect, for my use. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=115753 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
Got it. I'm on my own. ;-) Thanks! pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
[SlimDevices: Unix] How/where is .filetool.lst created?
I've looked for .filetool.lst in git, but it's not jumping out at me, and the fact that it and .xfiletool.lst are both dot-files makes me think they must be created from some other list or tool. In order to get few more things backed up (since they contain local mods), I've added several lines to .filetool.lst. Then in order to be sure -that- gets backed up, I added .filetool.lst to itself. This was fine, I believed, until today, when I realized that if the release maintainers have added something new of their own to .filetool.lst, then my backup will overwrite that change after I upgrade. So, I'll do something different to track my changes in the future, but for right now, I'd like to know whether .filetool.lst has changed between 7.0.1 and 8.1.0. I need to know this both to see if it has changed, as well as to verify my local changes. But I can't find it. Pointers? pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=115753 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: piCorePlayer 8.0.0
A couple of questions, before I do my first in situ upgrade. I assume that anything backed up (i.e., listed in /opt/.filetool.lst) will survive the insitu upgrade, correct? Likewise, the modules installed via onboot.lst? I'm running 7.0.1. Is it okay to upgrade straight to 8.1, or do I need to install 8.0 first? Related: Is there a "release announcement" thread, or a github folder I can subscribe to, to learn of new releases without having to monitor the forum? Should I just periodically check https://repo.picoreplayer.org/insitu/ for changes? What I'm currently running calls itself 7.0.1 at the bottom of the web pages, but I don't see 7.0.1 upgrade files at that location -- which makes me wonder if upgrades can come from elsewhere, as well. Many thanks! (And thanks, in general, for pCP. Fantastic project.) paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=114828 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
FYI, Ralph just helped me learn (while diagnosing the SIGTERM thing) that the shutdown bug doesn't happen if -C is used. I get the impression (and I'm going to confirm with him) that -C should always be used with USB devices that might be unplugged or turned off. (Clearly it should shut down correctly in either case, of course.) pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
coyrls wrote: > Submit an Issue at https://github.com/ralph-irving/squeezelite ? Perfect. Thank you. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Sure, maybe separating out the stop/start, and adding in the pkill, would be better. In my testing I never saw an issue with the restart, but it could be safer. Since the restart is happening when the device is present, the squeezelite shutdown bug may not be triggered. What should really happen is a) squeezelite should fix the SIGTERM shutdown bug, and b) the init.d script should be scrubbed to eliminate some of its issues. Maybe I'll figure out how to submit a bug against squeezelite. If any of our dear readers know the answer, please let me know. ;-) paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
In any case, I won't be adding that to my script, because none of those
commands will work on my system. (I connect to the LMS server via an
ssh tunnel, so my LMS server address is actually localhost. I use a
custom -s option on the squeezelite config page to do this.)
So here's my current script. To properly support lots of custom
operations when the device comes and goes it should really run a set of
scripts from a "device-appears" and a "device-goes-away" directory. But
that starts to sound a lot like recreating udev, so I'm not going to do
that. ;-)
You should do whatever you want with this, though now that you have a
good workaround for stopping squeezelite properly, maybe you'll just use
your script.
paul
Code:
#!/bin/sh
# watch_usb_audio -- a script to stop/restart squeezelite when a
# removeable audio device comes and goes.
# logging to a name starting with "pcp_" causes output to display
# under "Diagnostics" in the web interface.
logfile=/var/log/pcp_watch_usb_audio.log
exec >$logfile 2>&1
usage_header()
{
# Not a traditional usage message. More like a short README,
# shown at the start of the log.
cardname=${alsacard:-} # use $alsacard, or ""
cat
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Any reason you can't just use the "pcp" command (which I just stumbled across). Seems safer than loading their internal files. Code: ==kitchen(tc)>> pcp help = Basic piCorePlayer CLI - Squeezelite/LMS --- - pcp play : play current track in playlist - pcp stop : stop current track - pcp pause : pause current track - pcp up : volume up - pcp down : volume down - pcp next : next track - pcp prev : previous track - pcp rand : generate random playlist - pcp power [on|off] : software power on or off - pcp volume [0-100] : set volume between 0 to 100 - pcp rescan : look for new and changed media files in connected LMS library - pcp wipecache : clear connected LMS library and rescan - pcp mode : display Squeezelite's current mode - piCore -- - pcp bu : (b)ack(u)p - pcp sd : (s)hut(d)own - pcp bs : (b)ackup then (s)hutdown - pcp rb : (r)e(b)oot - pcp br : (b)ackup then (r)eboot - piCorePlayer - pcp d0 : debug off - pcp d1 : debug on - Jivelite - pcp kj : (k)ill (j)ivelite - pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
No -- SIGTERM is the default, for all versions of kill/pkill/killall. For some reason, if the audio device has gone away (probably not a well-tested scenario), one of squeezelite's threads doesn't die from the first kill -TERM, but does die from the second. I've put a similar workaround in my script. I want to look at your soft power-off code, then I'll publish a new version. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Have you tried using SIGTERM again, rather than SIGKILL? pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
You'll be happy to know I'm seeing an incomplete kill of squeezelite on my system as well. I'll look into it. Note that squeezelite, while not killed completely, has been crippled: 2 of its 4 threads do die. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
> The cardname is then part of the $OUTPUT variable, e.g. > "hw:CARD=DragonFly,DEV=0", from which 'DragonFly' would need to be > extracted. > I can make that be the default, but I'll allow overriding it on the command line. > 2) Do you have any thoughts on the frequency that this script checks for > the DAC? You've currently set 4 seconds, but how much of a drain on > resources would it cause if that was, say, 1 second? Maybe make this a > command line argument? > Anything would work. I can make it 1 second. I confess it makes me twitch a little, but 1 second is eons in modern computer clock speed time. > 3) If you put the log file in /var/log/, and precede its name with > 'pcp_', it will show up in the pCP -> Diagnostics -> Logs page, so users > won't have to use a separate shell to see what's going on. It needs root > permissions to write to this folder, but I think that's OK because User > Commands are run as root. > Okay. Didn't know about that. Can do. > 4) For my own setup I prefer that Squeezelite is soft powered on when > the DAC is turned on, regardless of its previous soft power state, so > I've been learning about the necessary JSON commands to do that this > evening. So for my own copy I'm going to add a function to do that and > add it to the commands that are run when the device appears. > You go guy! I have no idea what you're talking about. :-) > 5) There's at least one user of the udev script who does not want > Squeezelite to be killed when the DAC is powered off. I added the > --nostop option so that the 'remove' udev rule was omitted in the > installation. I wonder if a --nostop command line option could be added > to your script to achieve the same result. > I'm not sure what a --nostop would do. All I call is "restart" now, not "stop". If they don't want "restart" either, then... why would they run this script? The only thing that happens right now when unplugging the device is a log message. > Whilst I'll be happy to do these modifications for myself, I'm more than > keen to see how an experienced programmer would make them . I > learn a little bit more every time I look at someone else's code. > Don't worry -- my sense of ownership will fade very quickly, and I'll be happy to let you take over. ;-) pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Heh. Yup. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Since you're thinking of looking at my script, here's a cleaned up
version. It makes it a little more obvious where to put one's
commands.
I call it "watch_usb_audio".
Code:
#!/bin/sh
exec >/home/tc/watch_usb_audio.log 2>&1
audiodev=$1
usage()
{
cat <&2
usage: $0 audio-device-name
The only argument to this script should be your USB audio device
name, as seen in /proc/asound. On my machine my Harman Kardon
Soundsticks show up as "Soundsticks":
$ ls -F /proc/asound
Headphones@ card1/ hwdeppcm version
SoundSticks@ cardsmodules seq/
card0/ devices oss/ timers
EOF
exit 1
}
if [ ! "$audiodev" ]
then
usage
fi
log()
{
echo $(date +%Y-%m/%d-%X) "$@"
}
device_present()
{
test -e /proc/asound/$audiodev
}
wait_for_device()
{
while ! device_present
do
sleep 4
done
}
wait_for_device_to_go_away()
{
while device_present
do
sleep 4
done
}
watch_usb_audio()
{
while : loop forever
do
wait_for_device
log $audiodev is now present
# commands to run when the device is plugged in go here
alsactl restore
/usr/local/etc/init.d/squeezelite restart
wait_for_device_to_go_away
log $audiodev has vanished
# commands to run when the device is plugged in go here
done
}
log "Watching for USB device '$audiodev'"
if ! device_present
then
log Device not present at startup. Will wait...
fi
watch_usb_audio &
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
chill wrote: > > More good advice, thank you. But why is it a bad habit? > > When a process receives a signal, it usually has a chance to do something -- in fact, some signals are -only- used for "doing something", and don't kill a process by default. They might be used to tell the process to re-read its config file, for instance. But even if it's being told to die (which is what SIGTERM, the default signal from kill) is usually used for, it still might want to flush some output buffers, or if it has created its own pidfile, it might want to remove it. At the very least, the process might want to log that it's dying because of a signal. So it would do any of those things before calling exit. Now, a misbehaved (or buggy) process might catch your SIGTERM signal and then not exit. That's what SIGKILL (i.e., kill -9) is for. SIGKILL can't be caught and handled by a process -- it just kills it immediately. If you use it by habit, you may be preventing the process you're killing from doing an orderly shutdown. Kind of like pulling the plug on your PC instead of typing shutdown. It'll usually be fine when you start it back up, but then that one time ;-) pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
chill wrote:
> Thanks for taking a look in that much detail. I'd love to agree with
> your final statement, but I've been very careful to make sure that the
> pidfile and the process stay in sync. My current test script avoids the
> init.d script altogether - it starts Squeezelite manually (it doesn't
> use 'sudo', but since it's called by udev the process is owned by root
> anyway), and the pidfile is created with 'sudo bin/echo...' (perhaps the
> sudo isn't necessary for the same reason that the script is run under
> udev).
>
Just a nit. This line, from your script, does _not_ create the pidfile
using sudo:
Code:
sudo /bin/echo "$PID" > $PIDFILE
The echo runs as sudo, but the redirection into the pidfile is done as
the non-sudoed script. In the shell language, redirections belong to
the shell, not the command that they're redirecting. There are various
workarounds, but the most popular I think is to use tee to write the
file for you. (It turns out there aren't that many programs which will
simply take stdin and put it into a file. Using tee for this is
convenient, even if you have to discard the output from tee itself.)
Code:
echo $PID | sudo tee $PIDFILE >/dev/null
As you say, the distinction should be moot, if it's being run from udev,
so as I said, this is just a nit, and an FYI.
>
>
> So with everything in sync, the default 'kill' is NOT able to kill the
> process, whereas /bin/kill IS. In both cases, the kill command is being
> called directly by the udev script (i.e. without invoking the
> start-stop-daemon) in response to the DAC being unplugged,
>
> And of course there's the other thorny little complication that the
> behaviour of 'start-stop-daemon stop' is different on my Pi4B, where it
> works.
I still don't believe that "kill" will do anything different than
/bin/kill, given the two are running in an identical environment. (I
also don't believe you should be using "-9" everywhere. Squeezelite
dies perfectly happily with a plain "kill". Using -9 is a bad habit.)
I do have a couple of other comments on and questions about your script,
if you don't mind. Not that I see anything explicitly wrong, but maybe
they can be simplified, and simpler code is easier and safer.
First:
Code:
# Set DAEMON to the actual binary
[ -f $TCEMNT/tce/squeezelite ] && DAEMON=`readlink $TCEMNT/tce/squeezelite`
|| DAEMON=/usr/local/bin/squeezelite
# Legacy check, incase this is the binary instead of symlink.
[ "$DAEMON" = "" ] && DAEMON=$TCEMNT/tce/squeezelite
Is there any reason not to just use the shell to find the binary? And,
why does it matter if it's a symlink.
Code:
DAEMON=$(which squeezelite)
Second:
Code:
$DAEMON -n "$NAME" .&
sleep 1
local PID=$(/bin/busybox pgrep $DAEMON | /usr/bin/awk '{print $1}')
sudo /bin/echo "$PID" > $PIDFILE
Anything wrong with letting the shell tell you the PID? That's what $!
is for. It always contains the pid of the last process put into the
background.
Code:
$DAEMON -n "$NAME" &
echo $! >$PIDFILE
Lastly, even though you're no longer using the init.d script to
start/stop the daemon, you're still using it to check the daemon's
status. But all it does when you ask, is checks to see if the pidfile
exists. You should also also check to see if the process represented by
that pidfile exists. You can do that with the "-0" option to kill:
Code:
if [ -e $PIDFILE ] && kill -0 $(cat $PIDFILE)
then
echo process is running
else
echo no process found
fi
Anyway, I'm sure you'll figure out your problem. You set yourself a
lofty goal when you started this project, and you've done well so far!
paul
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
One more possible gotcha with the init.d script: run the start script, using sudo. run the stop script, without sudo. the pid file is now gone, but the squeezelite processes are still there. run the start script again, using sudo. the script doesn't see a pidfile, so it starts a new squeezelite, and records its pid. but that squeezelite can't run, because another instance is already running. so it dies. you still have the old squeezelite running, but the pidfile is now incorrect. Code: ==kitchen(tc)>> sudo killall squeezelite ==kitchen(tc)>> sudo rm -f /var/run/squeezelite.pid ==kitchen(tc)>> sudo /usr/local/etc/init.d/squeezelite start Starting Squeezelite player: Squeezelite... ==kitchen(tc)>> cat /var/run/squeezelite.pid 4918 ==kitchen(tc)>> /usr/local/etc/init.d/squeezelite stop Stopping Squeezelite player: Squeezelite... start-stop-daemon: warning: killing process 4918: Operation not permitted ==kitchen(tc)>> cat /var/run/squeezelite.pid cat: can't open '/var/run/squeezelite.pid': No such file or directory ==kitchen(tc)>> sudo /usr/local/etc/init.d/squeezelite start Starting Squeezelite player: Squeezelite... ==kitchen(tc)>> ps | grep s[q]ueeze 4918 root 0:00 /usr/local/bin/squeezelite -n kitchen -o hw:CARD=SoundSticks,DEV=0 -a 80 4 1 -m 00 00 00 00 00 41 -s localhost ==kitchen(tc)>> cat /var/run/squeezelite.pid 4944 Honestly, chill, I'm surprised you've done as well as you have, given the tools you're working with. :-) pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
kill (from within ash) and /bin/kill (linked to busybox) are the same
program, almost. The version in ash has to first handle job ids ("kill
%2"), but then the common code is called. start-stop-daemon doesn't
invoke a kill program at all. Like any reasonable program, it simply
invokes the kill() system call itself.
But decades of doing shell programming on unix/linux tell me that your
problem isn't because kill isn't doing its job. There's something else
wrong -- either kill isn't really being invoked, or its trying to kill
the wrong process, or the pidfile contains the wrong pid, or something.
Regarding the script /usr/local/etc/init.d/squeezelite: if it finds
/var/run/squeezelite it thinks it's running. If it doesn't find it, it
thinks it's not. That would be fine, except:
If I kill squeezelite manually, with killall squeezelite, or pkill
squeezelite, the processes go away, but the pid file remains.
If (after removing /var/run/squeezelite.pid) I invoke
"/usr/local/etc/init.d/squeezelite start" *without* sudo, squeezelite
will happily start, running as the user "tc", but the pidfile won't be
created (because tc doesn't have permissions to write to /var/run).
Running the script again whether as tc or as root, yields "Squeezelite
is not running.", simply because the pid file doesn't exist.
Alternatively, if I run the ".../squeezelite start" with sudo, and then
run the "stop" without sudo, then of course the processes are left
running (tc doesn't have permission to kill them), but the pidfile is
removed!! That's because the init.d script uses "sudo rm -f $PIDFILE".
Sigh. If it's going to remove the pid file with sudo, it should invoke
start-stop-daemon with sudo. But really, why is a system script using
sudo at all??
I think there are a lot of places where scripts and test cases can go
wrong without needing to investigate the kill command itself.
paul
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Greg Erskine wrote: > I notice Paul has installed the gawk/awk extension, probably gnu?. You > have to be careful not to develop code on requires the use of the full > blown version of the command without handling the installation of the > extension. > > We have been caught before installing gnu wget. We used the -s option > and it is not available, gnu wget uses --spider. Ooops. My bad. I thought I was fetching examples on a fairly pristine pCR, but I had misremembered, and was using the one I'd installed the development toolchain on. So the fact that gnu awk was installed on my machine has no bearing on chill's problems. Sorry for any confusion. But that's something to check Bogg's (was that who it was?) system -- are there extensions installed that could change how things work? paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
chill wrote: > Thanks again - very instructive, and it gives me something to look into > tomorrow. I know that the path available to a script called by udev is > indeed rather shorter than the one available under a user shell (i'll > post it again tomorrow). But does this make a difference if a command > is part of busybox? If it's part of busybox, does it even bother to > look in the path for a separate binary? Or do I have this wrong, and > the busybox commands ARE all separately linked to somewhere in the > path? > You answered your own question: the busybox builtins (like awk, sort, not the ash builtins like cd and alias) are found via PATH, because they're symlinked into various traditional bin directories. If a busybox builtin isn't linked into any of those places (unlikely) it can still be run with "busybox cmd ..." if need be. But they won't be found "automatically" simply because they're part of busybox. > And assuming the busybox built-in version is found, what could cause a > built-in command to fail when called in the udev environment (on some > setups), whereas the explicitly specified binary doesn't? > I don't know the answer to that. It's possible that the behavior of busybox is affected by environment variables (I could imagine a variable to enforce POSIX compliance, for instance). But other than that, invoking by full path shouldn't change anything, unless the full path is getting you a different executable (as in the case of the two awks on the system). paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
> For instance, awk --help reports 'BusyBox v1.31.1 (2020-12-18 22:25:41 > EST)' when called as either awk or /usr/bin/awk, whereas '/bin/echo > --help' reports 'BusyBox v1.31.1 (2020-12-18 22:25:41 EST)' but without > the path it simply echoes '--help'. So I'm curious where the separate > executables come from. Are some simply links to the busybox versions, > whereas others are standalone binaries? Yeah, it can get confusing. On pcp, a command can be provided by a) ash itself, b) a busybox builtin (invoked either via a symlink from 'cmd' to busybox, or "busybox 'cmd'"), or c) from a separate executable entirely. bash is friendlier than ash in that it provides a builtin command called "type" which, if you invoke "type -a cmd" will tell you everywhere in your shell, or along your PATH that 'cmd' can be found. Sadly, ash's "type" command has no '-a' option, and will only tell you about the first version of 'cmd' that's available, and will stop. So "type echo" only prints "echo" (note the absence of slashes) and "type awk" only prints "/usr/local/bin/awk". The good news is that "which -a" will find everything in your PATH. So you if you use both commands, you get all the information you need. Some might be duplicated. So: Code: $ $ type echo; which -a echo echo is a shell builtin /bin/echo $ ls -l /bin/echo lrwxrwxrwx1 root root 7 Jan 1 1970 /bin/echo -> busybox* $ $ type awk; which -a awk awk is /usr/local/bin/awk /usr/local/bin/awk /usr/bin/awk $ $ ls -l /usr/local/bin/awk /usr/bin/awk lrwxrwxrwx1 root root17 Jan 1 1970 /usr/bin/awk -> ../../bin/busybox* lrwxrwxrwx1 root root34 Jan 1 1970 /usr/local/bin/awk -> /tmp/tcloop/gawk/usr/local/bin/awk* There are two versions of echo on the system. I'd be surprised if they behave differently -- since they're both provided by busybox. There are also two versions of awk, but in this case one is provided by busybox, and the other by an extension. I suspect the built-in version is more primitive than the external one. So I suspect udev is invoked with a different PATH than you're using. Most likely it doesn't include /usr/local/bin -- if I were writing critical system code, I wouldn't rely on /usr/local/bin either. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
chill wrote: > > Anyone know how I can check for these built-in commands from within a > script? What makes them 'built-in' - is it some default shell > configuration? Could I manually load that configuration at the start of > the script, so that even if these built-in commands aren't available to > udev they would be to the script? I can probably help with this. I used to contribute patches and bug fixes to busybox pretty often -- we were using it in an embedded product I was working on. First, there are two kinds of "built in" with regards to the shell. All shells (ash, bash, zsh, csh) have some number of commands that are implemented internally to the shell. "cd", for instance, couldn't be done by an external program -- the external program would change directroy, and exit, and leave the shell where it always was. So "cd", "alias", "bg", fg", "read", etc are always built-in, because they have to be. "echo" and "kill" don't have to be, but for efficiency they usually are. echo is built-in for efficiency, kill is built in because it can be smarter if it is. Note that just because a command like echo or kill is built-in to the shell, it doesn't mean there isn't also a regular program by that name in the filesystem. Try "type -a echo" or "type -a kill" at a bash prompt, for instance. That lets other programs besides the shell run them if they need to. All of the above is true with or without busybox. Busybox adds another layer of "builtin-ness". When two programs are compiled (like "mv" and "cat", say) they end up containing a lot of redundant code. Even if they both use shared libraries for things like printf, or for reading and writing files, they still each have their own argument parsing, their own usage message, maybe some other common code idioms. If you took mv.c and cat.c and merged them into one executable called "twoprogs", you could imagine that "twoprogs" might be smaller than the sum of the sizes of the separate mv and cat. And you could still get with behavior with "twoprogs mv file1 file2" or "twoprogs cat file". Busybox is a merge like that, of a whole lot of programs. Do an "ls -l /sbin /bin /usr/bin | less" on a pcp box, and/or type "buybox --help" to get a list of all of the programs that are merged into one. And now, back to your problem: if awk isn't working without a full path, or pgrep isn't working without "busybox pgrep", it's really unlikely to be busybox's fault. busybox is a very mature program (I worked on it over 10 years ago), and is really unlikely to have the problems you're describing. (awk, for instance, isn't part of busybox -- it's an extension, I believe.) I'll stop now. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Gotcha -- thanks. Not a worry for me, but nice to know in case I ever hit it. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Is there a reason to want squeezelite stopped explicitly? Perhaps I missed something in one of the preceding pages about that. (I'm wondering if I should be doing it.) If you did want to stop squeezelite explicitly, you might want to wait a bit before doing so (perhaps just move the sleep to the top of the "not present" loop, and make it longer). Squeezlite is tolerant of the device going away for a short time, and it would probably be convenient to be able to unplug/replug the device quickly (to rearrange the cables on one's desk?) without losing your stream. In any case, you'd want to play with it. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Well, kill is an ash builtin, so without the full path, that's what you're getting -- but that alone doesn't explain why it doesn't do its job. (It's unlikely to be an internal ash problem in any case -- ash is a very good shell.) And as an aside: an old trick for keeping grep from returning it's own PID from a ps listing is to give grep a pattern which won't match itself: Code: ps | grep s[q]ueezelite Another trick is to use pkill, which is specifically designed for killing processes by attributes other than PID. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 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
Re: [SlimDevices: Unix] Start/restart squeezelite when plug-in USB dac
Whoa, this is fast-moving thread! I thought I was all caught up, and
suddenly there are another dozen messages! :-)
I'm pretty impressed by chill's script. Nice work. Keeping track of
all that statefulness, via multiple entry points to the script, is
tricky. The self-installation is a nice touch.
I found the thread while looking for something somewhat related, and
thought I'd share my (partial) solution to the USB audio detection
problem. I also happen to have a set of H-K Soundstick speakers, which
I've only recently hooked up to picoreplayer. Keeping things going when
the speakers are turned off or unplugged is an issue.
So... my script relies on polling (which doesn't worry me in the
least), and probably won't cover many corner cases, but it serves my
purposes. It relies on the USB audio device coming and going from
/proc/asound when it's un/plugged.
The script is invoked as one of the "user commands" on the Tweaks page.
The copy here is trimmed from the script I actually run, since mine does
some other unrelated stuff as well, but I don't think I've introduced
any new bugs. It's pretty simple -- hope it might help someone.
paul (another one)
Code:
#!/bin/sh
watch_usb_audio()
{
# loop forever
while :
do
# loop while the device exists
while [ -e /proc/asound/$audiodev ]
do
# if it only just became available...
if [ "$prev_usbaudio" != "present" ]
then
alsactl restore
/usr/local/etc/init.d/squeezelite restart
fi
prev_usbaudio=present
sleep 4
done
# loop while the device doesn't exist
while [ ! -e /proc/asound/$audiodev ]
do
prev_usbaudio=notpresent
sleep 4
done
done
}
audiodev=SoundSticks
watch_usb_audio &
exit
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
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
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
Thanks -- last time I tried to get something from the tinycore repo I had trouble finding a download link. I think I was successful eventually, though -- oh, I remember, I had to go to a mirror -- I'll try that. Thanks! paul (a different one.) pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=113512 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
I have a program that I've been running for years on various systems which, when built on picoreplayer, surprised me with a segfault. I went looking for gdb, and ... was surprised again. :-) Is gdb hidden in some unexpected extension? My system version is: piCorePlayer v7.0.0 | www v00011 | linux 5.4.83-pcpCore-v7 | piCore v12.0pCP | Squeezelite v1.9.8-1287-pCP Also -- in case the fault is toolchain-related, I assume that "compiletc.tcz" is the right toolchain, for this version of the system, right? I'll find the fault with successive printf's eventually, but a debugger would be convenient. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=113512 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
paul- wrote: > That is the right place to do it. The backup process stores ownership > in the backup file.and restores ownership during boot. Thanks. The other part of my question is: does the .filetool.lst file get overwritten on an upgrade? I guess I'll find out someday, but forewarned is forearmed. pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=113512 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
As mentioned in my previous post, I've modified /opt/.filetool.lst in order get the contents of /root backed up in mybackup.tgz. Is this "safe" to do? will .filetool.lst get overwritten during an upgrade without me knowing about it? If so, is there another way to add files to the backup? paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=113512 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
> On 2/24/2021 1:43 PM, paul- wrote:
> > pgf wrote:
> > [... wants to let two audio sources use pCP's output at a time...]
> >>
> > Squeezelite on pCP directly accesses alsa. Only one process can
> access
> > the alsa device at time, so you will need to do a full pulseaudio
> system
> > to do what you want. You might try to build your system up with
> > RaspiOS, or use piCore directly.
> >
> >
>
> If the hardware supports it, two processes can share the same alsa
> output by using the "dmix" device. With squeezelite I was able to get
> two processes to share the Analog Output using the same dmix device. I
> guess I was thinking that I could switch between streams by pausing one
>
> and starting the other in LMS but I never pursued it.
>
> I don't know if pCP would support that.
>
> John
Thanks -- I had given up on using dmix years ago when pulseaudio solved
my problems so well, but in fact, just yesterday afternoon I implemented
this, and it (almost) works just fine.
I've created a .asoundrc file that looks like this, in both /root and
/home/tc (and I've added /root to /opt/.filetool.lst, so /root gets
backed up):
Code:
# taken from:
#
https://stackoverflow.com/questions/7002423/how-to-mix-multiple-pcm-streams-using-alsa
pcm.hw1mix {
type dmix
ipc_key 1939 # must be unique
ipc_perm 0666 # mixing for all users
slave {
# pcm "hw:1"
pcm "hw:CARD=sndrpihifiberry,DEV=0"
period_time 0
period_size 1024 # must be power of 2
buffer_size 4096
rate 44100
}
bindings {
0 0
1 1
}
}
pcm.!default hw1mix
After doing that, "hw1mix" now appears in the pCP device selection menu.
If I select that, squeezelite will use it happily, and my HifiBerry
AMP2 works with two "inputs".
It's necessary to put the .asoundrc into a) /root so that it affects
squeezelite's view of alsa, and b) into /home/tc to affect tc's view.
tc needs it because I'm running a poor-man's network audio server. On
the remote host that has something to say, I run (essentially):
Code:
$ ssh tc@picore aplay < myannouncement.wav
There's probably a way to avoid the duplication of .asoundrc -- I'll
look into it.
The other issue I have is that when pCP first boots, squeezelite doesn't
come up -- it fails because hw1mix isn't available. If I simply restart
squeezelite, it works fine. I'll either figure out a fix, or a
workaround.
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113512
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
I'd like to try an extension that's available for TCL, but not listed as
available for pCP.
Is there a way to configure pCP to access a TCL extension repo?
Specifically, I'd like to install pulseaudio. I currently run about
half a dozen CHIP ("$9 computer") boards around the house -- they run
squeezelite for music, and also pulseaudio so that I can feed them home
automation announcements, etc. across the network. I don't know whether
squeezelite uses the pulseaudio install or maybe goes direct to also,
but the end result is that both audio sources (i.e., an LMS stream, and
a home automation caller-id announcement, for example) can both play at
the same time. As my CHIPs die over time, I'd like to replace them with
raspberry pi boards and pCP, but I need this functionality.
Thanks,
paul
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=113512
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] ANNOUNCE: piCorePlayer 7.0.0
There's a typo in the help for setting an alternate MAC address for squeezelite. The term "overwrite" is used -- I'm sure that what was meant was "override". Clearly this config doesn't actually overwrite a system MAC address, which would make the option a little scarier than it actually is. I know I did a double-take. (I use this feature, to give my clients predictable mappings in the LMS.) (And, since I'm a first-time user of picoreplayer, though a long-time user of squeezelite and LMS, please feel free to tell me where I -should- have reported this...) paul 33421 +---+ |Filename: typo.png | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33421| +---+ pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=113512 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Debian repository issues
mherger wrote: > > is there a low-volume release announcement mailing list? if updates > > aren't automatic via repository, i'm afraid i might forget to check > for > > new LMS releases for a very long time. > > We have added an update checker to LMS a long time ago. But it's > disabled for Linux, as at the time we decided to let the Linux package > manager deal with it. Now the situation has changed. I'll re-enable it > for Linux systems. > that would be good. thanks. > > Windows/OSX even have automatic download of the updates enabled. Is this > > something you'd consider useful? > i'd really prefer that updating use the standard repo-based mechanisms, rather than a home-grown solution. is it simply a question of manpower that LMS isn't in the distro repos? or is there some other corporate policy or licensing issue that i'm unaware of? pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=103897 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Debian repository issues
is there a low-volume release announcement mailing list? if updates aren't automatic via repository, i'm afraid i might forget to check for new LMS releases for a very long time. paul pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510 View this thread: http://forums.slimdevices.com/showthread.php?t=103897 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
