Acestream channels won't start on 1.0.14/1.0.15 — stuck in "Retrying TS" loop (works on 1.0.12)

[ViiKO4]

Summary

Acestream channels served via the HaP plugin (https://github.com/jopsis/StreamVault-IPTV-Plugin-HaP) fail to start on StreamVault 1.0.14 and 1.0.15. The player enters an endless Retrying TS 1/10 → 2/10 → … → 10/10 loop and never actually starts playback. Downgrading to 1.0.12 fixes the issue — channels start (though there is a separate freeze-after-10-15-min issue already discussed elsewhere, not in scope here).

I have not seen any public report of this regression, so I'm opening it. The root cause appears to be a one-line change introduced in 1.0.13 (commit 873086e) that sets TsExtractor.MODE_HLS for MPEG_TS_LIVE streams, which is incorrect for raw progressive TS served by the HaP proxy.

---

Environment

Field	Value
Device	Philips OLED718 (Google TV, SoC MediaTek MT9618, ARM64)
Android TV version	Android 11 / Google TV
StreamVault version (broken)	1.0.14, 1.0.15
StreamVault version (working)	1.0.12
Plugin	StreamVault-IPTV-Plugin-HaP v1.2.1
Source type	Acestream channels via HaP's local M3U at http://127.0.0.1:8888/aio (delivered as raw MPEG-TS, .ts URLs)
Other relevant settings	Decoder Mode = Hardware Only · Video Surface = SurfaceView · Live buffer size = Large

---

Steps to reproduce

1. Install StreamVault 1.0.14 or 1.0.15 on an Android TV device.
2. Install and configure the HaP plugin (v1.2.1). Add an Acestream source list.
3. Open any Acestream channel served by HaP.
4. Observe the player UI: it shows Retrying TS 1/10 … 2/10 … until it gives up after 10 attempts. The video never starts.
5. Downgrade to StreamVault 1.0.12 (same plugin, same source list, same device). The same channel starts playing immediately.

---

Expected behaviour

Channels served by HaP as raw MPEG-TS (http://127.0.0.1:8888/aio/.../<name>.ts) should start playback on 1.0.14/1.0.15 the same way they do on 1.0.12.

Actual behaviour

On 1.0.14 and 1.0.15, the TsExtractor produces no tracks for these streams, so prepare never completes, PlaybackException is raised, and PlayerRetryPolicy retries up to LIVE_TRANSIENT_RETRY_ATTEMPTS = 10 times before failing.

---

Suspected root cause

The regression was introduced in commit 873086e (21-May-2026, "Improve live playback recovery diagnostics"), which is not an ancestor of v1.0.12 but is an ancestor of v1.0.13, v1.0.14, and v1.0.15 — matching exactly the regression window.

The commit modifies PlayerMediaSourceFactory.kt for the MPEG_TS_LIVE branch:

// 1.0.12 (works) — no mode set, defaults to MODE_SINGLE_PMT
DefaultExtractorsFactory()
    .setTsExtractorFlags(FLAG_DETECT_ACCESS_UNITS | FLAG_ALLOW_NON_IDR_KEYFRAMES | FLAG_IGNORE_SPLICE_INFO_STREAM)
    .setTsSubtitleFormats(TS_SUBTITLE_FORMATS)

// 1.0.13+ (broken) — MODE_HLS forced
DefaultExtractorsFactory()
    .setTsExtractorMode(TsExtractor.MODE_HLS)   // <-- introduced by 873086e
    .setTsExtractorFlags(FLAG_DETECT_ACCESS_UNITS | FLAG_ALLOW_NON_IDR_KEYFRAMES | FLAG_IGNORE_SPLICE_INFO_STREAM)
    .setTsSubtitleFormats(TS_SUBTITLE_FORMATS)

TsExtractor.MODE_HLS is the mode that HlsMediaSource uses internally for TS segments inside an HLS playlist (with TimestampAdjuster and discontinuity handling). Applying it to a raw, continuous TS stream delivered via ProgressiveMediaSource — which is exactly what HaP's proxy serves — prevents the extractor from producing tracks, so preparation never completes.

Reference: TsExtractor.MODE_HLS documentation — "Suitable for HLS playback where TS segments are typically short and may contain discontinuities." Raw live TS served over HTTP (as HaP does) is not that case.

---

Why 1.0.15 didn't fix it

1.0.15 disabled shouldFallbackMalformedHlsToLiveTs and shouldFallbackStalledHlsToLiveTs (the maintainer clearly noticed the HLS↔TS fallback was problematic), but setTsExtractorMode(TsExtractor.MODE_HLS) for MPEG_TS_LIVE is still present in 1.0.15. The 1.0.15 fix only addresses the HLS→TS fallback path; it does not touch the TS extractor mode itself.

Additionally, the new "Prefer live stream format: Auto / HLS / MPEG-TS" setting added in 1.0.15 (PR #123) only affects Xtream providers (XtreamStreamUrlResolver.kt). Channels served via the HaP plugin do not go through that resolver, so the setting has no effect on this issue.

---

Suggested fix

In player/src/main/java/com/streamvault/player/playback/PlayerMediaSourceFactory.kt, remove setTsExtractorMode(TsExtractor.MODE_HLS) for the MPEG_TS_LIVE branch and let the extractor use the default MODE_SINGLE_PMT (as in 1.0.12). Keep the existing flags and subtitle formats.

// Proposed fix
DefaultExtractorsFactory()
    // .setTsExtractorMode(TsExtractor.MODE_HLS)   // removed — MODE_HLS is for HLS segments, not raw TS
    .setTsExtractorFlags(FLAG_DETECT_ACCESS_UNITS | FLAG_ALLOW_NON_IDR_KEYFRAMES | FLAG_IGNORE_SPLICE_INFO_STREAM)
    .setTsSubtitleFormats(TS_SUBTITLE_FORMATS)

MODE_HLS should only be used by HlsMediaSource internally, not by a ProgressiveMediaSource over a raw TS stream.

A regression test in PlayerMediaSourceFactoryTest.kt asserting that the factory for MPEG_TS_LIVE does not activate MODE_HLS would prevent this from coming back.

---

Logs

I don't have a logcat capture at hand right now, but the relevant code paths for confirming the diagnosis are:

• app/.../ui/screens/player/PlayerPlaybackMessageSupport.kt:42 — emits the "TS" label used in "Retrying TS N/N" because the resolved HaP URL ends with .ts.
• app/.../ui/screens/player/PlayerNoticeActions.kt:83 — builds the retry label "Retrying $formatLabel $attempt/$maxAttempts".
• player/.../playback/Media3PlayerEngine.kt:2338 — emits _retryStatus.value = PlayerRetryStatus(attempt, maxAttempts, delayMs).
• player/.../playback/PlayerRetryPolicy.kt — for MPEG_TS_LIVE with NETWORK/HTTP_SERVER/UNKNOWN categories, returns LIVE_TRANSIENT_RETRY_ATTEMPTS = 10.

---

Workaround

Stay on 1.0.12 for Acestream/HaP usage. 1.0.14 and 1.0.15 are unusable for this scenario.

---

Thanks for the work on StreamVault — really appreciate the project.

---

[NovaCyntax]

I don't know anything about plugins or acestream, but I do know that my XC playlist no longer plays Live TV in either HLS or TS formats. VOD works just fine.

[sm0keb0x]

I don't know anything about plugins or acestream, but I do know that my XC playlist no longer plays Live TV in either HLS or TS formats. VOD works just fine.

Same here. I use Dispatcharr to curate my m3u and I can see StreamVault connecting and requesting streams but it looks like it's giving up too quickly and keeps trying again. Sometime it disconnects after .5 to 2secs, and just keep looping

[christiangrs]

Same problem here 0.9 works, but in 0.14 and 0.15 no... i have a s25 ultra