Correct - I solved this in my headless setup with a headless HDMI dongle and just setting the resolution to anything larger than 1080p (1920x1080). That’s fixed the issue.
Except this isn't actually true. It can be larger or smaller. Just the container playing the video needs to have a 16:9 aspect ratio not the actual browser window like it is now.
Not my experience based on the current release of CC4C…but hey, whatever works. Would love to have a rock solid long-term solution without needing some of the shenanigans like headless HDMI dongles.
@Anvil_DVR, So, Chrome updated on my CC4C machine, from 114.0.5735.248 to 115.0.5790.110, and things went wonky. I experienced the issue that you are seeing, the Chrome window opens on my CC4C machine, but Channels never plays the stream. I started a recording directly from the guide, and it seemed to record, but watching the recording was hit or miss. Something strange going on.
Fortunately, I had just made a system image of the CC4C machine, so I rolled it back, and disabled Chrome updates. All good again, for now.
Anyone else on Windows with Chrome version 115+, and CC4C is still working for you?
At least it's not just me.
One odd thing, if I drag the window around and resize it. It will sometimes catch and start working.
There is definitely a problem with Chrome 115+ and talking to Channels. I just upgraded Chrome to test this out and immediately got the same issues.
Here are a couple of logs from some tests...
2023/07/26 09:27:48.713147 [TNR] Opened connection to M3U-ChromeCaptureforChannels for ch9200 Windy
2023/07/26 09:27:48.717563 [HLS] Starting live stream for channel 9200 from 10.255.1.227
2023/07/26 09:27:50.478347 [HLS] Probed live stream in 1.7607845s: h264 1920x1080 progressive 7388953bps
2023/07/26 09:27:50.488381 [HLS] ffmpeg: chrome-Windy: [matroska,webm @ 00000000025f2800] Length 6 indicated by an EBML number's first byte 0x06 at pos 1526249 (0x1749e9) exceeds max length 4.
2023/07/26 09:27:50.488381 [HLS] ffmpeg: chrome-Windy: [matroska,webm @ 00000000025f2800] Seek to desired resync point failed. Seeking to earliest point available instead.
2023/07/26 09:28:12.865313 [HLS] Couldn't generate stream playlist for ch9200-dM3U-ChromeCaptureforChannels-ip10.255.1.227: Timeout waiting for session to start after 12s
2023/07/26 09:28:12.865313 [HLS] Stopping transcoder session ch9200-dM3U-ChromeCaptureforChannels-ip10.255.1.227 (out: 0s, finished: false, first_seq: 0, last_seq: -1)
2023/07/26 09:28:12.865878 [TNR] Closed connection to M3U-ChromeCaptureforChannels for ch9200 Windy
2023/07/26 09:29:17.242425 [HTTP] | 302 | 0s | 10.255.1.227 | GET "/devices/M3U-ChromeCaptureforChannels/channels/9206/hls?codec=copy&format=copy"
2023/07/26 09:29:17.260215 [TNR] Opened connection to M3U-ChromeCaptureforChannels for ch9206 CNBC
2023/07/26 09:29:17.264569 [HLS] Starting live stream for channel 9206 from 10.255.1.227
2023/07/26 09:29:18.841521 [HLS] Probed live stream in 1.5769511s: h264 1920x1080 progressive 1504602bps
2023/07/26 09:29:26.471787 [HLS] ffmpeg: chrome-CNBC: [matroska,webm @ 0000000002672800] Unknown element C1 at pos. 0x1aebe0 with length 0x10340efae9b considered as invalid data. Last known good position 0x199ce6, 6 unknown elements in a row
2023/07/26 09:29:26.471787 [HLS] ffmpeg: chrome-CNBC: [matroska,webm @ 0000000002672800] Seek to desired resync point failed. Seeking to earliest point available instead.
2023/07/26 09:29:29.303446 [HTTP] | 200 | 12.0502392s | 10.255.1.227 | GET "/devices/M3U-ChromeCaptureforChannels/channels/9206/hls/master.m3u8?codec=copy&format=copy"
2023/07/26 09:29:41.374163 [HLS] Couldn't generate stream playlist for ch9206-dM3U-ChromeCaptureforChannels-ip10.255.1.227: Timeout waiting for session to start after 12s
2023/07/26 09:29:41.374163 [HLS] Stopping transcoder session ch9206-dM3U-ChromeCaptureforChannels-ip10.255.1.227 (out: 8.455011s, finished: false, first_seq: 0, last_seq: -1)
2023/07/26 09:29:41.374163 [ERR] Error during stream M3U-ChromeCaptureforChannels ch9206 CNBC: read |0: file already closed
2023/07/26 09:29:41.374163 [TNR] Closed connection to M3U-ChromeCaptureforChannels for ch9206 CNBC
2023/07/26 09:29:41.375686 [HTTP] | 200 | 24.0582827s | 127.0.0.1 | POST "/hls/progress?key=ch9206-dM3U-ChromeCaptureforChannels-ip10.255.1.227-remux"
2023/07/26 09:29:41.389492 [SNR] Buffer statistics for ch9206 CNBC: buf=0% drop=0%
2023/07/26 09:29:41.392624 [HTTP] | 500 | 12.0715379s | 10.255.1.227 | GET "/devices/M3U-ChromeCaptureforChannels/channels/9206/hls/stream.m3u8?codec=copy&format=copy"
2023/07/26 09:29:47.581201 [HLS] ffmpeg: chrome-CNBC: av_interleaved_write_frame(): Invalid argument
2023/07/26 09:29:47.581201 [HLS] ffmpeg: chrome-CNBC: Error writing trailer of pipe:: Invalid argument
@tmm1, submitted diagnostics: 1457183c-8333-4b89-a264-42dfb6f0a073
EDIT: And to be clear, the problem is with Channels. VLC plays CC4C perfectly fine:
EDIT 2: Confirmed this again by downgrading Chrome to 114.0.5735.199 and everything worked hunky-dory.
How to Downgrade: https://browsertouse.com/blog/17223/downgrade-install-old-chrome-version/
Version to Downgrade to: Download Google Chrome 114.0.5735.199 for Windows | Uptodown.com
1 Like
Saw a mention over in the HDMI for Channels thread about a popup that came on during a show when using Chrome Capture for Channels, advertising another show. I'm purely speculating here, but is there a way to install extensions in the engine used by Chrome Capture? There's something on the Mac (built for Safari but can be manually installed in Chrome) called Stop the Madness, which, more than a normal popup blocker, deals with all sorts of annoyances when browsing, like this kind of window. There are other windows like this, asking for input, that the extension dismisses. It's almost like the developer addresses every annoyance that bothers him.
This would only work in installs on a Mac, but maybe something similar is elsewhere? List of things it can handle:
I just set this up on MacOS (Mac Mini M1) and with Weatherscan, Channels displays it with miles of pillarboxing LOL... what could I possibly be doing wrong? The Chrome window appears fine, but what Channels on ATV is outputting is just a square inside a ton of black. I've read through this feed and can't seem to figure out why it would be working the way it is.
Yeah, that's a Weatherscan thing, that's just what the source looks like, in any browser, having nothing to do with CC4C or CDVR. I think it's formatted that way because it's intended for small hotel lobby TV's (or something like that.)
Ah that makes sense - I actually had letterboxing on the channel too, but figured out if I just made the Chrome window larger on the host machine, it went to full 4:3 with the pillarboxing.
1 Like
Mentioned previously:
So I've been playing with this more. I moved onto YTTV, and its working better than Fubo. I don't get DRM warnings anymore on ABC affiliates when capturing.
For those dealing with stuttering, see if this argument works well in your main.js:
--disable-gpu-vsync
Disabling vsync helped removed most of the stuttering I was getting on my end. Now I only seem to get it rarely, and its overall less bothersome. Opening new streams causes others to stutter for a brief moment, not sure if there is a way to partition resources better for tabs.
Where are you adding this vsync command in the main.js file? In the encoding section?
1 Like
Here's my code. This code below starts at about line 41 for me. Only thing I added was that --disable-gpu-vsync flag:
executablePath: getExecutablePath(),
defaultViewport: null, // no viewport emulation
userDataDir: path.join(dataDir, 'chromedata'),
args: [
'--disable-gpu-vsync',
'--disable-notifications',
'--no-first-run',
'--disable-infobars',
'--hide-crash-restore-bubble',
'--disable-blink-features=AutomationControlled',
'--hide-scrollbars',
],
1 Like
Thanks, I'll give that a try. The video playback is pretty smooth for me already, but during sports you can detect a slight bit of judder every so often.
A couple of small updates for those of you running this project using the Docker container:
First, I posted a docker-compose to support being able to connect to the "session" using VNC to enter credentials and such. It turned out that closing the VNC client also closed the VNC server in the container, so a second connection was not possible without a re-deploy. Easy fix though, the server just needed a "-forever":
version: '3.9'
services:
chrome-capture-for-channels:
image: fancybits/chrome-capture-for-channels
container_name: cc4channels
command:
- sh
- -c
- |
Xvfb :99 -screen 0 1920x1080x16 &
x11vnc -display :99 -forever &
node main.js
ports:
- 5589:5589 # cc4channels proxy port
- 5900:5900 # VNC port for entering credentials
user: '0:0'
environment:
- TZ=US/Mountain
volumes:
- /data/cc4channels:/home/chrome/.config
restart: unless-stopped
Second, if you happen to be running Docker in a Proxmox LXC container like me, make sure you have a minimum of 4 CPU cores assigned as this project requires some horsepower! So far 2GB of memory and 512MB of swap seems OK, but I was redlining with 2 cores.
Thanks
Maybe I'll try the docker method again since the windows version no longer works since the chrome update.
1 Like
Above I showed how you can get the Windows version working by downgrading Chrome:
2 Likes
Thanks, maybe I'll try that. Doesn't seem like a long term solution since this is on my daily driver machine.
I too propose for this tool to use aac audio instead of opus. JF doesn't play nice with opus audio and will try to transcode it.