Yup when i did it i thought i needed to do so for it to work BUT seems just fine with no change and the cmd windows shows the error
I just looked at doing that, but there are actually multiple commands used that don't work in Windows environments. Several have to do with "refreshing" Chrome itself, to keep it healthy. pkill appears to be the only one you're seeing, but others are likely failing behind the scenes.
It can be done of course, but it's not a straight swap one command for another to achieve the same functionality.
I have been running prismcast on my M2 Mac Mini for a couple weeks, with mostly positive results. I really only want to use it to view sports on ESPN channels. I have not had any issues watching games live on those channels over the past few weeks. But yesterday (after I had just upgraded to 1.5.2) I attempted to record a MLB game in the afternoon. Around 2hrs 37min into the recording, when the stream goes to a commercial break, the video is frozen at the end of the commercial. The rest of the game had the actual audio playing from the game but with a static image on the screen of the commercial. Anything I should attempt to try to prevent this from happening again?
It’s going to happen from time to time. This isn’t a PrismCast issue per se…it’s a Chrome, site-specific, and network issue…and a bit of a Channels DVR issue. The issues occur because “something” happens to the video stream…that something can be:
- Chrome misbehaving.
- The site you’re using for ESPN flakes out or has an issue.
- Network/Internet connectivity hiccup.
- System isn’t able to keep up with what’s going on (e.g. you’re trying to stream a bunch of things or running an LLM simultaneously on your machine or whatever…). That’s going to cause issues as well.
PrismCast tries it’s best to detect and recover from these situations…Chrome becomes “less reliable” shall we say, after a few hours…so PrismCast restarts it on a regular basis to keep it performant.
When sites flake out or network issues occur…PrismCast tries to detect those as well and self-heal, informing Channels DVR along the way. Works 80-90% of the time these days. If PrismCast triggers its recovery logic too aggressively, you’ll have streams always restarting with just modest streaming delays. It’s a balancing act.
One thing you can try: use a different site for ESPN…the different sites (ESPN.com vs D+ vs Hulu etc) all have different characteristics and some may work better for you than others. There’s no rhyme or reason necessarily…it’s very dependent on your own circumstances.
TL;DR: there is no magic bullet. Unlikely to be version-dependent, but open to the possibility that it is…but since the only changes between 1.5.1 and 1.5.2 were adding some more Spectrum channels, seems less likely. 
(unless it was a different version you were upgrading from).
Ensuring that streaming is always as reliable as it can be is a major focus area for me…trying to make PrismCast more bulletproof in imperfect conditions is a major reason why I created it. Appreciate the feedback, as always…hope the context helps folks understand a bit more of what’s going on.
Oddly enough, it was a Spectrum commercial that caused it to freeze up. I've got an hour and a half of guys talking about baseball while the words "Spectrum Business" are on the screen.
I just looked at doing that, but there are actually multiple commands used that don't work in Windows environments. Several have to do with "refreshing" Chrome itself, to keep it healthy. pkill appears to be the only one you're seeing, but others are likely failing behind the scenes.
It can be done of course, but it's not a straight swap one command for another to achieve the same functionality.
This is already on my radar and slated to be addressed more holistically in an upcoming release…appreciate folks raising it.
Just out of curiosity, I really wanted to use Prismcast, but was unable to because I was experiencing stuttering under Docker on Unraid. Do you know if that is planned to be looked into or addressed in the future? If not, it's okay. I'm just curious. Also, I'm curious if there's anything I can do on my system to mitigate such stuttering. I know others have experienced it, I just am curious if there are any workarounds anyone's found, or any potential ways I can help debug. I'm asking more or less if I can contribute in any way with my system. I always like to find ways to give back when I can.
You could try upping shm_size to 2gb.
Otherwise, what are the specs on your Unraid host?
I'm running an i7-12700K and 128GB of DDR4. My Docker containers all run off a Samsung, I believe a 980 Pro SSD.
Getting inconsistent results with the Providers API /providers/yttv/channels?refresh=true
It's not returning all the channels that appear on the YTTV Live Guide and returns a different amount each time it runs.
Maybe it needs to wait for the page to fully load?
In particular it's missing these channels that are in the YTTV Live Guide
ESPN in 4K
FOX Sports Plus 4K
NBA TV in 4K
NBC Sports Bay Area Plus
NBC Sports California Plus
That hardware should be quite adequate. Although I primarily use a Mac Mini M4 for PrismCast (as I don't use it for much else), the container testing I've done has been on a 12th gen i3 running Docker in a Proxmox LXC -- and I haven't seen any stuttering.
Definitely try upping the shared memory setting, and there are others you could potentially play around with to allocate more resources to a container, but those would be changes that would apply just to you.
A chatbot could likely guide you through possibilities. Maybe other Unraid users as well, for ways to deal with containers that require significant resources in Unraid environments?
It has full access to the entire pool of memory and the entire CPU, all cores.
Maybe I'm comparing it to the LinkPi encoder output a little bit too much. And this is browser capture, so that could be what I'm seeing. And it's perfectly normal, possibly.
Stuttering? No -- not normal. There are numerous people using this project successfully on hardware platforms with lower specs than yours.
Maybe I'm comparing it to the LinkPi encoder output a little bit too much. And this is browser capture, so that could be what I'm seeing. And it's perfectly normal, possibly.
Stuttering isn’t normal. Would be helpful for me if you could post a real example BTW, so I can take a closer look. I, in general, have no plans to directly dive into Docker-specific challenges. If you want the best experience, I would encourage you to run PrismCast natively on macOS. It’s going to have the best performance characteristics - both due to Apple Silicon being quite capable for this sort of thing, and the ability for Chrome to use hardware acceleration.
Anecdotally - I would say that issues like you’re describing inevitably point toward resource issues - be that CPU or memory. @bnhf is the official PrismCast on Docker expert, not I though. You might want to run an experiment for yourself and simply shut everything you can down on the machine and substantially over-resource PrismCast and see what happens. If it works well, you can start to methodically adjust the variables until you discover a sweet spot, perhaps.
This is unrelated to shm_size though. Docker sets it by default at something like 64MB, we set it to 1gb in the compose, but 2gb is better for systems that need it. Have you tried making that change?
Thanks. You know, I do have an M1 Mac Mini lying around.
I was using it as an iMessage server but I've since moved that off to a VPS using a reverse engineering project that I helped contribute quite a bit of code to and am now spending a lot of time maintaining. That a whole different story though. So the M1 Mac Mini is kind of freed up now, so I might end up using that for PrismCast perhaps.
Although, you're right, hardware acceleration is definitely beneficial for this, so it might be fruitless to try to troubleshoot this in Docker, considering all the other things I have running on my server at the same time. I also wonder if there are issues with the Docker engine on Unraid right now, given the issues I reported with the Channels DVR docker container and my Nvidia Shield devices that was not reproducible under a Windows VM on Unraid. Essentially after a packet capture I observed reset storms and dropped connections that were just easily reproducible for some reason with the Shield and and docker on Unraid but not a Windows VM on Unraid and the Shield-- or an Apple TV and Unraid docker, super weird head-scratcher stuff that makes me think something else is up. I also run 2 Unraid servers so it's not like it's a specific server acting funky, both behaved the same way. I even bought a different network controller to test.
I also kind of invested hundreds of dollars in a LinkPi and Osprey set up with six tuners, so it might not be worth it to configure something else given my financial investment in the encoders and Android boxes. I just wanted to spin up PrismCast to tinker!
Although, I'm really glad I was able to help contribute that channel list for others. I really do like the community here, so anything I can do to help out, I always try to. 
Please let me know if I can an be of any assistance, in this case I'm more likely to blame Lime Tech than anything else given the Shield issues that I isolated to Unraid docker. I even built my own custom (and now published) Docker container for Channels to confirm it wasn't the Fancy Bits container.
Yes I changed that as well. I honestly think something is weird with the docker engine in Unraid 7 or TCP/IP stack.
Just curious if this stuttering is happening when you are trying to capture at 1080? I run in a docker with an i5-10400 and when I capture at 720 high it’s fine but if I bump it up to 1080 high I get what I call super micro stuttering. Hard to explain it. Even at 1080 high it’s only using about 15-20% CPU. It feels less like a resource thing than a chrome thing. @bnhf is the container using chrome or chromium?
It's exactly that micro stuttering at 1080p high which my hardware should totally be able to handle but clearly there's something causing it to struggle.
Just wanted to report this YouTube TV (auto) problem (using v1.52). I have it working now.
Yesterday I deleted all my custom new and overridden channels, set my Provider to FoxOne and YTTV and assigned all channels to YTTV. I then deleted all channels I don't receive and went through the rest of the predefined channels to set them up.
With the Paramount channel using the default profile YouTube TV (auto), it kept failing like it couldn't find the channel selector Paramount, even though it's there. I could see it repeatedly opening a browser tab to the live guide and then closing the tab.
Once I edited the channel to change the profile to youtubeTV, it started working.
[2026/03/02 16:05:35.749] Provider filter updated: foxcom, yttv.
[2026/03/02 16:14:48.736] Bulk assign to 'yttv': 138 of 212 channels affected.
[2026/03/03 00:09:17.066] [ERROR] [paramountp-qwntnh] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 00:09:17.067] GET /hls/paramountp/stream.m3u8 from 192.168.1.4 responded 500 in 12461.358 ms.
[2026/03/03 00:09:27.328] [oxygenp-22drc0] Stream ended after 1m 2s.
[2026/03/03 00:09:29.634] [ERROR] [paramountp-40qf1y] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 00:09:29.636] GET /hls/paramountp/stream.m3u8 from 192.168.1.4 responded 500 in 12466.586 ms.
[2026/03/03 00:09:46.154] [ERROR] [paramountp-1ks3p7] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 00:09:46.295] GET /hls/paramountp/stream.m3u8 from 192.168.1.4 responded 500 in 1006.061 ms.
[2026/03/03 00:10:02.402] [ERROR] [paramountp-5y4vuh] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 00:10:02.429] GET /hls/paramountp/stream.m3u8 from 192.168.1.4 responded 500 in 803.294 ms.
[2026/03/03 00:10:16.660] [ERROR] [paramountp-3ffml0] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 00:10:16.663] GET /hls/paramountp/stream.m3u8 from 192.168.1.4 responded 500 in 12640.424 ms.
[2026/03/03 00:12:12.378] User channel 'paramountp' updated.
[2026/03/03 00:12:33.032] [paramountp-jzt1aq] Streaming Paramount (Pacific) (youtubeTV, FFmpeg). Tuned in 2.5s (direct).
[2026/03/03 00:13:57.352] [paramountp-jzt1aq] Stream ended after 1m 27s.
Thinking it may have been a fluke, today I changed the Profile back to Autodetect and it failed again.
[2026/03/03 17:47:12.698] Provider for Paramount (Pacific) changed to YouTube TV.
[2026/03/03 17:49:53.677] [ERROR] [paramountp-vykjcu] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 17:49:53.677] GET /hls/paramountp/stream.m3u8 from 192.168.1.8 responded 500 in 14405.254 ms.
[2026/03/03 17:50:08.276] [ERROR] [paramountp-7nmif7] Stream setup failed for https://tv.youtube.com/live: Waiting failed: 11000ms exceeded.
[2026/03/03 17:50:08.277] GET /hls/paramountp/stream.m3u8 from 192.168.1.8 responded 500 in 14548.647 ms.
Let me know if there's anything else you want me to try to make it work.