Thanks again for the update and log. From previous iteration it seemed that the device was blocked by the phy0 bindings. Now, we can see the real cause and effect.
To proceed with any firmware handling or overlay adjustments, we first need to positively identify the exact wireless module you’re using.
While the USB ID 0e8d:7961 confirms this is a USB-connected device, it does not uniquely identify the hardware. This ID is reused by at least 11 known mainstream modules excluding variations from multiple manufacturers, and in many cases those are mini PCIe or M.2 cards internally repackaged in USB enclosures.
Manufacturers using this ID include, but are not limited to:
ALFA
AzureWave
COMFAST
SparkLAN
Lite-On
Foxconn
LCFC
MediaTek reference boards
OEM-branded modules from Lenovo, HP, Dell, Acer, etc.
These modules may differ in:
Whether Bluetooth is physically present or fused off
Visible model label or packaging with identifying markings
Right now, I am guessing that your device is based on mt7921* kernel module, no way knowing which one. Once the exact hardware is confirmed, we can assess firmware suitability and safely advise on configuration or masking.
just to be sure, this is becouse the firmware gets loaded too late in the boot process works?
if you didnt get it, it works if i connect after boot from the menus, but for obvious reasons i can only do this with cable plugged in.
Thanks for confirming the module is a COMFAST CF-953AX. To properly understand why Wi-Fi is only usable after boot, and to assess any limitations with setup or AP mode, we’ll need a full hardware and driver diagnostic from your system.
Please follow the instructions here to run our official Wi-Fi diagnostics script:
Just installed 4.015 via OTA - went without problems.
Unfortunetely: Capability of reboot from installer/GUI disappeared again - hard reset neccessary.
BT remote still is connected but doesn’t work.
(HW) Config:
Pi5,
Raspi 2 Display (DSI),
Two rotary encoders on several GPIOs
NO (working) BT remote
Testing:
Spotify plugin, works (my only use case).
Touch display (and corresponding plugin) works
“Now Playing” plugin works
Rotary encoders are both working
WiFi is working (can access from laptop / phone).
BT remote is NOT working (connected but no signals detected)
CORRD link still only leads to app-store, no intergrations as far as I can see.
Summary:
Pi4B with SD or SSD and HDMI - works
Pi4B with SD or SSD and USB dac - works
Pi5B with SD or SSD and HDMI - fails
Pi5B with SD or SSD and USB dac - works
Conclusions:
My Pi5 doesn’t like HDMI for SOME but not all media.
Can’t be the HDMI cable
No difference SD or SSD boot
Thanks again for the excellent log and structured comparison across Pi4 and Pi5, HDMI and USB DAC.
After analyzing the Pi5 + HDMI failure log (mdeRXQe), I can see something concerning:
The Spotify plugin crashes due to a segmentation fault in go-librespot:
Jul 05 12:54:53 volumio go-librespot[1864]: Segmentation fault (core dumped)
error: system crashed: player: callback from go-librespot threw: TypeError: Cannot read properties of null (reading 'mute')
This segfault leads to a player state exception and a restart. The crash appears to occur when using HDMI audio output on the Pi5. It does not happen when using a USB DAC, nor does it appear in Pi4 logs under any output path.
At this stage, it’s unclear if this is a hardware-specific compatibility issue (e.g., Pi5 HDMI audio path with certain codecs), or something isolated to your current config.
We’ll hold off broader conclusions until we see more reports from other users. If you or anyone else can reproduce this on a fresh setup or different Pi5 unit, please share logs again. That would help narrow it down further.
Thanks again for your continued testing and detailed feedback on 4.015 - much appreciated.
OTA success confirmed - excellent.
Unfortunately, we’ve noted your report about the reboot-from-GUI reappearing. We’ll recheck the shutdown signaling path for this build. If you’re able to capture logs after triggering the GUI reboot (before hard reset), that would help isolate the issue.
Regarding the Bluetooth remote: still noted as connected but not delivering input events - understood and consistent with previous builds.
Just to reassure you - I haven’t forgotten about this. The BT controller has arrived here, but I’m currently occupied with some high-priority tasks. As soon as I free up, I’ll resume structured debugging specifically around HID input handling and triggerhappy interaction.
Also acknowledged:
Pi5 + Raspi DSI + rotary encoders working well
Spotify and Now Playing plugins stable
WiFi access intact
CORRD link behavior noted - still redirecting to app store with no backend integration available yet. We’re tracking that separately.
Appreciate you continuing to ride the Beta wave and log these insights - they’re helping shape how we harden the base before full release.
Dear @nerd , thanks for your acknowledges - especially on the Bluetooth matter - as mentioned earlier this is not urgent to me so take your time and do the really important stuff first!
Regarding your ask for capturing logs: Unfortunatley the reboot command from the GUI puts the system in a „halt“ condition - so it isn‘t accessible anymore.
Are you aware of a method to get a log in this state?
If possible I would try it next time.
Warmest regards and MANY thanks (I guess from all of us) for all of your huge effort!
@nerd
Hi, I retested here with 4.015 on Lenovo Yoga 520 and as the were no platform changes I skipped testing of the other 5 platforms (if required, on request).
I did not experience any issues except the one mentioned below.
I did make an exception to the test range because of a report we got today regarding Intel WiFi ax2xx chips.
As we do not have any details yet (request pending), I retested the Volumio 4 beta on a Lenovo Thinkpad T15V with an ax211 wifi chip, just to verify we have no issues there with chip support .
Test shows all OK, but…
There are still issues with configuring wifi on first boot (depending on chip?).
Any movement or new insights here?
Thanks for confirming the retest results on 4.015 and for checking Intel AX211 compatibility on the ThinkPad T15V.
Regarding the ongoing Wi-Fi first boot behavior:
The issue stems from the fact that the initial setup wizard assumes AP+STA capability without confirming adapter limitations. This leads to unpredictable results on adapters that only support one mode at a time (typically STA-only or AP-only).
Currently, the backend declines changes to core network behavior, and adapter logic is deferred entirely to wireless.js. While wireless.js does implement save-state logic, it does so only once a connection is established. During the wizard, no connection yet exists, leaving the system in a chicken-and-egg scenario.
The result is:
On first boot, Wi-Fi initialization may fail or behave inconsistently depending on the chip’s capabilities.
Adapters without AP mode support (common in newer AX-class chipsets) fail to spawn the hotspot.
There’s no fallback or adaptive logic at wizard stage to handle this gracefully.
We may need an explicit detection and pre-check routine inside wireless.js to verify AP/STA capabilities before any connection attempt, then adapt the mode accordingly before the wizard launches. This would allow a smarter, deterministic behavior on first boot.
Thanks for running the diagnostics script - this gives us a much clearer picture.
We can confirm that your COMFAST CF-953AX adapter, using the mt7921u driver, does support both STA (client) and AP (access point) modes. That means in theory it should be fully compatible with Volumio’s Wi-Fi and hotspot features, including AP+STA operation during setup.
However, the behavior you described - where Wi-Fi only works after boot, and only if configured from the UI - suggests a race condition or delay in how the adapter is enumerated over USB. Specifically:
The interface is not ready early enough during boot to be picked up by Volumio’s network stack.
This prevents first-time Wi-Fi setup from working unless Ethernet is connected.
After boot, manual reconfiguration works because the driver and firmware are loaded by then.
This dual behavior is real and not uncommon with USB-packaged chipsets that rely on deferred firmware loading or long init chains.
We will investigate further whether this can be addressed at the system level — for example, with a udev rule, deferred driver load, or service dependency adjustment. In the meantime, we recommend ensuring the adapter is always plugged in at boot and using Ethernet for initial setup if possible.
Dear @Wheaten , dear @nerd ,
it just came in my mind that is not THAT useful if I wait until your next release because you might had fixed the reboot issue in this release and my logs are useless.
So I’ve just tried Wheaten’s tip.
Unfortunately my expecation is correct.
Reboot from Volumio GUI shuts down the system in a “halt” condition.
SSH connection gets lost and connot be re-established.
So I’m not able to get a log out of this state, sorry.
System status is signalled with permanently red LED.
OK, this seems to be doable .
Currently I’m on the road until Thursday evening.
Will give this a try on Friday and will post result logfile here.
Thanks for advice!
thanks… ive tried delay services added delay to wireless.js but cant get it to work… another small media os (libreelec) has wait for network option, maybe you can steal that idea
