Hey @AndrewHeard,
You are comparing fundamentally incompatible systems. This is not pears versus apples - this is comparing a steam engine to a smartwatch.
The timeline you are spanning:
Let me lay out what has changed between “Volumio 2” and “Volumio 4” so the scope is clear:
Debian Releases:
- Debian 8 Jessie: April 2015
- Debian 9 Stretch: June 2017
- Debian 10 Buster: July 2019
- Debian 11 Bullseye: August 2021
- Debian 12 Bookworm: June 2023
Volumio 2 ran on Jessie/Stretch era base. Volumio 3 ran on Buster. Volumio 4 runs on Bookworm. You are spanning three to four major Debian generations.
Kernel evolution:
- Kernel 4.9.x: December 2016 (Stretch era)
- Kernel 4.19.x: October 2018 (Buster initial)
- Kernel 5.10.x: December 2020 (Bullseye era)
- Kernel 6.1.x: December 2022 (Bookworm initial)
- Kernel 6.6.x: October 2023 (Volumio 3 late backport for Pi 5 support)
- Kernel 6.12.x: November 2024 (Volumio 4 current)
Your boot time comparison spans approximately 8 years of Linux kernel development and 4 major Debian releases. Each kernel major version adds drivers, security subsystems, hardware abstraction layers, and initialization requirements. Each Debian release updates systemd, adds services, and increases baseline complexity.
This was explained extensively in the Alpha test thread (April 2025) and Beta test thread (September 2025). Neither you nor @marcinmarcin participated in those testing phases where these architectural realities were documented and discussed.
Why 175 seconds on your Pi 3B+:
The Raspberry Pi 3B+ has a Cortex-A53 quad-core at 1.4GHz with 1GB RAM shared with GPU. This hardware was released in March 2018 and designed when kernel 4.x was current. Running Bookworm with kernel 6.12.x on it means:
- Initial overlayfs mount and storage resize operations are heavier under modern kernel
- Systemd service chain is longer and more complex than 2017-era init
- Kernel 6.12.x has substantially more subsystems to initialize than kernel 4.9.x
- RAM constraints force pressure during boot when modern services compete for memory
- USB 2.0 storage interface bottlenecks all I/O operations
SD card class does not meaningfully change this. You tested Samsung EVO Plus 2 versus SanDisk Ultra - both are fast cards. The bottleneck is not sequential read speed. The bottleneck is random I/O during systemd service initialization and the sheer volume of work the modern kernel must complete before handing off to userspace.
Supported does not mean Performance Guaranteed:
Volumio maintains support for older single-board computers including the Raspberry Pi 3B+ to ensure users are not abandoned. Support means the system will boot, function correctly, and receive updates. It does not mean performance parity with newer hardware. Once boot completes and processes are loaded into memory, audio playback and UI responsiveness operate normally - the Pi 3B+ handles runtime workloads adequately. Boot time is the price paid for running a modern OS on legacy hardware.
What would actually help:
Moving to a Raspberry Pi 4 with 2GB or 4GB RAM would reduce boot time significantly - not because of RAM for audio playback, but because:
- Cortex-A72 cores are substantially faster for boot operations
- USB 3.0 allows faster storage access if using USB boot
- More RAM means less pressure during initialization
- Hardware is contemporary with Bookworm expectations
Your concern about HAT clearance with a heatsink is solvable. GPIO extender/stacker headers exist specifically for this purpose - they raise the HAT above the Pi 4 heatsink. HiFiBerry DAC Plus is fully compatible with Pi 4.
Power supply concerns are valid. Pi 4 does require 3A minimum. Your 18650x2 UPS arrangement would need evaluation.
Regarding migration of Favorites and Web Radios:
This should have been documented more prominently. The data files from V2 were not directly compatible with V4 database structure. Manual recreation was the practical path for most users.
Regarding @marcinmarcin and Single Network Mode:
This is Volumio architectural behavior, not a bug in 4.071. Volumio operates with only one network interface active at a time by design. When ethernet is connected, WiFi is disabled. When ethernet is disconnected, WiFi should re-enable.
The claim that “Single Network Mode management is failing to switch WiFi back on” needs investigation with proper logs. If this is a reproducible problem, it requires a log link from http://volumio-IP/dev showing the issue occurring. Without evidence, it cannot be assessed or escalated.
Both of you: if you want issues investigated, provide logs per the help request guidelines. Observations without evidence cannot and will not be actioned.
Kind Regards,