Thanks both! I look forward to trying these out. That won't be until
this evening unfortunately, so perhaps I should look forward instead to
Michael showing us whether they work under iSH. :)
EDIT: Had a quick try with Squeezelite. There don't seem to be any
sound output devices under iSH. :(
mherger wrote:
>
> I have a latest generation iPhone.
I'd be keen to try it out too. I've installed iSH on an iPad - must
admit, I didn't look into whether it's available for an iPhone, so
haven't tried it.
chill's Pro
ralphy wrote:
> I have an alpine i686 build system that I'm using to repurpose my O2
> joggler.
> So far, I only have squeezeplay and squeezelite apks but I should be
> able to build the lms packages.
>
That would interesting - do you have any iDevices to try those builds
under iSH? Squeezepl
mherger wrote:
> iSH is using i686.
Am I right that an i686 build would therefore allow, for instance, LMS
to run on an iPad, and Squeezelite to run on an iPhone? That would be
interesting.
chill's Profile: http://forums
mnd wrote:
>
> If you don't mind me asking again - maybe you have an applet for
> jivelite of the superdatetime plugin?
>
> I think I remember entering it's settings/info through "Extras" menu
> entry, but now the entry for superdatetime is gone and I don't see it in
> the Applet Installer. I
mnd wrote:
> Hi, I followed your progress from the first pages of this thread, and
> managed to install jivelite on Ubuntu bionic 5.4 from 'here'
> (https://birdslikewires.net/debian-for-openframe).
> I understand there was quite some progress from that point (after the
> post I quoted), but if
You can put your own copy of jivelite.sh in /mnt/mmcblk0p2/tce/. If
present, pCP will use this version instead of the system jivelite.sh.
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this th
mftech wrote:
>
> I end up creating a folder home/tc by removing the sd card and edit it
> on my PC and save the file as .sh.
>
As Paul suggests, this has created the file in the wrong location. With
the SD card inserted into your PC you will not be able to see the
default /home folder. Bec
mftech wrote:
> even if Jivelite is not configured properly should I see verbose on
> the display ?
>
I'm afraid I don't remember for certain. I think the framebuffer needs
to be configured correctly for the console messages to appear.
Have you checked that you've changed the Framebuffer
mftech wrote:
>
> I've read the thread but it's unclear to me if the code from Chill hans
> been check-in in Picoreplayer 8.0.
>
I've done a couple of fresh installs under pCP8.0.0 (one on a Pi Zero W
and one on a Pi Zero 2 W), and can confirm that following al
carsten_h wrote:
> The part with the buttons is not really what I like. :-)
>
I agree - the button locations do create a problem for case designers.
I see that there are several case designs at the above Thingiverse link
that simply leave the full face of the Pirate Audio board exposed - they
paul- wrote:
> Press the "Set Write Permissions" button in the web interface.
>
Thanks Paul - I wish I'd seen that before I dug out an old Windows
machine and eventually figured out the same solution. I guess the
fdisk/mkfs.ext4 process has created a file system that belongs to root,
so user
paul- wrote:
>
> In my office when I can get time on it.
> https://www.raise3d.com/e2/
Nice. Mine's a lot of trouble to keep working properly, and even when
fettled to the best of my ability it's still quite unreliable. Looking
at recent adverts they seem to have come on a long way in recent
I guess the samba share might have worked more like you're used to if
the drive had been formatted as NTFS, rather than EXT4. I suppose
that's still an option, but EXT4 works better with Linux, and I think it
should be fine once this permissions issue is resolved.
Another option, although unlik
kidstypike wrote:
>
> However it seems to contain a folder named "lost-found" that I cannot
> delete.
>
> I also cannot create new folders to add my music files.
>
Hmm - evidently something to do with permissions on the samba share.
But I'm out of my depth here - hopefully someone more know
I'm afraid I don't know enough about Windows these days to know where
that S: drive came from. I believe you will need to explicitly 'share'
your new EXT4 drive from your pCP machine in order to see it from a
Windows machine. Take a look in the LMS -> 'Setup Samba Share' section
on the pCP page
kidstypike wrote:
> Thanks all, getting there.:D
>
> However the partition seems to be only 3.37GB, how do I expand that?
>
> 36088
>
> 36089
Your first image shows that it's an EXT4 disk with 223 GB. Your second
image appears to be of a different disk, since it's identified as NTFS,
rather
paul- wrote:
> >
Code:
> >
> sudo mkfs.ext4 /dev/sda1
>
> >
Ah good - I couldn't remember whether 'sudo' was required.
chill's Profile: http://forums.slimdevices.com/
The format command wasn't complete, so the disk isn't yet formatted.
The full command is:
Code:
mkfs.ext4 /dev/sda1
>From memory I think this command might take a little bit longer to
complete.
---
kidstypike wrote:
> Done this, has it been created?
>
> What next?
>
If that's all worked as intended, you should now see a /dev/sda1 if you
issue the 'fdisk -l' command again.
If so, then it's on to the formatting command, mkfs.ext4.
---
Well I'm on slightly dodgy ground now, but from memory I think you need
to do
o create a new empty DOS partition table
n add a new partition (it'll ask some more questions - not sure
exactly the order or the options, but make it a primary partition that
fills the whole disk)
then
w
Aaargh - I'm an eejit. It's fdisk, not fdisc. Sorry!
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread: http://forums.slimdevices.com/showthread.php?t=114828
___
kidstypike wrote:
> Chill, thanks.
>
> Can't even get started . . .
>
> >
Code:
> > tc@musicbox:~$ fdisc -1-sh: fdisc: not found
> tc@musicbox:~$
> >
That first command should be just
C
My memory of what I did under pCP to format an SSD in the Argon case
isn't great, but I can give some clues.
>From your dmesg it looks like the SSD is device sda. If you SSH into
the RPi and type
Code:
fdisk -l
you should see some output like th
carsten_h wrote:
> Is there anywhere a good looking case available (to buy) for the Pi Zero
> and a Pirate Audio Hat with display?
I've struggled with this myself. I'm surprised Pimoroni/Pirate Audio
themselves don't make a case that fits nicely around a Zero and a Pirate
Audio board. The bes
Just in case we're overlooking something obvious - have you used the
little USB link piece to connect the disk tray to the RPi once
assembled?
I have a couple of these Argon cases, both running pCP (one's my server,
the other runs a player and does some housekeeping jobs overnight). My
memory i
I have a PI0W and a PI02W, both set up identically with a fresh pCP8.0.0
(64-bit on the PI02W) and with Pirate Audio sound cards/displays. I did
a quick speed test. From applying power to the start of audio playback
the original PI0W takes 49 seconds, and the new PI02W takes 28 seconds.
That's
lozcspi wrote:
> I've used the 64bit image (is this right?)
That's what I started with.
lozcspi wrote:
> Accessing on a windows PC and can only see a folder called overlays
> (drive is called PCP_BOOT)
>
> Do I create a boot folder?
I hesitate to imply that these are the definitive steps ne
The Pirate Audio setup seems to work exactly as it did for the Zero 1.
'[image:
http://www.cjh.me.uk/MyPhotobucket/cache/DIYHifi/Jivelite/240x240/PI02_640.jpg]'
(http://www.cjh.me.uk/MyPhotobucket/albums/DIYHifi/Jivelite/240x240/PI02.jpg)
---
Man in a van wrote:
> Is "boot" partition a typo ?
>
> i could only find the file in "Root" :confused:
>
> ronnie
It is! Sorry - meant root: PCP_ROOT/tce/optional/firmware-rpi-wifi.tcz
Will correct my post.
chill's P
My Zero 2 arrived yesterday while I was away, but following the steps in
this thread mine now seems to be up and running - thanks Paul and
Ronnie.
1) Added bcm2710-rpi-zero-2.dtb to the boot partition
2) Added a PI02 section to config.txt
3) Replaced the firmware-rpi-wifi package in the boot par
dkskl wrote:
> and a RPI4b/pCP8 streaming client (LMS not installed).
> A RPI3b client is also on the network.
>
Are these two clients synced? If so, try unsyncing and perhaps (soft)
powering off one of the clients. If they're not synced, do you get the
dropouts on both clients?
I had
Jivelite can certainly be set up to blank the screen when the player it
is controlling is powered off. The setting to do this is in 'Settings'
-> 'Screen' -> 'Screensavers' -> 'When off'. If you set this to 'Blank
Screen', then whenever/however the player that Jivelite is controlling
is powered
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: http://forums.slimd
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
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
v1.9.
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
>
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 surprise,
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: http://forums
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 script
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
>
==
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
>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 ve
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: http://forums.slimdevices.com/member.php?userid=10
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 ar
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 th
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 rigo
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, s
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
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: http://forums.slimdevices.com/
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 /u
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), o
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 contributor!
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 be
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 wro
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'
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
th
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 issue
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
p
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 th
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-daem
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, but
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 avai
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 b
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 repor
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 resolv
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 doe
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 wha
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: http://forums.slimdevices.com/showthr
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
'{pr
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: http://forums.slimdevices.com
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 faili
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.
-
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 interes
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 exp
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:
C
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}' |
xargs
Greg Erskine wrote:
> Maybejust maybe
>
> Way back somewhere I mentioned using the "force" option instead of the
> "stop" option during testing.
>
Thanks Greg. I had noticed the 'force' option, but hadn't looked beyond
the comment: "# Force should only be used for testing purposes."
That confirms that the start-stop-daemon isn't stopping the process.
The fact that the process hasn't stopped may or may not be enough to
prevent the subsequent start, but since the same start-stop-daemon is
used to start the process, it may well be failing to do that too.
I'm not sure yet what
Bogg wrote:
> As requested this is with dac still off -
>
> >
Code:
> >
> tc@pCP:~$ ps | grep squeezelite
> 6330 root 0:01 /usr/local/bin/squeezelite -n piCorePlayer -o
hw:CARD=M6,DEV=0 -a 80 4 1 -v
> 10355 tc0:00 grep squeezelite
> tc@pCP:~$
@Bogg - perhaps you could run another quick test.
Boot up as normal with the DAC attached and powered, then turn the DAC
off. Then:
Code:
ps | grep squeezelite
cat /var/run/squeezelite.pid
And could you also post the log file from this sequence
Thanks both Pauls - just working my way through the init.d script now.
WWWROOT is not used. And what I can't fathom is if there's a problem
with the environment in Bogg's fresh pCP7 install, why isn't there a
problem with the environment in my fresh pCP7 install?
Bogg wrote:
> Here's my adjus
and just to check, can you post the contents of your
/etc/udev/rules.d/10-M6.rules file.
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread: http://forums.slimdevices.com/showthread
Bogg wrote:
> Twice more, and I made sure I wasn't using --nostop as it had the same
> behaviour
>
> I just did the install and reboot a third time, just to be sure, and
> everything is as I describe above, including not being able to restart
> sqlite from the webpage.
You're right - it does a
Tsk - that's just muddied the waters even more!
I take it you've done a reboot since making the latest script changes?
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread: http://forums
Bogg wrote:
> Hi again. And thanks again. On with the show.
>
> Here are my steps for clarity -
> Dac on - run install without --nostop - pcp br - dac off (sqlite auto
> killed, not showing in material, but showing on pcp web)
>
> >
Code:
> > tc@pCP:~$ ps | grep sque
Paul Webster wrote:
> I haven't read through this all so apologies if this does not help ...
>
> I assume that when run via udev it is not necessarily being run as the
> same user and with the same environment as when run interactively.
> So - is there anything in the called startup script that
Bogg wrote:
> Sorry, in my excitement for progress I wasn't too clear.
> Unfortunatly it only restarts once, and the restart command needs to be
> run each time.
>
> Here's the new sudo output and log when it has worked
> Dac on (working) - dac off - dac on (not working) - run restart
>
> >
C
Bogg wrote:
>
> This makes things work again ! .
> I follow your three steps from post 199, and the dac reconnects !
> Here's the output
>
> >
Code:
> >
> tc@pCP:~$ /home/tc/SQLITE-control.sh restart M6 1-1.2
> /home/tc/SQLITE-control.sh: line 87: can't create /
Bogg wrote:
> When I run the script with --nostop I get quite different results.
>
> When I stop the dac the sqlite stays listed on material / apps
> the pcp web says not running
This bit is rather strange. The --nostop option makes a rules file that
does not have a rule for when the DAC is r
Bogg wrote:
>
> I'm sorry, I don't understand where to or what to actually add for
In the file /home/tc/SQLITE-control.sh, make the two changes highlighted
in bold below. I'm clutching at straws I'm afraid - I don't believe
this is the cause of the problem, but it's a loophole that should be
Bogg wrote:
> When I boot with dac off sqlite does not start.
> When I then turn on the dac sqlite still does not start.
> When I then restart sqlite from command line sqlite starts.
I can't understand this behaviour at all. There's nothing in the
'restart' part of the script that relies on pr
Bogg wrote:
> Hi,
> Starting from a playing sqlite.
>
> I turn off dac,
> >
Code:
> >
> tc@pCP:~$ ps | grep squeezelite
> 12419 root 0:02 /usr/local/bin/squeezelite -n piCorePlayer -o
front:CARD=M6,DEV=0 -a -v
> 15212 tc0:00 grep squeezelite
Bogg wrote:
> Hi, I installed the script from post 183. it seems to have installed ok,
> it finds my M6 dac and shuts squeezelite down as expected.
> Unfortunately it doesn't restart squeezelite when I turn on the dac.
>
I'm not sure. A few things you can try, to help understand what's going
Thanks Paul - that's very helpful.
paul- wrote:
>
> Do you really need them in the initrd?
>
I assumed they were needed at boot, but that's because I'm a bit out of
my depth here! I didn't think of using a separate extension - would
those files be available at the right time?
Thanks for t
I've bought a 3.5" capacitive touchscreen ('this one'
(https://www.amazon.co.uk/gp/product/B07Q8171LB)). I was attracted to
this particular screen because it was relatively cheap (I paid £27,
although it now seems to be unavailable), and it has a built-in RTC,
which may prove useful for a planned
1 - 100 of 746 matches
Mail list logo
