piCorePlayer, bt stutters when players synchronized

[paul-]

Good news, keep an eye on it, let me know if things change.

[gian]

Thanks, Paul,
I rebuilt the SD from scratch, with v8.2.
Now the situation looks better.

[paul-]

Sounds like you have a many times upgraded system that somehow broke, or too much tweaking in the wrong spots

Check your mirror selection bottom right of most of the pages

[gian]

thanks Paul, but...

[ INFO ] Updating pCP Bluetooth Extensions...
Invalid mirror selection for pcp-update
[ ERROR ] Try again later

[paul-]

I missed this on he first scan of the log, but your not using the latest version. Can you update the Bluetooth extensions.

[gian]

Voila...

[paul-]

The daemon is mostly dbus callbacks, so the only way for it to generate CPU usage is for bluetooth to generate events...... and the events are logged. There is nothing abnormal in your log.

Please take a screenshot with htop running showing what each process is using.

[gian]

here it is...

[bpa]

ooops! no! I was looking at the wrong Raspi...
Too many of these darn elves running around!

So, CPU n.3 is running at 100%:
- Command python3
- /usr/local/bin/pcp-btspeaker-daemon.py debug

pcp-btspeaker-daemon.py uses threads so I'm guessing one thread is having a problem.

Since you have enabled bt daemon logging, can you attach a zipped copy of the file /var/log/pcp_bt.log

[gian]

ooops! no! I was looking at the wrong Raspi...
Too many of these darn elves running around!

So, CPU n.3 is running at 100%:
- Command python3
- /usr/local/bin/pcp-btspeaker-daemon.py debug

[gian]

the problem is (or should I say luckily?) that at the moment the two speakers have been on two hrs, and there is no show of significant CPU load...

[bpa]

Sorry, maybe I had not understood the question.
No, LMS is running on another host, this a player dedicated to the two BT speakers.
I wasn't able to run reliably all the functions I needed in a single player: AP, DAC, two BT speakers, one USB relais to switch on the main HIFI system: so I split in two.
Both Raspi connected on eth0.

OK, so the process with the high processing has nothing to do with LMS or LMS provision of audio stream.

I think it would still be interesting to know which process is loading a CPU core - if it is BT related process then BT signal quality may be the issue.

With htop the CPU which a process is using can be shown using Setup / Columns and adding "PROCESSOR". The loading of each CPU can be shown using Setup / Meters and adding one of the "CPUs" options . To avoid showing child processes and just totals - turn off "tree view" in Setup / Display options.

[gian]

Sorry, maybe I had not understood the question.
No, LMS is running on another host, this a player dedicated to the two BT speakers.
I wasn't able to run reliably all the functions I needed in a single player: AP, DAC, two BT speakers, one USB relais to switch on the main HIFI system: so I split in two.
Both Raspi connected on eth0.

[bpa]

Yes, the source is Logitech Media Server Version: 8.3.0 - 1667251155 @ Fri 04 Nov 2022 09:14:25 AM CET

The two bt speakers wake me up with BBC Radio3 every morning, and are synchronized so I can follow "Bach before 7" from bed to shower.

LMS is up to date so no chance of old bug and anyway BBC streams (DASH) didn't trigger it.

It's not clear which system is running LMS. Is LMS running on the PCP system that you showed

CPU2: 24.3% usr 75.6% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 0.0% sirq

[gian]

I loaded htop and tuned the BBC, the speakers have been singing for 1h and no sign of overload... everything (exception htop) <1%...