think of it this way: a US company is caught doing business with a company wholly owned by a sanctioned individual. say the us company argued "we weren't doing business with Pavel Sanctionovich, we were doing business with Pavel S. Inc., a UK company that just happens to be owned by Pavel.", would the courts accept that?

it's pretty much guaranteed that the winner will be someone using fable or sol and the budget to let it churn for hours on end.

After getting laid off a while back, I started working on a degree online. It seemed like a good opportunity to spend some time traveling too, so I signed up for Starlink and got a friend to host my Plex server in his basement for the duration. Surely that would be good enough to watch whatever from where-ever.

Turns out that no, it's not. Plex really doesn't like streaming over Starlink. It would top out at 8-9mbps in good conditions, often dropping down to 2 or 3, while other streams and downloads would happily hum along at 100mbps+.

I spent a little time looking into the issue early on. None of the remote or server network changes I could think of made a noticable difference. Customizing Plex's internal MPV configuration to increase the chunk size and buffer limit helped a bit, but it was still too slow to watch anything in realtime.

My best guess was that the problem largely boiled down to a combination of Starlink's fairly frequent latency spikes and Plex's short timeouts. With things at school winding down, I decided to finally put that to the test by building some kind of caching proxy.

Initially the plan was to MITM the client/server connections so it could serve everything out of a cache and set it up to proactively cache things in the background. Once the client and server were talking reliably through the proxy, I realised those features wouldn't really be necessary. All it needed was a bit of parallelism and patience.

With my particular setup, 5 workers can reliably pull down segments at ~35-40mbps, adding another 5 pushes that up to about 60mbps. Either is more than enough to stream anything 1080p in realtime and 60mbps can handle almost anything 4K HDR. Ended up building the prefetching features despite that, because at that point why not?

Fast-forward a few days and I'm willing to call this a Good Enough first version. There are plenty of significant limitations and rough edges. It's almost entirely vibecoded and far from my best work ever. There's enough spaghetti under the hood that I have to actively avoid thinking about it. It works well enough that I don't have to start buffering a TV show 2 hours before I plan to watch it though, and that's what matters.

This is a niche tool for a niche problem. I don't really expect this to be of much use to anyone. It was a fun project though and a satisfying solution to an irritating problem, so thought I'd share it anyway.

Comments URL: https://news.ycombinator.com/item?id=48900786

Points: 2

# Comments: 2

tapping on the muesli vs corn flakes comparison gave me no visual feedback to indicate it was ever going to do anything.

then it died.

when it came back I tried tapping on Visual Studio Code, expecting a page to come up but nothing happened. after enough time to flip back to hn and tap that sentence out (on my phone) and there was a page load happening. another 5s after that, a page with a lot of things on it but very little content appeared.

so a couple thoughts:

if you're going to manage page loads and nav with javascript, visual feedback is not optional. (better yet, don't do it with js at all. you don't have to go full SSR, just let your web server handle more of the effort)

every example you have there is going to boil down to personal preference or context dependence. like corn flakes vs museli, no one is going to make buying decisions based on that. there is no "better" only in that comparison, only "better for my situation". same goes for local businesses, IDEs, and whatever else. these scores don't tell me if it will work for me, only that it's popular. this is why the best review sites these days compare and present the results as "if you prefer X, then consider A. if you're on a budget but want Y, then B is a good choice." people want to know what's best for them. if you've got the data then frame a new users experience around "what are you looking for and what do you care about" rather than this zillionth hot-or-not-with-a-twist clone.

you should take your llm's advice on this one

responses are still usable, no hallucinations or anything, but it's worth keeping in mind if you rely on detailed instructions or large context windows.

When planning small-to-medium sized changes, I found that it was a little bit faster than GPT-5.5 (high) and produced equivalent results. on large changes its results were fine but GPT's were more thoroughly thought through. DS v4 beats the absolute pants off GPT when it comes tone and style though.

... bingo!

Might add support for custom WASM plugins down the road, but everything shipped with the system will be Rust.

I'm all in favour of using AI for development, even for letting AI build the whole thing. Be lazy about it though and it will come back to bite you.

A concurrency framework seems like the wrong thing to be lazy about.