Follow-up after two more weeks of measurement on the same device (DMP-A6 Master Edition, 1st gen, v1

Hi Kim,

I have a reproducible regression on v1.5.90 that I don't think has been reported yet. It is not the I2S issue, and from your reply about v1.5.92 ("a specific fix for a random I2S issue") I don't expect .92 to address it — which is why I'm reporting it separately.

Device: Eversolo DMP-A6 Master Edition, 1st generation (not Gen 2) Firmware: v1.5.90 (official OTA, 22 July 2026) Source: TIDAL via airable, analogue XLR output Control: ZidooMusicControl v2 HTTP API, from a home automation server

Summary
Issuing seekTo on a track that has just been loaded kills the audio output. The device does not report an error and does not stop: it keeps reporting state = 3 (playing), and the position keeps increasing — but at roughly 2.5% of real time. There is no sound.

This is why I think it has gone unreported: from the app it looks like playback is running, just "stuck", and casual use rarely seeks on a freshly loaded track.

Reproduction
Each step is a plain HTTP GET to /ZidooMusicControl/v2/:

1. playMusic?... — load a single TIDAL track via airable (/tidal/track/<id>)
2. wait for the new instance to become live (getState reports state = 3)
3. playOrPause — pause it
4. seekTo?time=<ms> — seek to a position well inside the track (I use 50 000–310 000 ms)
5. playOrPause — resume
6. poll getState every 2 s

Expected: audio resumes from the target position. Observed: a brief moment of audio, then silence, while getState keeps reporting state = 3.

Measurements
Over 21 handoffs to the device on 27 July 2026:

condition result
14 landings with seekTo 12 dead
7 landings without seekTo (track starts at 0:00) 7 fine, full-speed playback, audio confirmed
The device dies exactly at the seek target:

seekTo target position where it died
58 000 ms 58 049 ms
94 000 ms 94 593 ms
138 000 ms 138 751 ms
184 000 ms 184 608 ms
309 000 ms 309 000 ms
51 000 ms 51 053 ms
A typical sample of getState in the failed state, polled every 2 s:







state=3 pos=60105 -
state=3 pos=60153 +48 ms
state=3 pos=60203 +50 ms
state=3 pos=60263 +60 ms
state=3 pos=60307 +44 ms
state=3 pos=60542 +235 ms

437 ms of track in 10 s of wall clock. In other episodes the position instead oscillates ±400 ms around the seek target. Either way it is not frozen — which matters, because a health check based on "is the position advancing?" reports the device as healthy.

Onset
I have a detector for "device stopped far from the end of the track" in my server logs since 8 June 2026:

• zero occurrences between 29 May and 22 July (6+ weeks)
• first two occurrences on 22 July at 23:10 and 23:24 — the evening v1.5.90 was released
• daily since

What I already ruled out

• currentOutput is not a usable indicator. It reads -1 in the failed state, but also -1 during perfectly healthy full-speed playback, and when the device is paused or idle. I initially thought it was a discriminator; it is not.
• Reloading the track and seeking again does not recover it — 7 attempts, 0 successes. It re-dies within 7–46 s, at the same point. Skipping 20 s past the "poisoned" offset did not help either.
• A physical power cycle does restore full-speed playback — but only until the next seekTo, which killed it again on the very next handoff.
• Not queue-related: it happens with a 1-item native queue and with 25 items.
• Not track-related: it happens on different tracks, and the same track plays fine when started from 0:00.

My current workaround is to never seek on this device — every room change restarts the current track from the beginning. It works, but it costs the listening position on every handoff.

Questions

1. Is this a known regression in v1.5.90?
2. Does v1.5.92 touch the streaming/seek path at all, or is it strictly the I2S fix?
3. Is "Cached Streaming Playback" (introduced in v1.5.90) involved, and is there any way to disable it? I can't find a toggle in the settings.

Happy to provide full logs, getState dumps, or to run any test build you'd like. The failure reproduces within seconds, so I can test quickly.

Thanks.

 

you have to toggle " cached streaming playback on " after the update so you it not enabled by the update itself.

 

Thanks Johnny. Could you tell me exactly where that setting lives? I've gone
through the settings on my DMP-A6 (1st gen, Master Edition, v1.5.90) and I
can't find any "Cached Streaming Playback" option — on the device UI or in
the Eversolo Control app.
Which model and firmware are you on? If it exists on yours and not on mine
that's useful information in itself.
Also, just to be sure I read you right: are you saying it should be turned
ON, or OFF?

 

Update on the "Cached Streaming Playback" suggestion: that option does not
exist on my device.
Settings (DMP-A6) > Playback, complete section on v1.5.90, is exactly these
13 entries:
Fixed sampling rate output / ReplayGain source mode / CD Auto Play /
Gapless playback / Previous button reset playback / Automatically switch
input source / Folder skipping playback / Skip to next device playlist /
Jump to the playback screen when starting / Auto-play behavior on startup /
Open playback screen on startup / Open VU Meter on startup / Eversolo
Original sampling-rate audio engine
Nothing containing "cache", "buffer" or "streaming" — in the Eversolo
Control app or on the device UI. The v1.5.75 changelog lists "Added
Streaming Playback Cache option", so I assume it's gated per variant.
Device self-report: model DMP-A6, firmware v1.5.90, Android 11,
RAM 4.0G, flash 32.0G, appcode 7952.
Two questions:
1. Should this option be available on this variant? If yes, its absence is
a bug on its own.
2. If it isn't available, then the streaming cache introduced in v1.5.90
cannot be disabled on my hardware — and it's my main suspect for the
seek regression. Is there another way to turn it off?

 

I don’t think so. When I did the update it was turned off and the only way to enable it was to use the actual screen on your device (not the remote) go to settings and tap the box to enable it .

 

On "Cached Streaming Playback": confirmed dead end. The toggle doesn't exist on this variant (as established above), and independently, on devices where it does exist it's reported OFF by default after the update — so it can't be what broke on 22 July. Ruling this out.

Root cause, narrowed: it's not seekTo as a static action — it's resuming too soon after the seek. Sequence tested: load → pause → seekTo (reflected, confirmed via getState) → wait N seconds while still paused → resume. With no wait (matching my original repro), it reliably kills the pipeline, same signature as before (position frozen exactly at the seek target, state=3, crawling at ~2-4% of real time). With a few seconds of pause held after the seek reflects, playback resumes clean at full speed from the target.

The threshold isn't fixed, though — it appears tied to how much the device has already been through:

• fresh reboot: 2s was sufficient, confirmed sane twice in a row with a 0s control freezing in the same run
• same evening, after a few freeze/cure cycles: needed 5s
• after repeated stress-testing (many forced freezes in a row): the device degraded to the point where nothing reliably cured it short of a power cycle

So this reads like some internal state accumulates with seek attempts / uptime, not a clean fixed timing constant. I'd avoid repeatedly forcing the freeze to hunt for an exact number — each cycle seems to leave the device worse, not neutral.

Recovery if it still freezes: toggling pause→play twice (on the same frozen position) resumes correctly from that exact position, without a reboot, in most cases — roughly 6 out of 8 attempts in my testing. Not 100% reliable, but it beats a power cycle when it works, and it's exact (I've confirmed the resumed position via delta-vs-wallclock measurement, same method as above — not just eyeballing getState).

Current workaround in production: pause → seek → hold 3s → resume, tuned conservatively toward the "fresh device" end of what I measured, accepting the small residual risk on a long-uptime device in exchange for less dead air on every room switch. Fallback if it freezes: double play/pause.

Still no indication v1.5.92/.95/.96 touch this — none of the changelogs mention seek, position, or streaming-cache internals. Will report back if that changes.