WeatherStar 4000

Playground
,
#142

I tried this. created a new container with that environment variable and ran it. It was running at the correct speed, but kept freezing up and then it got to the point where the lag was over six minutes behind.

Based on what Accustiver said, I tried stopping the containers, starting them, and connecting again, and when I connected it was racing through the time at a high speed, and after about 40 seconds, it froze up completely.

something is caching stale data

When I start and stop, on any device, using any client, it begins playing at the same point in time (same time stamp and same spot in the song). And no I don't mean that they're coordinated, I mean that the VLC player on my Linux laptop will begin playback with the time showing as 10:36:54 AM and I can let it run for a minute, go to my Android phone, open the Televisio app, run the stream, and it also begins at 10:36:54 AM (the time is 10:40 AM)

Something is caching stale data, and the fact that every client on every device wants to begin at the same time, even if it's the first time that device has ever played the stream, leads me to believe that it is not the client software or client device.

The WS4KP webpage always has the current time, so it can't be that.

Is there caching of any kind happening in ws4channels? If so, can you tell me how to turn it off for testing? Maybe it's the Puppeteer headless Chrome program?

Again, thank you for making this program, and all of your help!!

--Tony

#143

Thanks for testing this — that’s actually really useful info. To answer directly: there’s no caching layer in ws4channels no Redis, no proxy, nothing intentionally holding onto old data. What I think is actually happening is that the capture pipeline is freezing outright rather than slowly drifting. Once it stops producing new video segments, every client — regardless of device — just downloads whatever the last file written to disk happens to be, which is exactly why everyone lands on the same identical timestamp. It’s not caching in the traditional sense; it’s that nothing new is being generated at all.

The fact that 5fps didn’t help you (and that it fully froze after ~40 seconds) tells me this might be a different/worse version of the issue than what I originally suspected. I’m working on a build with much better diagnostic logging that should show exactly what’s happening the moment it freezes. Appreciate your patience — I’ll follow up once I have it.

1 Like
#144

08/10/2026 version 2.2 Added attempt to fix rare stream being more than 3 minutes behind and racing to catchup. Updates from netbymatt so that regional maps and radar are drawn full-screen and properly centered on the user's location.

#145

I'm curious about something... I know we can adjust processor and RAM usage, but is there a way to specify a resolution and maximum throughput?

#146

Standard mode should get you 640x480 instead of widescreen 1280x720.

VIEW_MODE=standard
1 Like