Title: Bluetooth hijacks Tidal Connect / Spotify Connect on pause

Bluetooth hijacks Tidal Connect / Spotify Connect on pause

The problem

When I pause playback from the Volumio UI while Tidal Connect or Spotify Connect is active, Bluetooth hijacks the volatile state. Status flips to play/bluetooth with empty metadata ~5 seconds after pausing — playback is effectively dead.

Pausing from the phone app (Tidal/Spotify app) works fine because it bypasses the Volumio state machine.

Disabling Bluetooth fixes it completely.

How to reproduce

  1. Have Bluetooth enabled (default)

  2. Start playback via Tidal Connect or Spotify Connect

  3. Pause from the Volumio web UI

  4. Wait ~5 seconds

  5. Status shows play/bluetooth — nothing actually plays

Environment

  • Volumio 4.103, Raspberry Pi 5

  • Tidal Connect (vtcs) active

  • Bluetooth enabled (default)

Full analysis + journal logs

I’ve filed a detailed bug report with timestamps, root cause analysis, and the exact journal log sequence on GitHub:

Bluetooth service hijacks volatile playback on pause (Tidal Connect / Spotify Connect) · Issue #276 · volumio/volumio3-backend · GitHub

Anyone else seeing this?

please update to the latest stable version

I’m on the latest

this is not the latest

Screenshot 2026-04-08 at 20.29.20

I am on the latest
Tested on RPI5 and RPI4… Tidal and Spotify

please provide a full log link after the issue has been reproduced

Just did

21:20:55  volumioPause → servicePause → vtcs pauses OK
          [pause:147] Entering → [pause:161] Exiting  ✓

21:20:55  volumioVolatilePlay  ← BLUETOOTH HIJACK
          BT MESSAGE: [FUNC] play
          BT MESSAGE: sendPlay skipped: activePlayer not bound or invalid  ✗

we need the log link to be copied/pasted here

the livelog is not enough, a full system log is required

You need to post the URL link to the log file, not the content of it

https://paste.rs/84Nya

Hey @borquee,

Let me make the requirements unambiguous so this thread can move forward or be closed.

  1. Version

Volumio 4.103 is not the current stable release. Anything reported against a superseded version is not actionable. Update to the current stable, reproduce the behaviour there, and state the exact version number as shown in Settings > System. “Latest” is not a version number.

  1. Log link

A paste.rs URL is not a Volumio log. A copy/paste of the live log view is not a full system log. Hand-annotated excerpts are not a substitute for the raw log either.

What is required, and the only thing that is required:

  • Reproduce the issue on the current stable version.
  • Open http://volumio.local/dev in a browser.
  • Use the log submission function on that page.
  • Copy the URL it returns.
  • Paste that URL here as plain text.
  1. Ground rules

Without a proper log link generated from http://volumio.local/dev, on the current stable version, after reproducing the issue, there is nothing to investigate. No log, no help. This is not negotiable and will not be restated.

Volumio runs on a very large number of installations without the behaviour you describe. The burden is on your environment to produce the evidence. The GitHub issue you filed is premature on the same grounds: no confirmed current version, no verified full log, no reproducible chain. Root cause claims made from a partial live log view do not meet the bar.

  1. Also include with the log link
  • Exact Pi model and revision code
  • Storage type (SD card, SSD, USB, NVMe)
  • Power supply
  • Whether the issue reproduces on a fresh flash of the current stable with no additional plugins installed

Kind Regards,

  1. 4.119 … and every version since I started using couple of months ago

  2. What is a log link? I used /dev " Send Log or bug report" to send, I was told to copy/paste system log, I sent you a https://paste.rs/84Nya

  3. sent you a log over /dev

  4. PI4 on SDCard and PI5 (with and without NVme)

5A official RPI PSU, 5A Meanwell, 16A variable voltage, current limiting PSU

Reproduced on a fresh install (what I sent), on a one month old install

And I made you a video of me reproducing it on Tidal IMG_8327.mp4
And reproducing it on Spotify IMG_8328.mp4

and again system log (please use the link above becauase I can post two links per post… paste.rs above)
and timeframes with problem

  • Line 2297 (00:37:16) — volumioPause — user pauses
  • Line 2298-2309 (00:37:16) — pause executes correctly, vtcs stops
  • Line 2314 (00:37:24) — volumioVolatilePlay — BT hijack
  • Line 2315 (00:37:24) — BT MESSAGE: [FUNC] play
  • Line 2316 (00:37:24) — sendPlay skipped: activePlayer not bound or invalid

Forgot to mention: one clip is RPI4 on sdcard, other is RPI5 on nvme

Hey @borquee,

  1. image
  2. image
  3. image
  4. CTRL+V
  5. image

NO LOGS = NO HELP

Kind Regards,

http://logs.volumio.org/volumio/ULtZtd7.html

Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::volumioPause
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreStateMachine::pause
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreStateMachine::stPlaybackTimer
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreStateMachine::servicePause
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::servicePause
Apr 09 12:34:06 volumiohelp volumio[1196]: info: Received pause
Apr 09 12:34:06 volumiohelp vtcs[2064]: [pause:147] Entering
Apr 09 12:34:06 volumiohelp vtcs[2064]: [feedThread:276] Exiting
Apr 09 12:34:06 volumiohelp vtcs[2064]: [pause:161] Exiting
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::servicePushState
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreStateMachine::pushState
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , saveDeviceInfo
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::volumioPushState
Apr 09 12:34:06 volumiohelp volumio[1196]: info: MRS: Pushing multiroomSync output update for this device
Apr 09 12:34:06 volumiohelp volumio[1196]: info: MRS: Pushing multiroomSync output
Apr 09 12:34:06 volumiohelp volumio[1196]: info: CoreCommandRouter::volumioGetState
Apr 09 12:34:06 volumiohelp volumio[1196]: SPOTIFY: RECEIVED VOLUMIO VOLUME 86
Apr 09 12:34:09 volumiohelp volumio[1196]: info: CoreCommandRouter::volumioVolatilePlay
Apr 09 12:34:09 volumiohelp volumio[1196]: ------------------------------------ BT MESSAGE: [FUNC] play
Apr 09 12:34:09 volumiohelp volumio[1196]: ------------------------------------ BT MESSAGE: sendPlay skipped: activePlayer not bound or invalid

don’t be snarky… it’s your bug, not mine

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.

  1. “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.

  1. 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.

  1. 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.

  1. 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.

  1. 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,

1 Like

Can you clarify please for me: 4.136 should have this bug fixed?

I am here very fresh and comments line “Step, by step commic book for borquee” is snarky and not called for

I am trying to help.

Sincerely,
B