nicokaiser / rpi-audio-receiver

Raspberry Pi Audio Receiver with Bluetooth A2DP, AirPlay 2, and Spotify Connect
MIT License
1.36k stars 150 forks source link

bluetooth-udev doesn't seem to execute at all #132

Closed Panaphobe closed 2 years ago

Panaphobe commented 2 years ago

Running rpi-audio-receiver on a Pi Zero 2 for a headless application and thought I would test to see if its bluetooth chip is acceptable on its own or whether I'd need a dongle.

I uncommented both ifconfig lines in bluetooth-udev, but the wifi doesn't toggle when I connect/disconnect a bluetooth device. To troubleshoot this I tried adding the device-added and device-removed aplay commands to their respective if sections. The sounds don't work either, so it seems as if the bluetooth-udev isn't running at all for some reason.

I also tried uncommenting the first line of the file, which had no effect so I re-commented it. Finally I tried manually running the ifconfig lines on their own in a terminal, and got an error: "SIOCSIFFLAGS: Operation not permitted". The ifconfig lines run fine in a terminal if preceded by sudo, and adding sudo to the appropriate lines inside bluetooth-udev has no effect.

It seems like maybe bluetooth-udev might be failing to do anything because it is not running with appropriate permissions? Thanks for any help.

Full content of my bluetooth-udev (hopefully without errors, it's manually typed out here as I don't have an easy way to transfer the file to the PC I'm making this issue report from):

!/bin/bash

if [[ ! $NAME =~ ^/"([0-9A-F]{2}[:-]){5}(0-9A-F{2})\"$ ]]; then exit 0; fi

action=$(expr "$ACTION" : "([a-zA-Z]+).*")

if [ "$action" = "add" ]; then bluetoothctl discoverable off

disconnect wifi to prevent dropouts

ifconfig wlan0 down &
aplay -q /usr/local/share/sounds/__custom/device-added.wav

fi

if [ "$action" = "remove" ]; then

reenable wifi

ifconfig wlan0 up &
bluetoothctl discoverable on
aplay -q /usr/local/share/sounds/__custom/device-removed.wav

fi

sebastian-de commented 2 years ago

I also noticed that commands in /usr/local/bin/bluetooth-udev didn't execute. I want to run mpc stop in case my MPD server is currently playing something, but playback didn't stop upon connecting a bluetooth device.

For me removing/commenting the NAME condition did the trick: https://github.com/nicokaiser/rpi-audio-receiver/blob/2b7ef54b21c4764a53e90e7cf1eedf1dbe48e7a2/install-bluetooth.sh#L60

Now all commands get executed upon a bluetooth connect. I'm using the RP4 built-in bluetooth (yes, I'm aware of the downsides).

Panaphobe commented 2 years ago

Edit: It turns out everything here was caused by the onboard bluetooth chip(s). I had slightly different symptoms on the different Pis, and I couldn't get the dongle to work in all situations (in newer-than-buster builds for example, or if I had the bluetooth dongle plugged in from the start) but I managed to resolve every error mentioned below by going through a clean, lite Buster install, then disabling wifi and onboard bluetooth in /boot/config.txt, and only then plugging in a bluetooth dongle. Now everything seems to work as expected. Sorry for the tone in some of what I wrote, I am closing the issue.

Your bluetooth-udev is 60 lines long? Mine is only about a dozen lines long, and the corresponding line is the first uncommented line in the default file.

At any rate, commenting out that line on a fresh install does nothing, bluetooth-udev still does not execute at all - the pi stays bluetooth-discoverable even when a device is connected.

Honestly this is making the entire project unusable for me. I'm on a fresh install - I've done nothing except do 2 line edits to /boot/config.txt as required by my HiFiBerry (disabling the onboard hdmi output because otherwise it won't output to the amplifier), run the rpi-audio-receiver install script and installed the bluetooth audio and nothing else. It works... once per pairing. You have to forget the pairing on both the pi and the source device each and every time you connect, then re-pair them. After a reboot you get "Connection failed - No usable services on this device" until you forget and re-pair on both devices. You can't just forget on the source device, because if you do that then the next time you try to pair it will give an error about having the wrong passcode. You HAVE to forget on the pi as well, which makes this 100% broken for headless applications as of now.

Maybe this is related to the fact that I'm trying to get it to work with the onboard bluetooth, but dongles have their own problems. I've got a couple dongles that work for everything else, that I'm happy to try - but I can't get the pi to actually use them. If I just plug it in it uses the onboard bluetooth, and if I disable the onboard bluetooth with dtoverlay=disable-bt in /boot/config.txt it still doesn't use the dongle. It's strange that the readme contains multiple warnings to use a dongle instead of the onboard bluetooth, but doesn't have a single hint on how to actually accomplish this.

A few weeks ago I had a test installation working on a RPi 4, and a Zero 2 W. They weren't fully configured though, so I made a new installation to use in my actual application. I thought maybe the Zero 2 W isn't supported somehow so I tried it on a 3 B v1.2 as well, and got the exact same problems. I'm doing a simple-as-possible, no-frills installation: I start with a clean Buster Lite install and I run the installation script as instructed in the readme, when prompted I install bluetooth audio, skip airplay and spotify, and let it configure the dacplus for my HiFiBerry AMP2. At this point the system works for most devices - once. For android devices I can pair with the pi and stream audio, but if the device disconnects it cannot connect again. I can pair subsequent devices after the first stops, but each only works until it is disconnected for the first time. A Windows 10 PC seems to be the exception - it is able to connect multiple times successfully, although it briefly displays a "driver error" message when disconnecting from bluetooth. For the android devices un-pairing and re-pairing does not even fix the problem: after the first pairing, re-pairing fails and says that there is an incorrect PIN or passkey. All of this is the case on the Pi 3, and Zero 2 W.