I needed the stream URL when casting video — so I built a fake TV

Gtio — Wed, 15 Apr 2026 09:48:24 +0000

I wanted to grab the actual stream URL when casting a video from my phone to the TV. Not to watch it on the TV — I wanted the raw m3u8 link so I could record it with ffmpeg or play it in VLC on my laptop.

Turns out, DLNA casting works by sending the media URL from the phone app to the TV via a standard SOAP request (SetAVTransportURI). The TV then fetches and plays the stream on its own. The phone is just a remote control.

So... what if your computer pretended to be a TV?

The idea

If you advertise a fake UPnP MediaRenderer on the local network, any app that supports DLNA casting (Bilibili, iQiyi, Youku, TikTok, and many more) will happily send you the real stream URL when you hit "cast."

The app can't tell the difference — it's standard protocol, same as talking to a Samsung or Sony TV.

How it works

SSDP multicast on 239.255.255.250:1900 — announce ourselves as a MediaRenderer
UPnP device description — reply with a minimal XML descriptor when queried
SOAP control — the app sends SetAVTransportURI with the actual stream URL. We extract it and we're done.

The whole thing is ~500 lines of Python stdlib. No dependencies.

Usage

pip install wechat-finder-dlna

# Print the captured URL
wechat-finder-dlna

# Record directly with ffmpeg
wechat-finder-dlna --record stream.mp4 --duration 01:00:00

# Pipe to VLC
wechat-finder-dlna | xargs vlc

Or use it as a library:

from wechat_finder_dlna import capture

url = capture(name="Living Room TV")
# url is the raw m3u8/mp4 link — do whatever you want with it

Phone and computer need to be on the same WiFi. That's it.

Why not just use an existing DLNA library?

I looked at a few (like dlnap, macast), but they're full renderers — they actually play the video. I just wanted the URL. So I built the smallest possible MediaRenderer that only implements device discovery and SetAVTransportURI.

Zero external dependencies. Pure stdlib (http.server, socket, threading, xml).

What apps work with this?

Anything that supports DLNA/UPnP casting. I've tested with several Chinese streaming apps (they all use DLNA for casting), but it should work with any app that can cast to a smart TV on your network.

The project is at github.com/gtoxlili/wechat-finder-dlna. Feedback welcome — especially if you've tested it with apps I haven't tried.

I needed resumable LLM streams in Go — so I built streamhub

Gtio — Tue, 14 Apr 2026 17:10:55 +0000

If you've built anything that streams LLM responses over SSE, you've probably hit this: the user refreshes the page, or their network blips, or the load balancer routes the reconnect to a different instance — and the stream is just gone. The generation keeps burning tokens on your backend, but the client sees nothing.

In the JS/TS world this is mostly solved. Vercel shipped resumable-stream, there's ai-resumable-stream, Ably has a whole token streaming product. But if your backend is in Go? Nothing.

I ran into this while working on a project where the LLM worker and the HTTP handler live in different processes. I needed something that:

persists chunks so reconnecting clients can replay what they missed
delivers cancel signals across instances (user clicks "stop" on one node, generation stops on another)
prevents duplicate producers (two requests racing to start the same session)

So I built streamhub.

How it works

Two Redis primitives, that's it:

Redis Streams store chunks. New subscribers read history first, then get live data.
Redis Pub/Sub carries cancel signals. Fast, fire-and-forget.

Each producer gets a generation ID that acts as a fencing token — if a stale producer tries to write after losing ownership, the writes are rejected.

What the code looks like

Producer side:

stream, created, err := hub.Register("chat:123", func() {
    // called when someone cancels this session
})
if !created {
    return // another instance already owns this
}
defer stream.Close()

stream.Publish("hello")
stream.Publish(" world")

Consumer side (can be a completely different process):

stream := hub.Get("chat:123")
chunks, unsubscribe := stream.Subscribe(128)
defer unsubscribe()

for chunk := range chunks {
    // replays existing chunks first, then streams live
    fmt.Fprint(w, chunk)
    w.(http.Flusher).Flush()
}

Cancel from anywhere:

hub.Get("chat:123").Cancel()

Why not just use X?

"Just use Redis Streams directly" — you can, but you'll end up reimplementing subscriber fan-out, replay-then-live handoff, generation fencing, and the cancel side-channel. That's what streamhub is.

"Use Centrifuge/Centrifugo" — great project, but it's a full real-time messaging framework. If all you need is to make your LLM streams durable, it's a lot of surface area.

"Use vercel/resumable-stream" — TypeScript only, tightly coupled to the Vercel AI SDK.

Status

Early days. The API surface might still change. If you're dealing with this same problem in Go, I'd appreciate feedback: github.com/gtoxlili/streamhub

Forem: Gtio

I needed the stream URL when casting video — so I built a fake TV

The idea

How it works

Usage

Why not just use an existing DLNA library?

What apps work with this?

I needed resumable LLM streams in Go — so I built streamhub

How it works

What the code looks like

Why not just use X?

Status