If you haven’t tried - don’t write a theory. I had such a situation on 3 of my 5 Rpi (v.65). Factory reset updated me to v.66 (first it uploaded v.65, then it updated to v.66 itself). I wouldn’t write this if I hadn’t done it myself.
coincidence? witchcraft?
@nerd what do you think about it?
Hey @JohnR,
Thanks for the photo. That Wi-Fi adapter is a “Wi-Pi” branded USB dongle, model reference COMFAST 8188, as indicated by the FCC ID printed on the casing:
FCC ID: OWVCOMFAST8188
Labelled Name: Wi-Pi
OEM: Shenzhen COMFAST (CF-WU815N series)
This model is based on the Realtek RTL8188CUS chipset, which uses the rtl8192cu driver in Linux, not rt2800usb as previously assumed from logs.
Summary
You are using a Realtek RTL8188CUS-based USB Wi-Fi adapter, under the brand “Wi-Pi” (COMFAST CF-WU815N), not a Ralink RT5370 as the USB ID 148f:5370 originally suggested. This explains the inconsistent behavior.
This chipset is known to have issues with recent Linux kernels and hotspot mode. It was once commonly used with the Pi Model B, but is no longer reliable for hotspot creation under Bookworm without patched drivers or a DKMS workaround.
Whilst trying to source similar for testing - let me know if you’d like tested replacement model recommendations.
Kind Regards,
I believe this is confusing, this link says the wi-pi has a Ralink rt5370 chipset, which also corresponds with the log @JohnR sent.
For some reason, the rt5370 refuses ap-mode, which is inconsistent with ralink usb adapters being used in other volumio setups. In fact, one of the Volumio OEM customers distributes a ralink rt5370 adapter with their device.
@JohnR did you try this setup with a current buster-based V3.812 version?
Hey @gkkpch,
Thanks for weighing in.
Testing the same adapter with the current Buster-based V3.812 is worth its weight in gold - it will confirm whether the issue is driver regression or hardware misclassification.
To clarify and prevent a detour:
While the USB ID in @JohnR’s log (148f:5370) does map to Ralink RT5370, and that chipset is widely used and normally well-supported under rt2800usb, the physical photo provided by JohnR shows a different unit entirely:
- The adapter is branded “Wi-Pi”
- The FCC ID on the casing is OWVCOMFAST8188
- This explicitly refers to a Realtek RTL8188CUS-based device, not a Ralink unit
So while the USB ID is spoofed to 148f:5370, the actual chipset is Realtek, not Ralink. This explains:
- Inconsistent behavior with AP mode
- Hostapd failing even when rfkill is unblocked
- Mismatch between expectation (rt2800usb) and real driver loaded (rtl8192cu)
This situation is not hypothetical. It is a known issue with some no-brand or rebadged adapters that reuse USB IDs but use a different internal chipset. This adapter was sold under the “Wi-Pi” name over a decade ago and can misreport itself as a Ralink device.
We are not dealing with a standard RT5370. We are dealing with a Realtek 8188CUS disguised as one.
I’m already researching this in the context of our Volumio 6.12.27 kernel build. For reference, here’s the upstream driver config:
Kind Regards,
Hey @Dick_van_der_Wal, @Gelo5,
Thanks for sharing your results. What you’re describing - OTA to 0.066 completes, but system still reports 0.065 until after factory reset - suggests the update was applied, but version info wasn’t properly committed or synced. This could be due to overlay write delays, filesystem issues, or stale cache.
This issue is not reproducible on my test builds. OTA behaves as expected and correctly reports version 0.066 after reboot.
To investigate properly, we need:
- Raspberry Pi model and board revision
- SD card brand, model, and size
- Power supply details
- Logs from the first boot after OTA - before factory reset
You can get those by visiting:
http://<volumio_ip>/dev
Once we have the logs, we can determine whether this is a hardware-related timing issue, a filesystem sync problem, or something else.
Kind Regards,
I can’t reproduce this situation anymore. I have 3 Rpi4 v.66 and 2 RPI5 with Buster, but… with a fresh v.65 installation of volumio on rpi4 - it installs v.66 by itself:
FACTORY RESET
and…
http://logs.volumio.org/volumio/a1sLmnm.html
Hey @Dick_van_der_Wal ,
Thanks again for sharing your findings. Based on detailed log analysis, I’ve identified backend plugin crashes as the likely cause of the version mismatch issue after OTA from 0.065 to 0.066.
Step-by-Step Test
-
Flash a clean Volumio 0.065 image to your SD card.
-
Before connecting to the network or allowing OTA:
-
Go to the UI → Plugins > Music Services
-
Disable the following plugins:
- YouTube Cast Receiver (
ytcr) - YouTube Music (
ytmusic)
- YouTube Cast Receiver (
-
-
Let the OTA update proceed to 0.066 as usual.
-
After reboot, provide a new set of logs.
What We Found
In the last test, both ytcr and ytmusic caused backend instability:
-
ytcrproduced 164 runtime errors related to missing session data:IncompleteAPIDataError: Missing data required to construct query string from bind params -
ytmusicfailed to load with a missing module:Cannot find module './lib/YTMusicContext'
These errors appeared 164 times each and caused the backend to crash repeatedly, preventing the system from updating its version metadata. The update was applied, but due to the failed boot sequence, Volumio remained stuck reporting version 0.065.
We need logs from the next OTA attempt with both plugins disabled to confirm this resolves the issue.
Kind Regards,
yes you re right wenn you instruct me like that, but it cannot be the problem, because i am trying to get ytcr en youtubemusic running. Because it is really annoying that it is not working yet. But the first attempt for updating to 0.66 was before i was try to get plugins running. So if the orginal plugin is te problem, ter must be mucht more people with te same problem likes me.
Hey @Dick_van_der_Wal,
Absolutely fair point - and no worries at all. You’re not stirring muddy waters; you’re doing exactly what an Alpha tester should do: observe, report, and question behavior when something doesn’t add up. Every detailed report like yours helps us clarify, catalogue, and isolate real problems, even if they turn out to be unrelated to Bookworm itself.
Both mentioned plugins are currently chasing shifting API changes. The plugin developer @patrickkfkan is actively working to keep up with upstream changes, and broken behavior at runtime isn’t unusual given how fast those endpoints change.
Our current focus is stabilizing the Bookworm base, so identifying when plugin issues cascade into system-level faults - like OTA version mismatch or backend boot failure - is critical. Your case helps us document an important scenario: pre-existing enabled plugins surviving OTA and causing post-upgrade instability. Even if it’s not a widespread issue yet, it’s a valid edge case that needs to be handled properly.
Thanks again for your persistence and clarity.
Kind Regards,
Hi @nerd ,
reboot done
Sorry to disappoint you, there are still player restarts while playback via Tidal Connect:
http://logs.volumio.org/volumio/INiflNa.html
Disconnect from Tidal, the title that is played continues…
http://logs.volumio.org/volumio/PI6xGwy.html
Again disconnect - but it seems to reconnect here:
http://logs.volumio.org/volumio/9JrVYXI.html
Disconnect - this time the Tidal App also crashes!:
http://logs.volumio.org/volumio/X8Rf7cu.html
Confusion: MyVolumio activated: TidelConnect does not see the device. MyVolumio switched off: Tidal Connect does see the device. 
http://logs.volumio.org/volumio/o5ZGyFk.html
Cheers, Robert
Hey @Robert.Hecht,
Thanks for the detailed logs and precise testing sequence. After a full review of all 5 logs, including /etc/asound.conf, plugin state, and service behavior, here’s the consolidated analysis:
Findings from Logs
1. Spontaneous Restarts - Tidal Connect Active
In multiple logs (e.g., INiflNa, X8Rf7cu), the volumio backend process crashes with:
node: ../deps/uv/src/unix/poll.c:113: uv_poll_stop: Assertion `!uv__is_closing(handle)' failed.
systemd[1]: volumio.service: Main process exited, code=killed, status=6/ABRT
This strongly indicates an unhandled async event closure - possibly triggered by a socket disconnection or conflict in player control state during or after Tidal Connect session changes.
2. Multiroom-related output switching
The stack is logging:
MRS: Pushing multiroomSync output
consistently right before the segmentation. However, your current /etc/asound.conf is not using any multiroom PCM, which confirms this was already disabled - so the crash is not due to multiroom PCM routing.
3. Tidal Connect Agent Interaction
In logs like o5ZGyFk.html, we see:
MYVOLUMIO: Adding device
...
error: Failed to add MyVolumio device: {"message":"USER_NOT_FOUND"}
and alternately:
Tidal Connect device missing while MyVolumio is active
This inconsistency suggests a possible auth/session race between MyVolumio token and Tidal Connect presence broadcast.
Preliminary Conclusion
This is not a fault in the ALSA backend or output routing itself. Instead, the observed crashes:
- Involve Volumio player core service failing under Tidal Connect conditions.
- Are likely triggered by a race or invalid state during a reconnect (possibly when Android/iOS background behavior interrupts media).
- MyVolumio presence might be conflicting with Tidal Connect agent initialization or its expectations.
Next Steps to Narrow Down
Please try the following:
-
Disable MyVolumio Temporarily
- Reboot with MyVolumio disabled
- Test several Tidal Connect play-pause-disconnect sequences
- Observe if the crash still occurs
-
Confirm if Spotify or Local Sources Reproduce It
- Play local files or Spotify via plugin
- Test connect/disconnect device screen lock behavior
-
Enable Full Node Debug
Temporarily run:export NODE_DEBUG=net,timers,stream,volumio systemctl restart volumioThen capture a log on the next crash. This would surface the async event or handle mismatch if it’s really the issue.
Thanks again for your deep testing and continued patience. This helps ensure we fix it at the right layer.
Kind Regards,
Hi @nerd ,
without MyVolumio enabled I’m not able to use Tidal Connect nor Tidal as a source. Or did I get something wrong?
Cheers, Robert
Hi @nerd ,
Since I’ve no Spotify account somebody else should run this test.
Playing local files (USB or NAS) is working as intended. No interruptions, no breakdowns, no disconnects, no crashes.
Cheers,
Robert
Hey @Robert.Hecht,
Excellent points - you’re absolutely right to call this out.
Indeed, Tidal Connect and plugin access do require an active MyVolumio session. That step in the test matrix wasn’t meant as a permanent setup, but rather to temporarily rule out if MyVolumio state propagation is introducing the crash - essentially a session-related variable we can toggle. But yes, doing that does disable Tidal entirely, which makes the suggestion… well, a bit circular. Thanks for pointing it out before I dug that hole deeper.
Your clarification that local playback is fully stable also strengthens the hypothesis that this is either:
- A MyVolumio ↔ Tidal Connect race, or
- A low-level session handler edge case, most likely triggered during reconnect/disconnect cycles.
We’ll reframe the test plan accordingly, and I’ll follow up internally with a more accurate isolation path.
Thanks again for the spot-on correction and sharp attention.
Kind Regards,
1 Like
Hi @nerd ,
here’s the log with more debug information as requested:
http://logs.volumio.org/volumio/Q44gHl8.html
one more:
http://logs.volumio.org/volumio/ZbZvQYK.html
Hope it helps…
Cheers, Robert
I just heard 4 gaps in the playback:
Hi Nerd,
I would welcome any suggestions about tested replacement model. As I said before I have several that never work in hotspot mode. I have sent a log file of the same hardware working with the latest version of Volumio 3. I hope this will be useful. http://logs.volumio.org/volumio/dvwqR9x.html
Regards
Hey @JohnR,
Thanks again for your detailed contributions and the logs. They’ve provided essential insight into what’s happening on both Volumio 3.812 (Buster) and 0.66 (Bookworm).
In the Buster log, the firmware for your Wi-Fi adapter is clearly requested and successfully loaded:
ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
This event is completely absent in the Bookworm log, even though the same driver (rt2800usb) loads and the chipset is identified as:
ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5370 detected
That discrepancy is my current working theory for why hotspot fails under Bookworm. I’ve verified that rt2870.bin is not present in the build. It’s also possible the firmware request is occurring but being suppressed by boot-time log options (quiet loglevel=0 use_kmsg=no), which would hide both successful and failed attempts from dmesg.
Earlier in the thread, I proposed the adapter might be Realtek-based (RTL8188CUS), based on the FCC ID visible in the photo you shared - which does match some COMFAST-branded Realtek devices. That led to the theory that it could be spoofing a Ralink USB ID.
However, based on consistent log output showing driver loading and chipset probing via rt2800usb, the behavior now supports a theory that it may be a genuine RT5370 adapter after all. I’m treating that as the working position unless new evidence arises.
Here’s what I’d like you to do next:
-
Connect the adapter, then temporarily raise the kernel log level to expose any suppressed messages:
sudo dmesg -n 8 -
Reload the driver to simulate a fresh boot:
sudo modprobe -r rt2800usb sudo modprobe rt2800usb -
Check the log for firmware request or load messages:
dmesg | grep -i rt2870 dmesg | grep -i firmware
This will confirm whether the firmware request is occurring and simply hidden, or not being made at all due to the missing file. Based on the result, I’ll advise the next step.
Kind Regards,
Hey @Robert.Hecht,
Thanks for following through with the debug session and sharing the logs.
Detailed Observations
1. Q44gHl8
- The system is up and running normally.
- No sign of SIGABRT, SIGSEGV, or
code=killed. - All modules including Tidal, librespot, and CoreCommandRouter operate without error.
- Playback commands (play, pause, next) are logged and acknowledged.
- No Node.js fatal assertion or uncaught exception is shown.
2. ZbZvQYK
- Continuation of typical playback sessions.
- No abnormal exits or service failures.
- Logs show command routing and Tidal connection management.
- All services respond as expected;
volumio.serviceis stable.
3. j2B1Lov
- Some gaps in playback were subjectively reported.
- The log shows sustained operation of go-librespot with dealer pings/pongs.
- No indication of process restarts or backend-level aborts.
- The Tidal stream remains active; no termination of backend service.
Suggested Next Step
This specific debug level (NODE_DEBUG=net,timers,stream,volumio) is intended to capture lower-level event loop activity and network/socket state. It will help trace the original SIGABRT termination we previously observed during TIDAL Connect use - particularly when the player was interacting with an Android device lock event and MyVolumio was active.
You had disabled nearly all plugins in that earlier test, which helped stabilize playback. We are now looking to reproduce the crash again with only essential modules active and this debug level enabled:
export NODE_DEBUG=net,timers,stream,volumio
systemctl restart volumio
Then proceed with TIDAL Connect use under conditions that previously caused issues:
- Locking the phone screen while connected
- Disconnecting and reconnecting TIDAL Connect sessions
- Using the Volumio UI for pause/resume/track change while TIDAL Connect is active
If a gap, stall, or crash occurs, capture the log the same way and post the link.
We are now focused on verifying whether the internal signal termination can be consistently triggered - and if so, what async event or handler is responsible.
Kind Regards,