Have been running v6.1.0 stable for a very long time. (and many other
stable versions before that also)
Did a in-situ upgrade to v7.0.0 and the later patch. Everything looked
fine.
However now it is somewhat unstable.
3 times the last week it has totally "frozen". Not able to reach the
rpi3+
apologies I've been looking for a new job and this has consumed much of
time these last months
in no particular order
@Aki7 - power-off/sleep mode of the player does not trigger any
additional functionality. I'll look at adding a configurable sleep mode
that will sleep in lockstep with the
pCP and piCore does not use apt packaging. It never has.
There is an extension page in the pCP web interface that allows you to
download and install packages. I have not had a chance to package
triggerhappy yet. I can get it this evening. What else might you
need?
piCorePlayer a small
paul- wrote:
> Names are fairly close to the application names. i.e. when I upload
> triggerhappy, the extension name will be triggerhappy.tcz
>
A little disappointed because I'm kind of lost already (although I know
I managed to solve this once before) because "apt-get" is not included
in
paul- wrote:
>
> So I would run a trim even (in the background) shortly after booting
> your device. Then on a weekly cron job.
Thanks Paul - that's how I've set it up, and yes, if I run the command a
second time, it returns 0 bytes.
But wait - I don't recommend updating to the firmware
That first large unmap will happen only the first run after boot. After
that it will only be the bytes that have changed since the last unmap.
So I would run a trim even (in the background) shortly after booting
your device. Then on a weekly cron job.
piCorePlayer a small player for the
Success! With the 'unmap' provisioning mode made persistent by
following Paul's guidance for editing bootlocal.sh, I can now issue the
fstrim command after a reboot.
Code:
tc@pCPServer:~$ sudo fstrim -v /mnt/Music
/mnt/Music: 45572067328 bytes trimmed
paul- wrote:
> If you read the threads, the Asmedia adapters are going to be dependent
> on the firmware loaded on the adapter.
>
This seems to be the key. I downloaded the 141126_A1_EE_82 firmware
(from 'here'
I've just seen the announcement that 8.1 has been release, so took the
opportunity to check on the state of affairs with the Docker container.
I see there are now quite a lot of different tags on there.
Can I suggest some 'named' tags that are updated to make it easier for
people to keep track
They changed the names in the 5.4 kernels. The old way of having 2
devices with the same name, switching between them was really "hacky".
piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please 'donate'
If you read the threads, the Asmedia adapters are going to be dependent
on the firmware loaded on the adapter.
It doesn't surprise me that the M.2 drive is faster though...
piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please 'donate'
rbl wrote:
> Works perfectly, thank you! Out of intertest, any idea why it was
> changed?
Some time ago the rpi foundation split the AV Jack and HDMI alsa
controls
With the latest software, there was a change to Pulse Audio being the
default for audio (it sits on top of ALSA)
I think that is
Man in a van wrote:
> Try
>
> plughw:CARD=Headphones,DEV=0 - bcm2835 Headphones, bcm2835 Headphones
> - Hardware device with all software conversions
>
> and reboot
Works perfectly, thank you! Out of intertest, any idea why it was
changed?
SB3 -> Quad 909 -> Quad Electrostatic speakers,
Try
plughw:CARD=Headphones,DEV=0 - bcm2835 Headphones, bcm2835 Headphones
- Hardware device with all software conversions
and reboot
Man in a van's Profile: http://forums.slimdevices.com/member.php?userid=43627
View
bpa wrote:
> DEV=1 or 2 often means a digital output such as SPDIF or HDMI and so
> nothing will happen on analog.
>
> "hw:" means only the hardware supported samplerate/sampleformats will be
> sent - so LMS will have to resample/trasncode as required.
>
> "plughw" means ALSA will support all
chill wrote:
>
> Maybe this explains why it is 50% faster than the previous SATA SSD
It doesn't. Both drives show up as identical devices with identical IDs
(is that possible?), and both are using the uas driver.
Code:
tc@pCPServer:/usr/local/bin$ ./lsusb
Bus 002
Thanks again Paul. So it appears that the M.2 drive is using UAS after
all:
Code:
tc@pCPServer:/usr/local/bin$ ./lsusb
BUS 002 DEVICE 003: ID 174C:55AA ASMEDIA TECHNOLOGY INC. ASM1051E SATA 6GB/S
BRIDGE, ASM1053E SATA 6GB/S BRIDGE, ASM1153 SATA 3GB/S BRIDGE,
17 matches
Mail list logo
