Announce: piCorePlayer 8.0.0

[Man in a van]

Of course! Thanks so much!

Another quick question. I've been getting quite a few rebuffering and disconnects from my pi recently. Does anyone know what might be causing this? I'm using a zero2 so would have thought it would be reasonably stable and zippy. Would a regular pi4 connected via ethernet improve these dropouts?

A zero 2W would give accepatble performance. (but would still not be called zippy , but rather something else )

A zero 2 would deffo benefit from a usb-ethernet connector

I have a rpi1b running pCP / LMS on a wireless dongle (I only stream internet radio) slower than a slow thing, but I'm rather fond of it

ronnie

[huxmut]

I have a rpi1b running pCP / LMS on a wireless dongle (I only stream internet radio) slower than a slow thing, but I'm rather fond of it

ronnie

i had a pi1b running up until a couple of months ago. seems to have just plain failed in service. sdcard is fried, usb port fried, wifi dongle fried. At least the hifi berry hat lives to fight on another (hopefully) many years. i cant bear to throw it in the bin, its just apart of my setup for so long ...
anyway, it passed in glory, running pCP for many many years with barely a stutter.
i salute you my old friend

[slimhase]

Shairport vanishes after about 5 minutes

I don't use shairport-sync, but nothing would have changed in the 8.1 update that would have changed anything.

Shairport-sync is to be used standalone. When you use LMS, you need to be careful that LMS/squeezelite is not using the audio hardware or one of the software players will crash. For squeezelite, you need to make sure the -C option is enabled so squeezelite can release audio hardware when not in use.

I searched the thread and could not find anything about this issue other than the above.

(Background: I am running piCorePlayer and LMS on a Raspi Zero W as a second system.
Its slow, but reliable since years; I use it only for streaming, no local music.
Its piCorePlayer v8.2.0 with all patches)

Since recently (sorry, I can not pinpoint this better, since this system is only used a couple of month within a year), when I enable shairport, I can see it on my phone.
But after waiting about 5 minutes (not using shairport as well as not using squeezelite), it vanishes from the phone. PiCoreplayer Webpage says its still running.
But only after restarting shairport, I can see it again on my phone - again for 5 minites, before it vanishes again...
(I have an ESP32 device w/ philippe44 firmware running as well - this one stays visible on my phone continuously, therefor I think the problem is not related to anything outside my piCorePlayer setup.)
If it is visible and I connect to it, I am still not able to hear anything of the streamed music, other than sometimes some odd hiss and popping.
These are the settings I used as listed in the piCorePlaÿer Web-Interface:
/usr/local/sbin/shairport-sync -a Tivoli-Airplay -o alsa -S soxr -d -- -d hw:CARD=sndrpihifiberry
Any ideas or help to get this fixed would be appreciated

Update: when I change both squeezelite and shairport from "hw:CARD=sndrpihifiberry" to "sysdefault:CARD=sndrpihifiberry"
I can play music via shairport and the system stays active.
However, the problem remains that when I stop music, disconnect my phone from shairport and wait 5 minutes, shairport entry vanishes again from our phones....
(Also, when I leave it connected, but stop music and wait 5 minutes, the phone "thinks" it is still connected, but when I want to resume play, its disconnected from shairplay and plays on the phone)

[slimhase]

Shairport vanishes after about 5 minutes

Since recently... when I enable shairport, I can see it on my phone.
But after waiting about 5 minutes (not using shairport as well as not using squeezelite), it vanishes from the phone. PiCoreplayer Webpage says its still running.
But only after restarting shairport, I can see it again on my phone - again for 5 minites, before it vanishes again...
(I have an ESP32 device w/ philippe44 firmware (Squeezelite-ESP) running as well - this one stays visible on my phone continuously, therefor I think the problem is not related to anything outside my piCorePlayer setup.)....
Any ideas or help to get this fixed would be appreciated...

UPDATE:
This problem seems to be an interaction with Squeezelite-ESP!
When I unplug the Squeezelite-ESP device (or turn Airplay off on that device) the vanished Shairport instance of piCorePlayer shows up again on our phones!
I will raise this issue also in the Squeezelite-ESP thread.

[Paul Webster]

Do the players advertise the same name over AirPlay?

[slimhase]

Do the players advertise the same name over AirPlay?

No, they have different names.

FYI, I raised the issue here for the ESP side of it:

https://forums.slimdevices.com/showthread.php?116788-ANNOUNCE-Squeezelite-ESP32-version-2-x&p=1061645&viewfull=1#post1061645

[atrocity]

No hyphen in mountpoint name?

Is it a PCP or TinyCore limitation that forbids mountpoint names from containing a hyphen? I can work around it but figured it wouldn't hurt to ask. Thanks!

[John Stimson]

Okay, squeezelite froze again and this time I was able to load more of the squeezelite log file. The critical change appears to be:

[14:54:45.966312] process:528 strm
[14:54:45.966412] process_strm:280 strm command t
[14:54:45.966457] sendSTAT:195 STAT: STMt
[14:54:46.434711] output_thread:772 pcm wait timeout
[14:54:46.434856] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[14:54:46.434919] output_thread:762 start error: File descriptor in bad state
[14:54:46.445067] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[14:54:46.445116] output_thread:762 start error: File descriptor in bad state
[14:54:46.455293] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[14:54:46.455343] output_thread:762 start error: File descriptor in bad state
[14:54:46.465467] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[14:54:46.465515] output_thread:762 start error: File descriptor in bad state
[14:54:46.475628] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[14:54:46.475715] output_thread:762 start error: File descriptor in bad state

Repeating that last pair of messages about every hundredth of a second I guess until the log ran out of space. I'm going to roll back to 8.0.0 and see how that goes.

I have now tested with pCP 7.0.0, 8.0.0, 8.1.0, and 8.2.0, each imaged one at a time onto the same 8GB microSD card. They all ran for about a week with no failures, being powered off and then back on 1-2 times per day, except for version 8.2.0, which froze within about 18 hours of its most recent boot.
It does not seem to be related to the SD card size as I had suspected it might, since increasing the card size from 1 GB to 8 GB did not resolve the lock-ups. It's pretty clearly a problem that started with the 8.2.0 release. Any advice for what logs I should be looking at, and at what debug level?

[John Stimson]

I have now tested with pCP 7.0.0, 8.0.0, 8.1.0, and 8.2.0, each imaged one at a time onto the same 8GB microSD card. They all ran for about a week with no failures, being powered off and then back on 1-2 times per day, except for version 8.2.0, which froze within about 18 hours of its most recent boot.
It does not seem to be related to the SD card size as I had suspected it might, since increasing the card size from 1 GB to 8 GB did not resolve the lock-ups. It's pretty clearly a problem that started with the 8.2.0 release. Any advice for what logs I should be looking at, and at what debug level?

I saw a suggestion to increase the partition size for the pCP boot partition -- so I scaled it up to use the whole 8GB card, using the option in the pCP web interface main page. A lockup occurred after about 6 hours of uptime.

Error messages are as before. This shows the transition from normal playback to the non-playing state:

[17:12:10.960585] sendSTAT:195 STAT: STMt
[17:12:14.960393] process:528 strm
[17:12:14.960505] process_strm:280 strm command t
[17:12:14.960550] sendSTAT:195 STAT: STMt
[17:12:16.525348] output_thread:772 pcm wait timeout
[17:12:16.525500] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.525563] output_thread:762 start error: File descriptor in bad state
[17:12:16.535741] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.535793] output_thread:762 start error: File descriptor in bad state
[17:12:16.545920] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.546010] output_thread:762 start error: File descriptor in bad state
[17:12:16.556162] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.556210] output_thread:762 start error: File descriptor in bad state
[17:12:16.566326] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.566374] output_thread:762 start error: File descriptor in bad state
[17:12:16.576512] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.576559] output_thread:762 start error: File descriptor in bad state
[17:12:16.586676] ALSA snd_pcm_hw_start:688 SNDRV_PCM_IOCTL_START failed (-77)
[17:12:16.586723] output_thread:762 start error: File descriptor in bad state

[paul-]

Is it a PCP or TinyCore limitation that forbids mountpoint names from containing a hyphen? I can work around it but figured it wouldn't hurt to ask. Thanks!

Its pCP and the web interface handling. Just easier to deal with no odd characters. The mount name is just a name.

[philippe_44]

No, they have different names.

FYI, I raised the issue here for the ESP side of it:
https://forums.slimdevices.com/showt...=1#post1061645

Is there something specific in your network like subnets or similar? What are the IP and MAC address of each?

[wcndave]

Can't get started... I am connected to Wifi and eth0
I can see the correct IP/mask/bcast in ifconfig using a keyboard/monitor on pi
I can see the 2 connections on my network mgmt server (ubiquiti unifi)
however I cannot access the pi on either address from PC
and the pi cannot ping the gateway, nor anything else on the network.

there are no firewalls internally to the network.

Any ideas?

[slimhase]

Is there something specific in your network like subnets or similar? What are the IP and MAC address of each?

Nothing specific, just a router (providing internet wirelessthrough SIM card access to 4G network.
My internal network is managed throu that router (DHCP) with just one network, no subnets etc.
Wrt IP and MAC Adresses, I‘ll report back when I am at the system.
Thanks for the feedback!!

[slimhase]

piCore Shairport and SqueezeliteESP Airport conflict

Double-Post - cant delete...

[slimhase]

piCore Shairport and SqueezeliteESP Airport conflict

....FYI, I raised the issue here for the ESP side of it:
https://forums.slimdevices.com/showt...=1#post1061645

Is there something specific in your network like subnets or similar? What are the IP and MAC address of each?

Nothing specific, just a router (providing internet wirelessthrough SIM card access to 4G network.
My internal network is managed throu that router (DHCP) with just one network, no subnets etc.
Wrt IP and MAC Adresses, I‘ll report back when I am at the system.
Thanks for the feedback!!

So, I checked - they have both different IP an MAC addresses.
IP Addresses are: 192.168.1.102 - RaspZeroW piCore with LMS & Player1/Shairport: "Tivoli-Airplay"
192.168.1.118 - ESP-Player/Airportname: "BlaueBox"

Just to note:
If I have the raspi running and then boot up the ESP, I have both Airport-devices visible on my phones - and I can select either one and both work!
But - if I wait i.e. 2 minutes after booting the ESP, the Shairport one vanishes from the phone and only the ESP one is visible.
If I then unplug the ESP, the Shairport one is visble and funktional again.
(PiCore Website reports Shairport running all the time - also when Shairport device is not visible,on the phones)

P.S. These are the Shairport-sync settings as reported by piCore Webpage:

Shairport-sync is using these settings:

/usr/local/sbin/shairport-sync -a Tivoli-Airplay -o alsa -S soxr -d -- -d