LL-HLS Orchestrator never links Origin for a fresh WHIP stream ("Could not find Origin for the stream") — no config/version workaround found

[sachin-iam]

Describe the bug
After a WHIP stream begins publishing successfully (confirmed ACTIVE by the server), the
Orchestrator sometimes never links an LL-HLS origin for it. The following line repeats
every ~2 seconds, sometimes for 30-70+ seconds, sometimes indefinitely until the server
process is restarted:

[Orchestrator] orchestrator.cpp:535 | Could not find Origin for the stream: [#default#live/<streamKey>]

No LL-HLS output is ever produced for the affected stream until (if ever) this resolves.
This is not tied to stream-key reuse — it reproduces on brand-new, never-before-used
stream keys as well.

To Reproduce
Steps to reproduce the behavior:

1. Start OvenMediaEngine with a stock/default config — WHIP provider enabled, LLHLS
   publisher enabled, no ABR (single bypass-only rendition), OriginMode = true.
2. Publish a stream via WHIP using plain ffmpeg (no custom application logic involved).
3. Intermittently, check server logs — the Orchestrator fails to link an origin for the
   newly-registered stream even though the stream is otherwise ACTIVE and receiving media.
4. See the "Could not find Origin for the stream" error repeating.

We were unable to find a 100%-reliable single trigger — it is intermittent rather than
tied to one specific action.

Expected behavior
The LL-HLS origin should link promptly (within the normal few-second WHIP-ingest-to-
origin-ready window) for every stream that is successfully ACTIVE.

Relevant configuration (Server.xml)

<Providers>
    <RTMP />
    <SRT />
    <WebRTC>
        <Timeout>30000</Timeout>
    </WebRTC>
</Providers>

<Publishers>
    <AppWorkerCount>1</AppWorkerCount>
    <StreamWorkerCount>8</StreamWorkerCount>
    <LLHLS>
        <OriginMode>true</OriginMode>
        <ChunkDuration>0.5</ChunkDuration>
        <PartHoldBack>1.5</PartHoldBack>
        <SegmentDuration>6</SegmentDuration>
        <SegmentCount>10</SegmentCount>
        <CreateDefaultPlaylist>true</CreateDefaultPlaylist>
        <DVR>
            <Enable>true</Enable>
            <TempStoragePath>/tmp/ome_dvr/</TempStoragePath>
            <MaxDuration>10800</MaxDuration>
        </DVR>
    </LLHLS>
    <WebRTC>
        <Timeout>30000</Timeout>
    </WebRTC>
</Publishers>

<!-- OutputProfile: single bypass-only rendition, no ABR/transcoding -->
<Video>
    <Name>bypass_video</Name>
    <Bypass>true</Bypass>
</Video>
<Audio>
    <Name>aac_audio</Name>
    <Codec>aac</Codec>
    <Bitrate>128000</Bitrate>
    <Samplerate>48000</Samplerate>
    <Channel>2</Channel>
    <BypassIfMatch><Codec>eq</Codec></BypassIfMatch>
</Audio>

Logs
Real excerpt from a production occurrence (2026-07-31) that eventually self-resolved:

[2026-07-31 13:12:40.741] E [SPLLHLS-t8090:45] Orchestrator | orchestrator.cpp:535  | Could not find Origin for the stream: [#default#live/sk_ded5c443...]
[2026-07-31 13:12:42.751] E [SPLLHLS-t8090:45] Orchestrator | orchestrator.cpp:535  | Could not find Origin for the stream: [#default#live/sk_ded5c443...]
(repeats every ~2s for 37 seconds)
[2026-07-31 13:13:17.888] I [OutboundWorker:56] LLHLS Publisher | llhls_stream.cpp:1409 | LLHlsStream::ComputeOptimalPartDuration() - Video track(0) FrameRate(30.067895)...
[2026-07-31 13:13:22.867] I [AW-LLHLS0:58]  LLHLS Publisher | llhls_stream.cpp:1768 | LLHlsStream(#default#live/sk_ded5c443...) - Ready to play : Part Hold Back = 3.213000

A separate occurrence the same session never self-resolved and required a full server restart — the stream stayed at outputs: [] indefinitely, confirmed via:

[2026-07-31 13:11:11.911] W [SPAPISvr-t8081:60] APIController | controller_base.h:179  | HTTP error occurred: [HTTP] Could not find the stream: [default/#default#live/sk_bb423de5...] (404)

Full OvenMediaEngine.log for this window available on request — trimmed here for readability.

Server (please complete the following information):

• OS: Linux (Ubuntu, production VPS) and macOS (Docker Desktop) — reproduces on both
• OvenMediaEngine Version: v0.20.5 (also reproduced on v0.20.0)
• Branch: master (Docker image airensoft/ovenmediaengine:latest)

Player (please complete the following information):

• Device: Not player-specific — failure occurs server-side before any output is produced
• OS: N/A
• Browser: N/A
• Version: N/A

Additional context
Things we ruled out through direct testing: OriginMode true/false (both fail), DVR on/off
(no difference), audio codec/bypass settings (no difference), StreamWorkerCount/
AppWorkerCount ratio variations (no difference), ABR/transcoding load (reproduces with
ABR fully disabled), stream-key reuse (reproduces on fresh, never-reused keys too).

Related issues we checked but don't appear to match: #745 (different topology,
Origin/Edge + OVT), #1464 (different trigger — startPushPublishing between apps on the
same server, different error signature), #969 (closest in shape, but that report
self-recovers in ~1 minute; ours is frequently permanent until a server restart).

[sachin-iam]

Happy to provide any additional specific logs, config diffs, or a fresh reproduction if needed — the environment testing above was done through direct experimentation, not just log analysis.

[getroot]

I haven’t seen this problem before. It’s likely that the stream wasn’t created properly due to an encoder-side or network issue. If you attach the log file and share the ffmpeg command you’re using for WHIP, I can analyze it further. Please also check whether it reproduces with OBS or OvenLiveKit (https://demo.ovenplayer.com/demo_input.html).

[sachin-iam]

Thanks for the quick reply — here's everything you asked for:

1. ffmpeg command used for WHIP

ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 -f lavfi -i "sine=frequency=1000"
-c:v libx264 -preset veryfast -tune zerolatency -pix_fmt yuv420p -g 60 -b:v 1500k
-c:a libopus -ac 2 -b:a 128k
-whip_flags dtls_active
-f whip -t 30 "http://:3333/live/?direction=whip"
Two flags were required beyond the obvious ones: -whip_flags dtls_active (ffmpeg's WHIP muxer otherwise offers a DTLS role our OME rejects), and -ac 2 (OME/WebRTC rejects mono audio — "Unsupported audio channels 1 by RTC, choose stereo"). -c:a aac also fails outright ("whip muxer supports only codec opus for type audio"), so audio has to be libopus.

2. Log file

Full production log for the exact incident window (2026-07-31, 13:10–13:20, the same occurrence quoted in the original report): https://gist.github.com/sachin-iam/5bcbe15474d187dea173837762d7d326

This ~5,000-line excerpt contains 35 separate "Could not find Origin" occurrences for that one stream (sk_bb423de5...), starting right after the WHIP publish request comes in and continuing until we eventually gave up on that session. For broader context: across our last 4 days of production logs, the exact phrase "Could not find Origin" appears 5,276 times total — this is not a rare edge case for us, it's a frequent recurring failure.

3. Does it reproduce with OBS or OvenLiveKit?

We're actively working on testing both right now:

OvenLiveKit (your demo page): hit a snag — Chrome's Private Network Access policy blocks that public HTTPS page from reaching our localhost/private-IP OME instance at all (Permission was denied for this request to access the loopback address space), independent of anything about our stream. Working around it now (exposing the port temporarily / self-hosting the demo page) and will report back.
OBS: testing in progress, will follow up with a result shortly.
ffmpeg (native WHIP muxer): this is what we've already fully tested end-to-end, both locally (stock/default OME config, zero custom app logic involved) and in production — this is the data we can hand you right now.
Given that we already have (a) the exact ffmpeg command that reproduces a healthy publish, (b) a full raw log excerpt showing 35 consecutive "Could not find Origin" failures for one real production stream, and (c) confirmation this isn't rare for us — 5,276 occurrences of that exact error across just the last 4 days of our logs — we'd really appreciate you starting to dig into the ffmpeg+log evidence in parallel while we finish the OBS/OvenLiveKit tests. We're currently blocked in production on this (live classes intermittently never get playable video), so any early read on what in the Orchestrator/origin-registration path could cause this — even a hypothesis to test against — would help us a lot right now.

[getroot]

The log below means that a playback request came in, but the live/sk_ded5c443 stream doesn't exist on that OME.

[2026-07-31 13:12:42.751] E [SPLLHLS-t8090:45] Orchestrator | orchestrator.cpp:535 | Could not find Origin for the stream: [#default#live/sk_ded5c443...]

This log is printed every time a playback request comes in while the stream isn't ready. In other words, the problem is that the WHIP encoder is failing to create the stream on OME.

From a quick look at the logs, there seem to be a lot of packet reordering / loss issues on the WHIP input side, so it's likely the stream wasn't created. The problem is most likely a network issue between the WHIP client and OME. Testing with WHIP/TCP will likely resolve this issue.