App version
Production
Issue description
Transcoded streams play at roughly 6.7x speed.
When Symfonium plays a transcoded stream from Navidrome, the entire track is
fast-forwarded at a constant ~6.7x and then goes silent. Direct play of the same
track is perfectly fine.
The whole track is audible (fast-forwarded to the end), and the factor is constant
across track lengths, so this is not a truncated download:
149 s track → playback ends after ~22 s (6.8x)
247 s track → playback ends after ~37 s (6.7x)
Immediately after seeking, playback is briefly correct and starts racing about one
second later. The track’s total duration is displayed correctly, so only the rate and
position are wrong. The seekbar waveform is also visibly broken: only the leftmost
~12% is rendered, the rest stays flat.
The ratio is identical for Opus at 48 kHz and MP3 at 44.1 kHz, so this does not look
codec- or sample-rate-specific.
Not the audio output path: Bluetooth, wired headphones and the phone speaker all
behave identically.
Not the server or the network: Chrome on the same phone, over the same connection,
playing the same transcoded stream from the same server, plays it correctly.
Clearing the cache, clearing app data and reinstalling did not change anything.
Enabling compatibility mode did not change anything either.
Device type
Phone
Media provider
Navidrome
Steps to reproduce
- Connect Symfonium to a Navidrome server (tested on 0.63.2).
- Enable transcoding for the current network (Opus 128 kbps or MP3 128 kbps -
both reproduce it). - Play any track whose source bitrate is higher than the transcoding target.
Mine are 320 kbps MP3, 44.1 kHz, stereo. - The whole track is fast-forwarded at ~6.7x and then goes silent.
- Turn transcoding off so the track is direct-played, and play the same track
again: it plays normally.
Additional information
ENVIRONMENT
Phone : REDMAGIC 11 Pro (NX809J)
SoC : Snapdragon 8 Elite Gen 5
OS : Android 16, build REDMAGICOS11.0.20_GB, kernel 6.12.23
security patch 2026-06-01, Play system update 2026-07-01
Symfonium : 14.1.0 (127734)
Server : Navidrome 0.63.2 on Windows, reached over LAN and Tailscale
Endpoint : /rest/getTranscodeStream.view
WHAT IS AFFECTED
Symfonium, transcoded Opus 128k / 48 kHz → ~6.7x speed
Symfonium, transcoded MP3 128k / 44.1 kHz → ~6.7x speed
Symfonium, direct play (raw) → OK
Chrome on the same phone, same stream → OK
Chrome on a PC, same stream → OK
SERVER OUTPUT VERIFIED CORRECT
I checked the files the server actually produces:
- decoded length matches the source exactly (148.99 s vs 148.99 s)
- correct sample rate (48000 Opus / 44100 MP3) and channel count
- Ogg granule positions monotonic, 1 s per page, no gaps, correct final value
- valid OpusHead (version 1, 2 ch, pre-skip 120, mapping family 0)
SERVER-SIDE LOG
Every playback attempt produces 6-7 stream requests for the same track within
about 1.5 seconds:
11:31:17 format=raw
11:31:17 format=opus bitRate=128 sampleRate=48000 cached=true
11:31:17 format=opus bitRate=128 sampleRate=48000 cached=true
11:31:17 format=opus bitRate=128 sampleRate=48000 cached=true
11:31:17 format=opus bitRate=128 sampleRate=48000 cached=true
11:31:18 format=opus bitRate=128 sampleRate=48000 cached=true
11:31:18 format=opus bitRate=128 sampleRate=48000 cached=true
The only errors the server records are client-side disconnects:
level=error msg="Error sending transcoded file"
error="write tcp <server>:4533-><phone>:48460: connection was closed"
A few HTTP 416 (Range Not Satisfiable) responses also appear on
getTranscodeStream requests.
It happens both when the server streams an uncached transcode (chunked,
Accept-Ranges: none, no Content-Length) and when it serves a cached one
(real Content-Length, range support).
I can provide server logs, the transcoded files themselves, or run any test.
I searched existing issues first
on
I understand that logs are mandatory
on
Log upload name / description
transcode-6.7x-speed-NX809J-2026-08-15