64bit Support Message on QNAP Docker RoonServer 2.71 (ref#GDA7ME)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Roon-Support-Ticket – write with help from KI

Subject: QNAP Docker RoonServer 2.71 – repeated need 64bit support messages

Hello Roon Support,

I am running RoonServer in Docker on a QNAP NAS.

Environment:

RoonServer: 2.71 (build 1683) production
Docker image: ghcr.io/roonlabs/roonserver:latest
Image version: 1.0.8
Platform: amd64 / Linux
Docker network: host
QNAP NAS

The container starts normally and reports:

RoonServer installed successfully.
Image: 1.0.8
Branch: production
Roon: 2.71 (build 1683) production
Initializing
Started
Running

However, shortly after startup, the RoonServer log repeatedly prints:

[tantivy] IndexWriter build config: 1 thread(s), 128 MB budget
need 64bit support
need 64bit support
need 64bit support
...

The message is repeated many times.

At the same time, Roon appears to be functioning normally. The log shows:

watchdog tick: enabled=True sleeping=False db_loaded=True

and the library is successfully loaded:

tracks: 16820
albums: 1821
artists: 1266
works: 7384
performances: 8955
playlists: 17

Roon also successfully communicates with the Roon service:

POST to https://api.roonlabs.net/device-map/1/register
status code: 200

The system is definitely running a 64-bit userspace/kernel. For example, the Roon binary/library reports:

ELF 64-bit
03 00 3e 00

and /proc/cpuinfo reports the lm CPU flag.

The Docker container itself is also reported as:

amd64/linux

Could you please clarify what component produces the repeated need 64bit support message and whether this is a known issue with RoonServer 2.71 on QNAP/Docker?

Since Roon is otherwise running normally, I have not modified or deleted the Roon database.

Thank you.

Tell us about your home network

· Roon-Support-Ticket – Text zum Kopieren

Subject: QNAP Docker RoonServer 2.71 – repeated need 64bit support messages

Hello Roon Support,

I am running RoonServer in Docker on a QNAP NAS.

Environment:

RoonServer: 2.71 (build 1683) production
Docker image: ghcr.io/roonlabs/roonserver:latest
Image version: 1.0.8
Platform: amd64 / Linux
Docker network: host
QNAP NAS

The container starts normally and reports:

RoonServer installed successfully.
Image: 1.0.8
Branch: production
Roon: 2.71 (build 1683) production
Initializing
Started
Running

However, shortly after startup, the RoonServer log repeatedly prints:

[tantivy] IndexWriter build config: 1 thread(s), 128 MB budget
need 64bit support
need 64bit support
need 64bit support
...

The message is repeated many times.

At the same time, Roon appears to be functioning normally. The log shows:

watchdog tick: enabled=True sleeping=False db_loaded=True

and the library is successfully loaded:

tracks: 16820
albums: 1821
artists: 1266
works: 7384
performances: 8955
playlists: 17

Roon also successfully communicates with the Roon service:

POST to https://api.roonlabs.net/device-map/1/register
status code: 200

The system is definitely running a 64-bit userspace/kernel. For example, the Roon binary/library reports:

ELF 64-bit
03 00 3e 00

and /proc/cpuinfo reports the lm CPU flag.

The Docker container itself is also reported as:

amd64/linux

Could you please clarify what component produces the repeated need 64bit support message and whether this is a known issue with RoonServer 2.71 on QNAP/Docker?

Since Roon is otherwise running normally, I have not modified or deleted the Roon database.

Thank you.

2

Hello @Udo_Richartz

Thank you for the level of detail here, it made this quick to pin down.

Your system is fine, and the message is not about it. Nothing in it refers to your CPU, kernel, userspace or container. Your ELF check, the lm flag and the amd64 platform are all correct, and none of them are relevant.

What produces it. It comes from our reader for MP4 audio files, which runs as a separate helper process. In MP4, every atom carries a 32-bit size field, and a value of 1 means the real size is held in a following 64-bit field instead. That larger form is what this reader does not handle, so it abandons the file and prints that line. The “64bit” refers to a field inside the file, not to anything on your machine.

That also explains why it sits next to the [tantivy] line and why neither carries any context. Both are written straight to the container’s output rather than into the Roon log file, so they arrive interleaved and unlabelled. Neither line appears in your Roon log at all, which we checked.

And we can tell you exactly which files. There are 147 of them, all .m4a, all in these two folders:

/Music/Sprachmemos/Sprachmemos/
/Music/Compilations/Sprachmemos/

They are named Neue Aufnahme 1.m4a, Neue Aufnahme 2.m4a and so on, which makes them Voice Memos recordings rather than music. Your Roon log records the same failures under a different name, UnsupportedFormat, 2,793 attempts in total, because each file is retried on every rescan. Nothing else in your library fails. Only these 147.

So it is cosmetic in your case, which matches what you observed. The library loads, playback is clean, and there are no dropouts anywhere in the period we reviewed.

What will stop it. Since these are voice recordings rather than music, the simplest answer is to take them out of Roon’s scope. In Settings, then Storage, please edit your watched folder and exclude the Sprachmemos directories, or move them outside your music folder. That removes both the container messages and 2,793 warnings from your Roon log.

Worth knowing while you are there: those same recordings exist in two places, under Sprachmemos and under Compilations/Sprachmemos, so Roon is scanning both copies.

On whether it is known. It is a limitation in that reader rather than a QNAP or Docker issue, and it would behave identically on any platform. We are filing it, along with the fact that the message names no file and reads as though it were a platform problem, which is what sent you looking at your kernel.

3

Hi @Udo_Richartz,

Just to summarize: Roon Server is choking on the m4a files contained in the voice memos folder inside of a Watched Folder. These are iOS/Apple voice memos, not music track files.

Try disabling this particular folder or excluding it from Watched Folders in Roon.

Please let us know if this helps. This thread will auto-close without any new responses after the next few days. Thank you!

4

Hello,

I thank you very much for the great support!

I have moved the ‘Sprachmemos’ directories outside my music folder. That removes both the container messages and the warnings from my Roon log.

I’m just hoping the next update installs successfully; the last one kept throwing an error, and I had to use a complicated workaround involving AI—during which the error messages related to voice memos also became visible.

Should an update normally run without issues when Roon is running in a container? Or is there anything specific to consider for this setup?
Many thanks in advance!

Udo Richartz