Introducing PrismCast: Browser-based Live TV Capture for Channels DVR and Plex

patrick4vt · September 27, 2026, 11:42pm

I'm assuming you're running Prismcast directly on your system and not via Docker then? I'll have to test rolling back Prismcast to an earlier version. Not sure how to just roll back chrome on the docker setup.

hofs1 · September 27, 2026, 11:56pm

Yes I run Channels DVR and Prismcast on a dedicated mini I5 HP Prismcast is up to latest 1.13 it was Chrome that is the problem

patrick4vt · September 28, 2026, 12:12pm

Since I'm running the docker version of this, I rolled back to v1.12.1. This fixed the full screen issue. I'm guessing v1.13.0 has the latest version of Chrome on it, I didn't check before rolling back.

dlinvill · September 28, 2026, 9:46pm

I was able to get this working in a Windows 11 VM with intel gpu passthrough on proxmox. On the first try I was getting video but no sound. After some troubleshooting the issue was chrome audio failing due to missing invariant Time Stamp Counter (TSC) on my proxmox host cpu config.

Adding a custom cpu type in /etc/pve/virtual-guest/cpu-models.conf containing:

cpu-model: prismcast-host-invtsc
flags +invtsc
phys-bits host
reported-model host

fixed the missing sound.

EnigmaPBS · September 29, 2026, 2:34pm

Is there a profile/configuration available for Verizon FIOS?

chDVRuser · September 29, 2026, 4:47pm

Agreed. I'm still running PrismCast 1.12.1 and Chrome just updated from v153 to v154 this morning and now I'm seeing letterboxed playback on all Chrome capture channels, but not on native HLS channels.
Updating to PrismCast v1.13.0 did NOT fix it.

Jim_FL · September 29, 2026, 5:18pm

Agreed. Seeing same here.

chDVRuser · September 30, 2026, 3:08am

Not preconfigured

Checkbin · September 30, 2026, 11:01am

I was wondering the same thing. I tried created a custom channel for Verizon FIOS but couldn’t get it to work. Has anyone gotten it to work with FIOS with custom channels?

KineticMan · September 30, 2026, 8:25pm

I looked into it. I think it's a bug in a newer version - not Chrome related. It is not present in v1.1

github.com/hjdhjd/prismcast

1.12.1: capture viewport drops from the preset surface to the Chrome window size ~1s after tune, letterboxing the capture (site-independent repro)

opened 08:05PM - 30 Sep 26 UTC

kineticman

### PrismCast Version v1.12.1 (from the `ghcr.io/hjdhjd/prismcast:1.13.0` image… — see note at the bottom) ### Platform and OS Docker on Ubuntu 24.04.4 LTS, x86_64 ### Node Version v22.23.3 (in the container) ### Chrome Version 154.0.8037.57 (bundled in the image) ### Affected Channel (if applicable) Site-independent — reproduces with a plain local page containing only a `<video>` element. ### Describe the problem ## Summary In 1.12.1 the capture page's viewport starts at the preset's emulated surface (1280x720), then about 1 second after tune it resizes to the real Chrome window size. PrismCast's CSS styling then fills that window-sized viewport, and the capture scales the whole viewport into the 1280x720 output. The result is a small, pillarboxed and letterboxed picture in the middle of a black frame. Nothing is logged: no warning, and no recovery is triggered. The same page on 1.11.0 captures full-frame. ## Reproducer (no streaming site, no login) ```bash mkdir plain && cd plain ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -f lavfi -i sine -t 120 \ -c:v libx264 -pix_fmt yuv420p -c:a aac -movflags +faststart t.mp4 cat > index.html <<'EOF' <!doctype html><html><head><style>html,body{margin:0;background:#000;height:100%}video{width:100vw;height:100vh}</style></head> <body><video src="t.mp4" autoplay muted loop playsinline></video> <script> const log=(e)=>fetch('/log?'+encodeURIComponent(e+' '+innerWidth+'x'+innerHeight+' '+document.visibilityState),{method:'POST'}); log('init');addEventListener('resize',()=>log('resize'));setInterval(()=>log('hb'),5000); </script></body></html> EOF # any static server that also logs POSTs, e.g. a tiny Python http.server subclass on :8765 ``` Tune it: ``` http://<prismcast>:5589/play?url=http%3A%2F%2F127.0.0.1%3A8765%2Findex.html&profile=keyboardFullscreen ``` What the page reports (innerWidth x innerHeight): ``` 16:02:16 init 1280x720 visible 16:02:16 resize 945x971 visible <- about 1s after load 16:02:21 hb 945x971 visible ``` 945x971 is the Chrome window's own size in a fresh container. The captured 1280x720 frame shows the page scaled down to fit (about 700x720), with the 16:9 video letterboxed inside that. So the visible picture is about 700x394, centered in black. I first hit this through FastChannels, which bridges DRM channels to PrismCast by pointing `/play?url=` at its own player page. A user reported it there as "briefly full screen, then reduces down to a windowed view" (kineticman/FastChannels#67). Their Docker install shows the same behavior, so it isn't specific to my environment. ## Things I checked - **The page isn't the cause.** The plain page above has no fullscreen code and nothing that resizes; the resize comes from outside the page. - **Native fullscreen can't compensate.** `keyboardFullscreen` no longer carries `fullscreenKey` (fabef09). I also tried `clickToPlayKeyboard`, whose click gives the page real user activation (`navigator.userActivation.isActive === true`). The page's own `document.documentElement.requestFullscreen()` is then rejected with `not granted`, presumably because the capture tab is in the background now. - **`keyboardIframe` isn't a workaround for a page without frames.** It is the one built-in profile that still sends `f`, but setup fails with ``Waiting for selector `iframe` failed``. - **1.11.0 works.** The same page and FastChannels' page capture full-frame on 1.11.0, where `keyboardFullscreen` presses `f` and the page goes native fullscreen. It looks like the device-metrics override (`declareSurface` / `reaffirmCaptureSurface`) is being dropped or superseded shortly after the capture starts. Maybe that happens when the capture start selects the tab and then returns to the previously selected tab, but I haven't traced it further than that. ## Side note: 1.13.0 image contains 1.12.1 `ghcr.io/hjdhjd/prismcast:1.13.0` (created 2026-09-26) has `"version": "1.12.1"` in `/usr/lib/node_modules/prismcast/package.json`. At startup it logs `Starting PrismCast v1.12.1` and `Update available: v1.13.0 (current: v1.12.1)`. The FastChannels reporter saw the same thing after pinning the `1.13.0` tag. ### PrismCast Configuration ```json Default configuration (fresh volume), with container env: PORT=5590, VNC_PORT=5901, NOVNC_PORT=6081, DISPLAY_NUM=98, SCREEN_WIDTH=1920, SCREEN_HEIGHT=1080, SCREEN_DEPTH=24, HDHR_ENABLED=false ``` ### PrismCast Log Output ```shell [2026/09/30 07:53:18.761 PM] Starting PrismCast v1.12.1 with configuration: [2026/09/30 07:53:21.082 PM] Chrome ready: Chrome/154.0.8037.57 (GPU: llvmpipe (LLVM 19.1.7 256 bits)). [2026/09/30 07:53:24.695 PM] Update available: v1.13.0 (current: v1.12.1). [2026/09/30 08:02:18.484 PM] [127.0.0.1-lllkwj] Streaming http://127.0.0.1:8765/index.html: 127.0.0.1, keyboardFullscreen, FFmpeg [H264]. Tuned in 2.1s (direct). (no warnings or recovery messages for the plain-page stream; the viewport change is silent) ``` ### Acknowledgment - [x] I have read the documentation and searched existing issues before creating this support request.

chDVRuser · September 30, 2026, 10:54pm

Could be, but the update in Chrome from v153 to v154 is what triggered the letterboxing to start in PrismCast v1.12.1.

Did you mean v1.11?
Wish there was a way to downgrade the version using brew on macOS.

KineticMan · September 30, 2026, 11:49pm

yea probably 1.11

you can't downgrade? thats wild.

chDVRuser · September 30, 2026, 11:54pm

Not when using "The recommended way to install PrismCast on macOS"
https://github.com/hjdhjd/prismcast#homebrew-macos

KineticMan · October 1, 2026, 12:58am

you are right btw - looks like it's a combination of Chrome 154 AND the new version of Prism.

1.11.1 with 154 works if you can find a way to downgrade.

chDVRuser · October 1, 2026, 1:14am

Maybe @hjd will come up with a way to downgrade using homebrew.
This is the third time it would have been useful.

jagrim · October 1, 2026, 1:15am

Still on v 1.1.11 with Chrome 153

chDVRuser · October 1, 2026, 1:40am

Something in the PrismCast log (with debugging enabled) I don't know if it's new. All my captured channels are showing this now.

[DEBUG:browser:video] [awe-t3nqek] Fullscreen verification failed (attempt 1/3). Retrying after 500ms.
[DEBUG:browser:video] [awe-t3nqek] Fullscreen verification failed (attempt 2/3). Retrying after 500ms.
[WARN] [awe-t3nqek] Fullscreen failed after 3 attempts. Escalating to aggressive fullscreen.
[DEBUG:browser:video] [awe-t3nqek] Fullscreen succeeded after aggressive techniques.

[2026/09/30 06:34:15.660 PM] [DEBUG:browser:lifecycle] [awe-t3nqek] The window reported its restore complete after 0ms (1 reads).
[2026/09/30 06:34:15.703 PM] [DEBUG:browser:lifecycle] [awe-t3nqek] Emulated the capture surface at 1920x1080 with a pixel density of 1.
[2026/09/30 06:34:15.735 PM] [DEBUG:timing:startup] [awe-t3nqek] Capture acquired in 30ms.
[2026/09/30 06:34:15.739 PM] [DEBUG:native:intercept] [awe-t3nqek] HLS playlist observer installed.
[2026/09/30 06:34:16.489 PM] [DEBUG:native:intercept] [awe-t3nqek] Channel selection epoch stamped at wire sequence 0.
[2026/09/30 06:34:16.493 PM] [DEBUG:timing:tune] [awe-t3nqek] Video context found. (+4ms)
[2026/09/30 06:34:16.538 PM] [DEBUG:browser:video] [awe-t3nqek] Video state after scroll: readyState=0, paused=true, muted=true, 0x0, src=none.
[2026/09/30 06:34:17.306 PM] [DEBUG:timing:tune] [awe-t3nqek] Video ready. (+817ms)
[2026/09/30 06:34:17.510 PM] [DEBUG:browser:video] [awe-t3nqek] Fullscreen verification failed (attempt 1/3). Retrying after 500ms.
[2026/09/30 06:34:18.211 PM] [DEBUG:browser:video] [awe-t3nqek] Fullscreen verification failed (attempt 2/3). Retrying after 500ms.
[2026/09/30 06:34:18.914 PM] [WARN] [awe-t3nqek] Fullscreen failed after 3 attempts. Escalating to aggressive fullscreen.
[2026/09/30 06:34:19.117 PM] [DEBUG:browser:video] [awe-t3nqek] Fullscreen succeeded after aggressive techniques.
[2026/09/30 06:34:19.117 PM] [DEBUG:timing:tune] [awe-t3nqek] Playback ensured. (+2628ms)
[2026/09/30 06:34:19.118 PM] [DEBUG:browser:lifecycle] [awe-t3nqek] The window reported its restore complete after 0ms (1 reads).
[2026/09/30 06:34:19.118 PM] [DEBUG:timing:startup] [awe-t3nqek] Page with capture ready. Total: 3460ms.
[2026/09/30 06:34:19.119 PM] [DEBUG:native:coordinator] [awe-t3nqek] Attempting native streaming for awe.
[2026/09/30 06:34:20.620 PM] [DEBUG:native:intercept] [awe-t3nqek] Interception finalized in 4883ms but no HLS playlist was captured.
[2026/09/30 06:34:20.620 PM] [DEBUG:native:coordinator] [awe-t3nqek] No manifest intercepted for awe in 1501ms. Falling back to capture.
[2026/09/30 06:34:20.621 PM] [awe-t3nqek] Streaming AWE: YouTube TV, youtubeTV, FFmpeg [⚡ H264]. Tuned in 3.5s (direct).

Jim_FL · October 1, 2026, 1:57am

I downgraded on Win 11 PC---npm install -g [email protected]. Fixed letterboxed image.

dfrap · October 1, 2026, 6:26pm

Thank you! This fixed my 'wife acceptance' issue with PrismCast. I find it runs quite acceptably on an N100 minipc, but I couldn't switch if the recordings did not fill the screen.

jator · October 1, 2026, 8:23pm

Running in a Linux docker and chrome is still on v 1.52 and I'm running v1.12.1 of PrismCast. Did an AI search on how to prevent chrome from updating in the docker until I am ready to once a fix is in place and was given these instructions. Others know better than I, but if you are on Linux Docker and not yet experienced this, may want to consider doing this inside the docker bash:

apt-mark hold google-chrome-stable

And of course, don't update your docker until a fix has been confirmed.