First of all, thank you for doing all of this - I'm sure Prismcast is going to get there and it was working well for me until I taught myself how to update a docker via portainer
Your welcome! It's early days, and evolving. I have a sense of how to address the issue you're encountering, and knowing 1.2.1 worked reliably is a significant help...the next release of PrismCast should provide you with a better experience again.
Your system should be fine in general.
I do not run, support, nor optimize for, containerized environments...I leave that to others so I can't help on those fronts.
I am seeing something strange that someone may have mentioned earlier, when I use the cDVR "show stats" feature, the Prismcast 1.3.2. stream indicates > 60.0 MiB, but the ADBTuner stream of the same channel is only indicating ~10 MiB - if MiB = megabits/s then is something causing the video to get reencoded at a high bitrate?
(I have a 10Gb network interface to the unraid server and most of my clients are on wired ethernet plugged into a 2.5Gb switch - but clients are limited to 100Mb or 1Gb and are OTG clients probably even less)
EDIT: nevermind, sorry, that was the size, there is a bitrate indicated in the info and it seems OK
I am seeing something strange that someone may have mentioned earlier, when I use the cDVR "show stats" feature, the Prismcast 1.3.2. stream indicates > 60.0 MiB, but the ADBTuner stream of the same channel is only indicating ~10 MiB - if MiB = megabits/s then is something causing the video to get reencoded at a high bitrate?
I’m going to leave Channels DVR’s reported stats to you to interpret. PrismCast focuses on generating the stream, and how Channels displays those details is outside its scope.
PrismCast can’t do what you’re describing. There isn’t an “original resolution” mode — it’s capturing and encoding a rendered browser window, so the output is inherently constrained by the display environment and will not match a native broadcast stream.
Tools like PrismCast (and CC4C, which inspired it) aim to produce something usable and pretty good quality, but they won’t deliver true 4K video or 5.1 audio.
PrismCast targets 720p by default because it provides a good balance for most use cases. To achieve that, it needs a display (physical or virtual) with enough resolution headroom. For example:
A 1080p display can accommodate 720p capture
A 720p display typically limits capture to 480p
This is because the browser window includes UI elements and needs additional screen space beyond the video frame itself.
On an older MacBook Pro with a lower-resolution display, PrismCast may only allow 480p because there isn’t enough usable screen real estate.
Capturing at higher resolutions (e.g., 4K) would require a significantly larger display or virtual display, and generally isn’t recommended due to the performance overhead.
is the url i used for the manual channel add
was a bit funky getting it login etc BUT it seems to be working You may need to use the Watch live URL after you login as it may be different etc
Is it me or am I getting constant crashes with the new version?
Logs
Navigate to this URL:
http://prismcast:6080/vnc.html?host=prismcast&port=6080
Press Ctrl-C to exit
[2026/02/16 03:53:15.913] Using FFmpeg at: /usr/local/lib/node_modules/prismcast/node_modules/ffmpeg-for-homebridge/ffmpeg
[2026/02/16 03:53:15.918] Loaded 307 channels (14 user, 293 predefined).
[2026/02/16 03:53:17.108] [WARN] Display supports maximum 1920×939. Configured 1080p preset will use 720p-high instead.
[2026/02/16 03:53:17.109] Chrome ready: Chrome/145.0.7632.75.
Starting PrismCast with noVNC support...
Display: :99
Screen: 1920x1080x24
VNC Port: 5900
noVNC Port: 6080
PrismCast Port: 5589
Starting Xvfb...
Xvfb started successfully.
Starting x11vnc...
Xlib: extension "DPMS" missing on display ":99".
0
The VNC desktop is: prismcast:0
x11vnc started successfully.
Starting noVNC...
Warning: could not find self.pem
Using installed websockify at /usr/bin/websockify
Starting webserver and WebSockets proxy on port 6080
WebSocket server settings:
- Listen on :6080
- Web server. Web root: /usr/share/novnc
- No SSL/TLS support (no cert file)
- proxying from :6080 to localhost:5900
noVNC started successfully.
==============================================
noVNC available at: http://localhost:6080/vnc.html
PrismCast UI at: http://localhost:5589
==============================================
Starting PrismCast...
Navigate to this URL:
http://prismcast:6080/vnc.html?host=prismcast&port=6080
Press Ctrl-C to exit
[2026/02/16 03:53:30.318] Using FFmpeg at: /usr/local/lib/node_modules/prismcast/node_modules/ffmpeg-for-homebridge/ffmpeg
[2026/02/16 03:53:30.322] Loaded 307 channels (14 user, 293 predefined).
[2026/02/16 03:53:31.175] [WARN] Display supports maximum 1920×939. Configured 1080p preset will use 720p-high instead.
[2026/02/16 03:53:31.176] Chrome ready: Chrome/145.0.7632.75.
Starting PrismCast with noVNC support...
Display: :99
Screen: 1920x1080x24
VNC Port: 5900
noVNC Port: 6080
PrismCast Port: 5589
Starting Xvfb...
Xvfb started successfully.
Starting x11vnc...
Xlib: extension "DPMS" missing on display ":99".
0
The VNC desktop is: prismcast:0
x11vnc started successfully.
Starting noVNC...
Warning: could not find self.pem
Using installed websockify at /usr/bin/websockify
Starting webserver and WebSockets proxy on port 6080
WebSocket server settings:
- Listen on :6080
- Web server. Web root: /usr/share/novnc
- No SSL/TLS support (no cert file)
- proxying from :6080 to localhost:5900
noVNC started successfully.
==============================================
noVNC available at: http://localhost:6080/vnc.html
PrismCast UI at: http://localhost:5589
==============================================
Starting PrismCast...
Navigate to this URL:
http://prismcast:6080/vnc.html?host=prismcast&port=6080
Press Ctrl-C to exit
[2026/02/16 03:53:42.461] Using FFmpeg at: /usr/local/lib/node_modules/prismcast/node_modules/ffmpeg-for-homebridge/ffmpeg
[2026/02/16 03:53:42.466] Loaded 307 channels (14 user, 293 predefined).
[2026/02/16 03:53:43.451] [WARN] Display supports maximum 1920×939. Configured 1080p preset will use 720p-high instead.
[2026/02/16 03:53:43.451] Chrome ready: Chrome/145.0.7632.75.
I saw that too. I had to stop the stack, and delete the prismcast_data volume. If you have configuration you care about, you may want grab the JSON files from the volume before you delete it.
This used to happen with CC4C occasionally as well, and the fix was to break-up the persistent data into multiple volumes -- and not store any of the temporary Chrome data in a bound directory or volume.
I'll chat with @hjd about potentially making a change along those lines...
@hjd We may be seeing a problem with storing all Chrome data in a persistent Docker volume. Based on previous experiences with CC4C, there's certain temporary Chrome data, that is best not maintained in this manner.
In the case of CC4C, we moved to the approach below for maintaining Chrome data -- with the idea of keeping login data, and a few other things that made sense to keep as persistent. Temporary and cache files, would not be kept between spin-ups.
A Docker Compose snippet of the structure looked like this:
volumes:
- cookies:/home/chrome/chromedata/Default/Cookies # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome cookie data.
- logins:/home/chrome/chromedata/Default/Login Data # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome user login data.
- localstorage:/home/chrome/chromedata/Default/Local Storage # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome user local data.
- prefs:/home/chrome/chromedata/Default/Preferences # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome user preferences data.
- secure:/home/chrome/chromedata/Default/Secure Preferences # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome user secure data.
restart: unless-stopped
volumes:
cookies:
logins:
localstorage:
prefs:
secure:
I'd propose we do something similar, with appropriate adjustments to the container-side paths, and the addition of persistent storage for the PrismCast config files. I can submit a PR to cover this if you like.
@hjd We may be seeing a problem with storing all Chrome data in a persistent Docker volume. Based on previous experiences with CC4C, there's certain temporary Chrome data, that is best not maintained in this manner.
In the case of CC4C, we moved to the approach below for maintaining Chrome data -- with the idea of keeping login data, and a few other things that made sense to keep as persistent. Temporary and cache files, would not be kept between spin-ups.
I’m open to trying that. I’d still like to understand — and ideally address — the underlying cause, since this feels more like a workaround than a root fix. That said, Docker behavior is more your wheelhouse than mine, so I’m interested in your take. I loathe hacks/workarounds unless they're essential, in general...but I loathe not having working software more.
I’ve been having this same exact problem as well ever since upgrading from 1.2.1 to 1.3.1 and 1.3.2. I’m running mine on Windows 11 Pro with an Intel Core i5-4440 processor at 3.10GHz with 4 cores and 4 logical processors and 16GB RAM. Everything was working fine on version 1.2.1. Thanks again for all your hard work on this!
yep. @nriley that is the big diff here - everything else browser-based is windows first, and it's gotten tiring.
I'll still keep an encoder going for some more niche providers, but when i can set up a prism-only playlist, and multiview off of it easily, and it works, it has already grown into a favorite.
PrismCast working great here. Congrats and thanks for the effort. Tennis Channel also working fine (Brightcove profile). In my setting, when I stop watching a channel, PrismCast server takes around 40 seconds to cancel the stream and close the Chrome session. Is this by design or should I adjust any env settings?
Thanks for the response - makes sense. This older intel MacBook Pro is running in clamshell mode and I use VNC to access it - so I just upped the display resolution and now i can configure 1080p. My main recording use case is the ESPN channels since Disney is evil and removed them from TVE. They broadcast everything in 720p - so I've set the resolution to 720p High in the Prismcast settings and it is capturing that resolution now. i guess not technically native since I am sure Chrome fiddles with it - but looks really good to my eye.
I tried it natively in Win 11as a service BUT It had problems with stuttering freezing etc plus getting Chromento open for authentication stopped working.... I went back to Docker BUT figured natice would be best. I'm running an I5 6 core with 48gig ram and 250 ssd Iit ran CC4c ok BUT maybe this is a heavier load
Massive thank you to @hjd for this project. Very impressive! I apologize if I missed this in the many posts before this (I did search for "speed"), but is there a way with YouTube TV to tune quicker? With Chrome Capture, I tune to a channel in about 4-5 seconds, and this is perhaps double that, so I'm wondering if I am doing something wrong. I have this and Channels running on an M1 Mac Mini.
PrismCast working great here. Congrats and thanks for the effort. Tennis Channel also working fine (Brightcove profile). In my setting, when I stop watching a channel, PrismCast server takes around 40 seconds to cancel the stream and close the Chrome session. Is this by design or should I adjust any env settings?
That's correct behavior, by design. It exists in case you're channel surfing and decide to come back. Streams end 60 seconds after the last client disconnects.
