It sounds to me that your Bluetooth speaker is doing something funky which is causing the Bluetooth adapter module to hang/crash or causing bluez-alsa to hang which in turn causes mpd to hang which stops the web interface from responding because it/nginx can't get status updates from mpd.
As you state that a constant audio stream like radio is OK it is most likely that the speaker is not handling the break between streams of individual tracks well and the potential changes in sample rate between streams which is locking up the sending process. Maybe increasing the audio buffer in the mpd config screen might help, to something like 20MB (20480 KB), maybe not.
The range isn't great with the Pi's Bluetooth adapter so that might be a contributing factor but ultimately this sounds like the root cause is a hardware problem not software, primarily the thing you're streaming to.
Maybe you can get a better idea by inspecting the kernel logs as it happens, e.g. replicate the issue whilst running;
...or run 'dmesg' after the event.
If you get nothing there then the Pi's Bluetooth adapter is probably fine and you'd go on to do the same with the system journal. You could also make bluetoothd output log debug messages by editing the systemd unit file, e.g;
... and change
... to...
... and restart bluetoothd or reboot.
Then replicate the issue whilst running..
.. or give up on this Bluetooth speaker you're using for something better.
As you state that a constant audio stream like radio is OK it is most likely that the speaker is not handling the break between streams of individual tracks well and the potential changes in sample rate between streams which is locking up the sending process. Maybe increasing the audio buffer in the mpd config screen might help, to something like 20MB (20480 KB), maybe not.
The range isn't great with the Pi's Bluetooth adapter so that might be a contributing factor but ultimately this sounds like the root cause is a hardware problem not software, primarily the thing you're streaming to.
Maybe you can get a better idea by inspecting the kernel logs as it happens, e.g. replicate the issue whilst running;
Code:
sudo journalctl -kef...or run 'dmesg' after the event.
If you get nothing there then the Pi's Bluetooth adapter is probably fine and you'd go on to do the same with the system journal. You could also make bluetoothd output log debug messages by editing the systemd unit file, e.g;
Code:
sudo nano /lib/systemd/system/bluetoothd.serviceCode:
ExecStart=/usr/sbin/bluetoothd --noplugin=sapCode:
ExecStart=/usr/sbin/bluetoothd -d --noplugin=sapThen replicate the issue whilst running..
Code:
sudo journalctl -ef.. or give up on this Bluetooth speaker you're using for something better.
