This isn’t meant to be snarky, but please keep in mind that the people helping you here are volunteers, spending their own free time.
Multiple people have asked you. four times now with instructions, to post a full log. Instead, you keep replying with partial live logs or obscure URLs that we’re not going to open.
Please respect the time we donate by following the instructions given. Providing the requested information upfront avoids unnecessary back‑and‑forth and prevents friction for everyone involved.
No, I am very grateful for all the help, but as I told you, I’m using Volumio about a month, I don’t know how internals work, I’m willing to learn and help as much as I can … I have never seen this kind of bug reporting (it’s actually quite good).
In the last month I managed to make Volumio work with Hifiberry’s DSP… works nice and I think it would be good for the community
Run a system update, your device will upgrade to V4.136
Reboot
Perform your test and see if the issue has been resolved, as we expect it is.
If it still fails, provide a full log. This will give the developers a starting point to investigate.
I do not do socialising and I do not manage feelings. I do engineering based on details. Emotions do not fix problems; they consume time and energy that should be spent on the problem. If a response reads as blunt, that is the medium doing its job. What matters is whether the technical content is correct and useful. Judge the replies on that basis, and this thread will move forward efficiently.
The BT MESSAGE lines are a consumer, not an emitter. The plugin wraps coreStateMachine.volatilePlay at startup, so any caller of volatilePlay anywhere in the backend transitively invokes the plugin’s play handler. The handler logs [FUNC] play on entry and then hits its guard: sendPlay skipped: activePlayer not bound or invalid. That guard is correct behaviour: no BT device is bound, the plugin refuses to act. The plugin has no code path that originates a volatilePlay call.
Conclusion: the BT log lines are a red herring. Plugin is exonerated.
Event chains across 4.119 and 4.136 are not identical
+3s: volumioVolatilePlay → BT [FUNC] play → skipped
4.136:
vtcs logs Illegal state:1 and Ignore play request (state_=2, playstate_=1, player_state_=0)
vtcs performs full PCM close:85 → open:50 → start:106 cycle, feedThread re-entry, FLAC LOST_SYNC, all before the user’s pause
volumioPause → servicePause → vtcs pause:147
+3s: volumioVolatilePlay → BT [FUNC] play → skipped
The vtcs-internal error cascade in 4.136 is new and does not appear in 4.119. vtcs is in a degraded state before the pause is issued.
The constant across both builds
Approximately 3 seconds between servicePause and the spurious volumioVolatilePlay, in both builds. A consistent 3-second delay is not an event-driven reaction to the vtcs errors, which would fire sub-second. It points to a timer or polling interval in the backend re-evaluating state and issuing a volatilePlay based on stale data.
What needs to happen next
The emitter of volumioVolatilePlay has to be named with a stack trace, not guessed. The plugin already wraps volatilePlay, so adding new Error().stack logging inside that wrapper on entry will print the caller chain on the next reproduction. One capture per build will identify the emitter definitively and confirm whether the source is identical across 4.119 and 4.136, or whether the vtcs degradation in 4.136 is adding a second path.
Issue #276
Filed against the wrong component. The bluetooth plugin is not causing the volatile play. The issue should be re-scoped to the state machine or volatile source path in volumio3-backend, with the stack trace from step 4 attached, or closed and refiled cleanly once that data is in hand.
Disabling Bluetooth is not a workaround
Disabling Bluetooth suppresses the visible symptom because it removes the consumer that reacts to volumioVolatilePlay and flips your UI state. The upstream emitter continues to fire regardless. It is symptom suppression, not a fix, and I am not presenting it as a workaround. Leave Bluetooth enabled for the next reproduction so the stack trace capture has the full path to walk.