Is it possible to switch off the lighning that shows undervoltage?
My Pi 3+ works fine, but when I play flac there constantly this lighning
flickers.
The power supply delivers 3A, that seems to be more then enough. Or is
there differnt problem I should investigate first?
3xPi3B-7"+pCP 6.0 |
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
I suspect that the hidden SSID is the problematic element, but I haven't
tested it, and probably won't now that it's working.
I was vaguely aware that "# Maintained by user" will allow me to create
a fixed config file that pCP won't later modify, but thanks for pointing
it out, as it made me
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.
Hi benh,
Good detective work! What you are saying is basically correct.
The "setup" method now hooks into an existing wifi setup process. It is
very simple, it takes a SSID and PSK and creates a wpa_supplicant.conf
that will work in the majority of cases.
Are you aware that adding "#
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
OK, I put the pCP on the same subnet as my LMS server, and now Jivelite
is magically working.
Keep in mind, Squeezelite has been working perfectly across subnets, but
there's something about Jivelite that breaks when that's the
configuration.
I'm curious about what it is.
Did I say 'a moment'? That was a frustrating hour and a half!
First I'd neglected to launch Squeezelite into the background, so I was
getting all sorts of confusing issues - sometimes things would work,
sometimes they wouldn't.
Second, some more of the basic built-in commands weren't doing
Just to be sure I'm not missing anything, I started over from scratch,
with a fresh image on the SD card, and set up a wpa_supplicant file on
that SD card from the beginning.
So, at no time was I ever connected to a wired connection.
Squeezelite works fine. I have to specify my LMS server,
I'm still trying to 'sort out the problems'
(https://forums.slimdevices.com/showthread.php?103330-Jivelite-for-piCorePlayer=1013061=1#post1013061)
I am having with Jivelite on piCorePlayer 7.0.1 on a Pi with a
touchscreen and am digging deeper. I found an issue unrelated to that
that I thought
Wait - I should have tested this at my end first. It doesn't work.
Give me another moment
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread:
I think this should create the PIDFILE and keep everything in sync.
Insert these two lines after the 'sleep $interval' line in the same
function, like this:
Code:
sleep $interval
PID=$(/bin/busybox pgrep /usr/local/bin/squeezelite | awk
Ah, yes, this is because the workaround is only partial at the moment -
it doesn't create the PIDFILE that is necessary for the other parts to
stay in sync. Give me a mo.
chill's Profile:
I spoke too soon !!
I was so excited it worked, I turned my dac off again. And sqlite was
NOT killed. and made the synced players skip.
And when I restart the dac sqlite won't play any music. It shows on
material. But when I soft on, all music stops and will not play, when I
soft off, the other
Success !
Sqlite now gets killed when dac off, and restarts when dac on. It's
showing not running in pcp web, but showing ok (and running ok) in
material.
Here's the log -
Code:
[ 15.10] Script parameters: find M6
[ 15.15] Searching for M6 with
Bogg wrote:
>
> Hi, It stops my sqlite, and now shows it not running in pcp web and also
> killed on material.
That's a start.
Bogg wrote:
>
> But I still get failed to start
Oh my, I wasn't expecting that. I really thought I'd cracked it. It
looks as though the start-stop-daemon is
I Think I accidently deleted my previous reply when I saw a typo lol.
Sorry if this ends up being a double post.
chill wrote:
>
> @Bogg - it would be interesting to know if this works on your system.
>
Hi, It stops my sqlite, and now shows it not running in pcp web and also
killed on
chill wrote:
>
> @Bogg - it would be interesting to know if this works on your system.
>
> PS - I've taken the bold step of giving this a version number 1.0.0
> (more digits than I'll need!), to help keep track :)
Hi, It stops my sqlite, and now shows it not running in pcp web and on
killed
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
I found that if the DAC is playing as part of a synced group, then it
causes the other players to stop after a while if squeezelite is unable
to send audio to the DAC. This doesnt happen if squeezelite is stopped.
A soft power-off would probably work too.
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
pgf wrote:
>
> 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
Here's a tidied up version that uses the 'forced' approach to stopping
Squeezelite - not the full 'kill-anything-that's-called-Squeezelite'
approach, just the 'synchronised' approach that uses the PIDFILE to kill
the specified process. This seems to work on my Pi3A+.
@Bogg - it would be
pgf wrote:
> 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.)
>
Thanks Paul - yes, contrary to what I
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
Hmm - well this is odd. I can make the kill command work if I specify
the location of the binary, i.e. 'sudo /bin/kill -9 $PID'. But I don't
understand that, because the path available to the script when called by
udev, although rather shorter than for a normal user shell, does contain
/bin:
Greg Erskine wrote:
> I only use "force" option on the command line. I'm wondering if $0 gets
> set correctly if calling from a script.
I think I got to the root of this. The line:
Code:
sudo ps | grep squeezelite | grep -v grep | awk '{print $1}' |
38 matches
Mail list logo
