bluetdi wrote:
> Not really helpful your reply. I want to turn off the lightning.
If you think it is not helpful, why are you looking now for a new power
supply?
I told you that the voltage of your power supply is not enough for the
Pi and that is the reason for the lightning.
pi4 4gb
Thanks for your answers.
I read some reviews of PS for the Pi with a 7"-screen and now ordered
the official one. It will be delivered tomorrow and I hope it has enough
power for both so the lighning disappears. My other 2 Pi with screen
dont have this problem so I presume it must be the PS
> 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
NoobNR7 wrote:
> Jeff you saved my day/ saved me days...
>
> You made me realize I was thinking the wrong way around...
>
> It's working! :D:D:D
>
> Man that was easy:cool:
> Haha...
>
> I will try some other stuff. Very satisfying after struggling for hours.
> Making it so difficult.
Jeff07971 wrote:
> When using the Flirc USB Dongle you do not use lirc or keytables, the
> FLIRC emulates a keyboard
>
> So program the FLIRC dongle to send the appropriate keys for the remote
> control operation you want
>
> Jeff
Jeff you saved my day/ saved me days...
You made me realize
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:
Jeff07971 wrote:
> When using the Flirc USB Dongle you do not use lirc or keytables, the
> FLIRC emulates a keyboard
>
> So program the FLIRC dongle to send the appropriate keys for the remote
> control operation you want
>
> Jeff
Thank you Jeff for answering my question.
I bought the flirc
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:
> I don't think a dual-PS, if such a thing exists, would be any different
> from a splitter attached to a single PS. The important thing is that
> the PS should be regulated. An unregulated supply can measure higher
> than the rated voltage under no load, but can drop below the
bluetdi wrote:
> Thank you @paul-
>
> I will look for a dual-PS with enough power for the screen and the Pi
> and feed them separately.
I don't think a dual-PS, if such a thing exists, would be any different
from a splitter attached to a single PS. The important thing is that
the PS should
Thank you @paul-
I will look for a dual-PS with enough power for the screen and the Pi
and feed them separately.
3xPi3B-7"+pCP 6.0 | LMS 8.0.1 | Transporter | 2xTouch | 2xClassic |
2xBoom | 2xRadio | iPeng
[Discarded: 2xOdroid U3+m2p+LMS]
NoobNR7 wrote:
> Hi Ralphy,
>
> Hoping you can help me out? I am struggling to get IR working on my old
> raspberry with pcp.
>
> Trying to install/ use flirc ir usb receiver with a remote lying around
> in the house.
> (wich is preferred ir remote (easiest/ future proof) method in
>
I do not believe there is a way to turn it off. That is handled in the
firmware, which is not open source.
Common problems are with too cheap of a cable/connector on the power
supply, or something connected the the USB port that is pulling the RPI
internal voltage too low. If you are using
carsten_h wrote:
> You see the difference? It really is undervoltage, not undercurrent!
> When the *voltage* is too low the lightning appears. I have a few power
> supplies that deliver 3A, but the voltage is at 4,9V when the Pi is
> drawing 1A and that is too low for the Pi.
Not really helpful
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
Hello..
On my rpi4 (2gb) no mater what I do .fresh pcp 7.0 64 bit installs
and/or anywhere along the process of installing lms, resizing
partitions, etc I cannot successfully execute the WAP install , always
get a downloading package error?..anybody have any ideas, thx in
advance.
2nd
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
NoobNR7 wrote:
>
> I had the remote working :D for a little while on pcp. But when I
> rebooted I had to take all steps again.
>
'pcp bu' (https://docs.picoreplayer.org/information/pcp_cli/) ?
jeroen2's Profile:
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
ralphy wrote:
> .
Hi Ralphy,
Hoping you can help me out? I am struggling to get IR working on my old
raspberry with pcp.
Trying to install/ use flirc ir usb receiver with a remote lying around
in the house.
(wich is preferred ir remote (easiest/ future proof) method in
2021?(Jivelite or
bluetdi wrote:
> 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
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
bluetdi wrote:
> that shows *undervoltage*?
>
> The power supply delivers *3A*
You see the difference? It really is undervoltage, not undercurrent!
When the *voltage* is too low the lightning appears. I have a few power
supplies that deliver 3A, but the voltage is at 4,9V when the Pi is
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
38 matches
Mail list logo
