uudruid74 wrote:
>
>
> It will give you output about what the current device is. Turning off
> the DAC should tell you the audio device is no longer available.
> Restore the DAC and it should detect it and restart squeezelite. Let me
> know what output it gives you.
Hello,
I'm asking
Greg Erskine wrote:
> I have noted this.
>
> Unfortunately it is not as simple as one expects. If we include the code
> we then become responsible for it, and there are also copyright
> obligations.
Understood. Thanks for clarifying this.
kitus wrote:
> Hello uudruid74! I can confirm this works like a charm. I'm now a happy
> camper. Thank you!!!
>
> To my opinion, this should be part of pCP core. Does anybody know how i
> one can officially propose this?
I have noted this.
Unfortunately it is not as simple as one expects. If
uudruid74 wrote:
> Did you reboot the system so that it starts usbconnectd?
>
> If no ...
> Restart the system from the web interface
>
> If yes ..
> Ssh into the system to a command prompt. See what it says when you type
> this ...
>
> sudo killall usbconnectd
>
> If it says "no process
uudruid74 wrote:
> Did you reboot the system so that it starts usbconnectd?
>
> If no ...
> Restart the system from the web interface
>
> If yes ..
> Ssh into the system to a command prompt. See what it says when you type
> this ...
>
> sudo killall usbconnectd
>
> If it says "no process
kitus wrote:
> Thanks for the detailed instructions! I've already added it as User
> Command #1 on the Tweaks tab.
>
> This is what I've done:
> > >
- I powered off my DAC
- pCP did not notice it. Squeezelite still appeared as green on the
> main page.
- I then restarted
uudruid74 wrote:
> Open the web interface for picoreplayer (not LMS). Go to the Tweaks
> tab. You'll see where it says "User Commands" at the bottom.
>
> You want the full name and path here. For example, if in the default
> user's home directory, it's ...
>
> /home/tc/usbconnectd
>
> If
kitus wrote:
> Would you mind pointing me to that post? I've searched for it across
> several pages, and I didn't find it. Once I manage to get it working,
> I'm happy to update your GitHub repo landing page with detailed
> instructions, if you allow me to.
Open the web interface for
uudruid74 wrote:
>
> Add it as your command to run at startup (there is a post about all that
> a few back).
Would you mind pointing me to that post? I've searched for it across
several pages, and I didn't find it. Once I manage to get it working,
I'm happy to update your GitHub repo landing
Man in a van wrote:
> @uudruid74
>
> Just for info
>
> VirusTotal flags both links as having malicious content :(
>
> ronnie
Added GITHUB link which solve that.
uudruid74's Profile:
Man in a van wrote:
> Well I'm just a civilian who happens to be strolling by. :rolleyes:
>
> I find there is, actually, a lot of humour I don't understand, and
> hence, do not find funny :confused:
>
> It must be an age thing and being a computer numpty :confused:
>
> But thanks for the
uudruid74 wrote:
> Just ran it from their website to see what you are talking about.
>
> Hastebin is a widely used site similar to pastebin. It has no malicious
> code and VirusTotal doesn't flag it at all. Its just a paste of the
> code "hastebin
> The eddon.systems link is only flagged
Man in a van wrote:
> @uudruid74
>
> Just for info
>
> VirusTotal flags both links as having malicious content :(
>
> ronnie
Just ran it from their website to see what you are talking about.
Hastebin is a widely used site similar to pastebin. It has no malicious
code and VirusTotal
@uudruid74
Just for info
VirusTotal flags both links as having malicious content :(
ronnie
Man in a van's Profile: http://forums.slimdevices.com/member.php?userid=43627
View this thread:
sbp wrote:
> For me the ranges is saved correctly if I add 44100-768000 in the max
> sample rate box in the UI and press The save button.
> Then checking the Squeezelite command string 'more>'
> (http://192.168.0.216/cgi-bin/squeezelite.cgi?#) I have the correct
> string -o
sbp wrote:
> For me the ranges is saved correctly if I add 44100-768000 in the max
> sample rate box in the UI and press The save button.
> Then checking the Squeezelite command string 'more>'
> (http://192.168.0.216/cgi-bin/squeezelite.cgi?#) I have the correct
> string -o
For me the ranges is saved correctly if I add 44100-768000 in the max
sample rate box in the UI and press The save button.
Then checking the Squeezelite command string 'more>'
(http://192.168.0.216/cgi-bin/squeezelite.cgi?#) I have the correct
string -o hw:CARD=sndrpihifiberry -a 80:4::1: -r
uudruid74 wrote:
>
> I am running the following version. How to update?
> >
Code:
> > Squeezelite v1.9.9-1391-pCP, Copyright 2012-2015 Adrian Smith,
2015-2021 Ralph Irving. See -t for license terms> >
>
> At the main page in pCP you use the update button to
ralphy wrote:
> I introduced a regression at r1109 that was 'fixed in 1.9.9r1392'
> (https://github.com/ralph-irving/squeezelite/commit/3fbf7ea5288fad99e76800ee566771bbbce49299)
> that caused squeezelite to exit instead of waiting for the audio device
> to appear.
>
> See 'issue 153'
I introduced a regression at r1109 that was 'fixed in 1.9.9r1392'
(https://github.com/ralph-irving/squeezelite/commit/3fbf7ea5288fad99e76800ee566771bbbce49299)
that caused squeezelite to exit instead of waiting for the audio device
to appear.
See 'issue 153'
slartibartfast wrote:
> Someone else had a similar issue. Their posts start here.
> https://forums.slimdevices.com/showthread.php?p=1012890
>
Yeah. The difference, as I noted above, is that my version doesn't
bypass the start-stop-daemon (or need to deal with the udev environment
at all),
uudruid74 wrote:
> Yes, that was from this thread. The script isn't the issue, but I
> wouldn't mind seeing the latest version (I'm NOT searching through 30
> pages!), but I doubt it would help
>
>
>
> Tried, but thats not the issue. Without sudo it just runs as whatever
> permissions
carsten_h wrote:
> Yes, I think that was the work from this thread. But it seems that there
> is not the whole script which is used in this thread.
>
> No, not really. Maybe you can try the last version of the script from
> this thread here.
Yes, that was from this thread. The script isn't
Try taking the "sudo" out.
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer - kiss, absolute, scala, jazzfm etc), kcrw, abc
australia and cbc/radio-canada
and, via the extra \"radio now playing\" plugin lots more - see
uudruid74 wrote:
> There is a how-to
> (https://docs.picoreplayer.org/projects/autostart-squeezelite-from-usb-dac/)
> that suggests this should be working.
Yes, I think that was the work from this thread. But it seems that there
is not the whole script which is used in this thread.
uudruid74
Greg Erskine wrote:
> hi carsten_h,
>
> I can't give you a definite answer but... here's a guess.
>
> I believe in pCP7 there was a problem getting the card name (from USB
> DAC) which caused errors restoring asound.state.
>
> The USB restart scripts worked around this.
>
> Maybe because we
hi carsten_h,
I can't give you a definite answer but... here's a guess.
I believe in pCP7 there was a problem getting the card name (from USB
DAC) which caused errors restoring asound.state.
The USB restart scripts worked around this.
Maybe because we fixed a few ALSA things in pCP8.0.0 it
Hello!
After installing pcp 8.0 with an insitu update squeezelite is not longer
starting at boot. The USB soundsticks are switched on but nothing
happens.
This is the pcp_Soundsticks.log file:
Code:
[ 12.73] Script parameters: find SoundSticks
[ 12.76]
Point taken. So pgf's original approach is best - init.d stop, followed
by pkill. Maybe add a short sleep between the two, to give squeezelite
a chance to finish its orderly shutdown.
chill's Profile:
It was more of a general thought from me (and also I probably should not
have said SIGHUP - that was just habit from the old days).
To me it feels better to ask an application to perform an orderly close
down before forcing it.
On pCP this is probably less important because there is probably
Paul Webster wrote:
> Given that the situation is relatively rare and that an extra few
> seconds is unlikely to make a difference then a
> SIGHUP then pause and check again and SIGKILL if still running should be
> OK.
Do you mean as a general purpose approach for the init.d script? For
this
Given that the situation is relatively rare and that an extra few
seconds is unlikely to make a difference then a
SIGHUP then pause and check again and SIGKILL if still running should be
OK.
Paul Webster
http://dabdig.blogspot.com
author of \"now playing\" plugins covering radio france (fip
paul- wrote:
> Are you guys using the absolute latest squeezelite package? The have
> been changes after pCP 7 was released that affected the -C option.
On my test Pi3A+ I've been using the Squeezelite version that was part
of the the pCP7.0.0 image: v1.9.8-1287-pCP. I've just updated to
Im not sure what you are expecting SIGTERM to do. This just tells the
program to shutdown normally. In all of these cases being discussed,
abnormal conditions are present, so the shutdown process is unable to
complete. Using an escalated termination signal is quite expected.
piCorePlayer
Are you guys using the absolute latest squeezelite package? The have
been changes after pCP 7 was released that affected the -C option.
piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please 'donate'
pgf wrote:
> 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
>
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
I removed the old udev script from my main Pi4B player, and installed
your new script (with a few personalisations: logfile named after the
audio card, player powered up in LMS after a restart, 'restart' split
into new-style stop and init.d start). It's working perfectly. Not
really a
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:
pgf wrote:
>
> 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
pgf wrote:
> If any of our dear readers know the answer, please let me know. ;-)
>
Ralphy's yer man for Squeezelite. He's already seen the thread, so I'm
sure he'll see your suggestions.
chill's Profile:
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
pgf wrote:
>
> 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.
>
That's brilliant, thanks Paul. I don't really see the benefit of the
udev approach over your approach. Your
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
pgf wrote:
> 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
>
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
pgf wrote:
> 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
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
>From the busybox source code (for debianutils)
(https://github.com/brgl/busybox/blob/master/debianutils/start_stop_daemon.c)
Code:
Options which are valid for --stop only:
-s,--signal SIG Signal to send (default:TERM)
Could the piCore
pgf wrote:
> Have you tried using SIGTERM again, rather than SIGKILL?
Well blow me - that works too. What signal does it send if you don't
specify one?
chill's Profile:
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
pgf wrote:
> 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
Well that's encouraging, in a way. What model RPi
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
ralphy wrote:
> pCP uses and includes 'JSON.awk' (https://github.com/step-/JSON.awk) to
> parse json output.
Haha - while I was browsing through the pCP source code to find an
example of JSON.awk in use, I found 'pcp_lms_power' (and all the other
defined functions). All the hard work has been
ralphy wrote:
> pCP uses and includes 'JSON.awk' (https://github.com/step-/JSON.awk) to
> parse json output.
Perfect - thank you for the tip.
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View
chill wrote:
> Ahem. It doesn't work reliably. Not surprising for a JSON newbie I
> suppose. It seems that the player details aren't always returned in the
> same order, so I can't 'awk' for the player name THEN the MAC address.
> I was hoping to get away without parsing the JSON rigorously
Greg Erskine wrote:
> Thx.
Ahem. It doesn't work reliably. Not surprising for a JSON newbie I
suppose. It seems that the player details aren't always returned in the
same order, so I can't 'awk' for the player name THEN the MAC address.
I was hoping to get away without parsing the JSON
Thx.
Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
___
unix mailing list
I changed 'sudo /usr/local/etc/init.d/squeezelite stop' to 'sudo
start-stop-daemon --stop --quiet -p /var/run/squeezelite.pid' in your
script, and it made no difference.
But then I discovered that the start-stop-daemon has the '-s' flag to
determine which signal is sent. And what do you know,
chill wrote:
> Aargh! Guess what. On my Pi3A+, the command
> '/usr/local/etc/init.d/squeezelite stop', when called within your script
> (with or without 'sudo'), only deletes the pidfile. It does NOT kill
> the squeezelite process. Exactly the same behaviour as I was seeing
> with the udev
Greg Erskine wrote:
> Where does the softpower function come from? I don't do json stuff.
Nor do I! I cobbled it together from other examples I found in
pcp-lms-functions.
chill's Profile:
Where does the softpower function come from? I don't do json stuff.
Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
Aargh! Guess what. On my Pi3A+, the command
'/usr/local/etc/init.d/squeezelite stop', when called within your script
(with or without 'sudo'), only deletes the pidfile. It does NOT kill
the squeezelite process. Exactly the same behaviour as I was seeing
with the udev script.
Calling 'sudo
pgf wrote:
>
> 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.
>
That was my feeling too. Isn't this the way a daemon works (something
like pigpiod that constantly watches for gpio events),
> 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
pgf wrote:
> 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".
>
That's great - so many neat little tricks that I've not seen before, as
befits a busybox
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
Very nice.
A minor point, I think your second comment should read: "# commands to
run when the device is unplugged go here".
coyrls's Profile: http://forums.slimdevices.com/member.php?userid=44253
View this thread:
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()
{
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
pgf wrote:
> Just a nit. This line, from your script, does _not_ create the pidfile
> using sudo:
> >
Code:
> > sudo /bin/echo "$PID" > $PIDFILE
>
> >
>
Ooh, thank you - I did wonder about that. Thanks for the tip about
tee.
pgf
chill wrote:
>
> I can't recall whether I've tried modifying the init.d script to use
> sudo with the start-stop-daemon. Something else to try
Made no difference. The daemon was unable to stop the process on my
Pi3A+.
I have a new Pi4B arriving tomorrow*, so I'm going to start afresh
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
pgf wrote:
> One more possible gotcha with the init.d script:
>
I'd say this counts as an edge case that is unlikely to arise, because
in normal operation pCP runs everything as root and everything stays in
sync nicely.
I don't believe these possible loopholes are what's behind the inability
chill wrote:
>
>
> So with everything in sync, ...
>
That's a bit of a red herring in this particular case, since my test
script calls the kill command without regard to the pidfile - purely for
test purposes of course. I then tidy up if necessary by deleting both
the pidfile and the
coyrls wrote:
> In bash, you can disable a builtin with "enable -n" but the busybox
> shell is ash, not bash and ash does not have the enable command. I have
> struggled to find decent documentation for ash but what I have found
> doesn't document any way to disable builtins. What is the
pgf wrote:
>
> I think there are a lot of places where scripts and test cases can go
> wrong without needing to investigate the kill command itself.
>
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
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
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
chill wrote:
> That makes sense, thank you.
>
> So assuming that's the case, is there a way to override the default,
> such that 'kill' (specified without a path) will use the busybox version
> in /bin?
>
> It still seems possible that the start-stop-daemon is using the default
> external
coyrls wrote:
> I think the "default" kill will be the shell built in version.
>
That makes sense, thank you.
So assuming that's the case, is there a way to override the default,
such that 'kill' (specified without a path) will use the busybox version
in /bin?
It still seems possible that
I think the "default" kill will be the shell built in version.
coyrls's Profile: http://forums.slimdevices.com/member.php?userid=44253
View this thread: http://forums.slimdevices.com/showthread.php?t=113661
chill wrote:
> I have a theory that I'd like to test, but I'm not sure how.
>
> I've now methodically repeated my earlier tests on my troublesome
> Pi3A+.
> 1) Called from within my own script (bypassing the init.d script), the
> command 'start-stop-daemon --stop -p $PIDFILE' reports that it
I have a theory that I'd like to test, but I'm not sure how.
I've now methodically repeated my earlier tests on my troublesome
Pi3A+.
1) Called from within my own script (bypassing the init.d script), the
command 'start-stop-daemon --stop -p $PIDFILE' reports that it has
stopped the process,
chill wrote:
>
> @Bogg - it would be good to know if this version still works in your
> case. Just replace the entire script. No need to re-run the install,
> unless you give this script a different name.
> v1.1.0 - 'workaround' version to bypass start-stop-daemon
Hi Chill,
I can confirm
I'm not sure how to tackle finding out why the start-stop-daemon doesn't
work consistently, but in the meantime...
The path available from within my udev script is:
Code:
/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
Compare that with the path
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
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
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
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
> 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
>
Yeah, I was wrong about 'restart' killing the old process. It doesn't
on the Pi3A+. Ok, so that's slightly more consistent - the 'stop'
function of the daemon doesn't seem to work at all.
I tried making the init.d script use /sbin/start-stop-daemon, but it
made no difference.
Thanks Paul, that's all useful information. I've noticed that some of
these commands that don't seem to work without specifying a path seem to
be exactly the same versions in the default shell and in the specific
binary location, whereas some seem to be different. For instance, awk
--help
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
I'll keep subscribing for the future updates, and just enjoy how well
things work for now.
Thanks
Bogg's Profile: http://forums.slimdevices.com/member.php?userid=50888
View this thread:
Bogg wrote:
> I'm very very grateful for all the effort you have taken Chill. I though
> when I first posted that I had just made a simple mistake that someone
> would point out and I'd be up and running like everyone else. Instead I
> caused hours of work to resolve all kinds of problem.
>
>
I'm very very grateful for all the effort you have taken Chill. I though
when I first posted that I had just made a simple mistake that someone
would point out and I'd be up and running like everyone else. Instead I
caused hours of work to resolve all kinds of problem.
Should I consider that
I'm very very grateful for all the effort you have taken Chill. I
thought when I first posted I'd made a simple mistake that someone would
point out and I'd be up and running like everyone else. Instead I caused
hours of work to resolve all kinds of problems.
Should I consider that script gold
Bogg wrote:
> Success Again !
> And better tested this time. I've on and off half a dozen times in a
> row, and it's reacted perfectly every time !
> The pcp web and skins are always in sync, sqlite is always killed, and
> always comes back.
> I've even rebooted pcp with the dac off. sqlite
Success Again !
And better tested this time. I've on and off half a dozen times in a
row, and it's reacted perfectly every time !
The pcp web and skins are always in sync, sqlite is always killed, and
always comes back.
I've even rebooted pcp with the dac off. sqlite doesn't start, and
switch
1 - 100 of 342 matches
Mail list logo
