Hey @borquee,
Complete log received, version now confirmed as 4.119 on Raspberry Pi 4 Model B Rev 1.5, SD card, headphone jack out, wlan0 only, Spotify community plugin installed, Bluetooth and the Tidal/Qobuz connect daemons all active from the proprietary stack. System interdependence, plugins states, configurations including i2c states - all accounted for and initially missed.
Before anything else, two things to straighten out.
- “It’s your bug, not mine”
Wrong framing. I do not own, write, ship, or get paid for Volumio. I am a community volunteer as many other who stepped in this thread and asked you for the exact same thing - log. The help here is voluntary. Attitude like that is a good way to ensure the next person who sees a post from you scrolls past it.
- What the log actually shows
At 12:34:06 volumioPause and servicePause execute cleanly and vtcs acknowledges pause:147 Entering and pause:161 Exiting. Three seconds later, at 12:34:09, a volumioVolatilePlay arrives originating from the bluetooth subsystem, accompanied by the bluetooth plugin’s own log line “sendPlay skipped: activePlayer not bound or invalid”. That is the plugin pushing a volatile play transition while simultaneously reporting it has no active player bound. Self-inconsistent state on the bluetooth path. Consistent with your symptom.
None of this is news.
- Status of the behaviour
This behaviour is known. It has been addressed in the bluetooth plugin. The fix is merged. It lands in builds 4.136 and later, which are currently on the alpha update channel.
If you want to verify the fix on your hardware:
- Open http://volumio.local/dev in a browser
- Under “Update Channel Selection” switch to Alpha
- Check for updates, install, reboot
- Reproduce your pause test
Help page for the test channel: How to switch Update Channel (Stable/Test)
If the behaviour persists on 4.136 or later, come back with a fresh log link from that build.
- The GitHub issue
volumio3-backend issue #276 was filed at 4.103, with a hand-annotated partial log, claiming root cause, against a repository that does not contain the bluetooth plugin code path emitting the problematic state. That is three separate filing errors in one issue. It would help if you amended or closed it and, if a report is still warranted after testing on 4.136 or later, file a properly scoped one against the correct component with a full log link attached.
- Reality check
You were on a superseded version. You spent four posts fighting a log link request that should have taken you thirty seconds. You filed a premature GitHub issue claiming root cause. You called a volunteer’s code “your bug”. And the fix you are demanding has been available on the alpha channel the entire time. Consider that before the next combative reply.
Kind Regards,