Since both versions use the same ports, both cannot be running at the same time. So I don't think they're bumping heads.
Thanks!
OK, so after playing around with this a bit today, my working theory is that chromedata in Linux can become corrupted in a way that creates all kinds of problems in a container environment.
So, what I'm attempting now is to save only the minimum data required to store passwords, tokens, cookies and other site data. Basically, just trying to minimize the need to connect with VNC after the initial password entry, without persisting anything unneeded for that.
I've pushed a new bnhf/cc4c:latest (aka bnhf/cc4c:2025.04.15) that uses multiple Docker Volumes attached to the various directories under chromedata/Default that need to be saved without also saving cache and other things that can become corrupted.
A couple of other comments for you, and other Windows Docker Desktop users. Best performance on a WIndows host will be achieved by running the Windows version of cc4c. Mostly due to the incomplete Linux Chrome support for the iGPU, compared to the full support in Chrome for Windows. Also, Peacock (NBC) at least, does not appear to support the Linux version of Chrome or Chromium for decrypting DRM.
With those disclaimers, if you still want to give this a try, here's the updated Docker Compose for the new bindings. I haven't added this yet to Project One-Click, so you'll need to stop your cc4c stack in Portainer and update it:
version: '3.9'
services:
cc4c:
# 2025.04.13
# GitHub home for this project: https://github.com/bnhf/chrome-capture-for-channels.
# Docker container home for this project with setup instructions: https://hub.docker.com/r/bnhf/cc4c.
image: bnhf/cc4c:${TAG:-latest}
container_name: cc4c
devices:
- /dev/dri:/dev/dri # Uncomment for Intel Quick Sync (GPU) access
ports:
- ${HOST_PORT:-5589}:${CC4C_PORT:-5589} # cc4c proxy port
- ${HOST_VNC_PORT:-5900}:5900 # VNC port for entering credentials
environment:
- VIDEO_BITRATE=${VIDEO_BITRATE:-6000000} # Video bitrate in bits per second [number] [default: 6000000]
- AUDIO_BITRATE=${AUDIO_BITRATE:-256000} # Audio bitrate in bits per second [number] [default: 256000]
- FRAMERATE=${FRAMERATE:-30} # Minimum frame rate [number] [default: 30]
- CC4C_PORT=${CC4C_PORT:-5589} # Port number for the server [number] [default: 5589]
- VIDEO_WIDTH=${VIDEO_WIDTH:-1920} # Video width in pixels (e.g., 1920 for 1080p) [number] [default: 1920]
- VIDEO_HEIGHT=${VIDEO_HEIGHT:-1080} # Video height in pixels (e.g., 1080 for 1080p) [number] [default: 1080]
- VIDEO_CODEC=${VIDEO_CODEC:-h264_nvenc} # Video codec (e.g., h264_nvenc, h264_qsv, h264_amf, h264_vaapi) [string] [default: "h264_nvenc"]
- AUDIO_CODEC=${AUDIO_CODEC:-aac} # Audio codec (e.g., aac, opus) [string] [default: "aac"]
- TZ=${TZ} # Your local timezone in Linux "tz" format.
volumes:
- cookies:/home/chrome/chromedata/Default/Cookies
- logins:/home/chrome/chromedata/Default/Login Data
- localstorage:/home/chrome/chromedata/Default/Local Storage
- prefs:/home/chrome/chromedata/Default/Preferences
- secure:/home/chrome/chromedata/Default/Secure Preferences
restart: unless-stopped
volumes:
cookies:
logins:
localstorage:
prefs:
secure:
And, here's a set of sample env vars:
TAG=latest
HOST_PORT=5589
CC4C_PORT=5589
HOST_VNC_PORT=5900
VIDEO_BITRATE=9500000
AUDIO_BITRATE=256000
FRAMERATE=60
VIDEO_WIDTH=1920
VIDEO_HEIGHT=1080
VIDEO_CODEC=h264_vaapi
AUDIO_CODEC=aac
TZ=US/Mountain
While I was experimenting today, I ended up having the same ECONNRESET error you were seeing, with a known working container. This was solved by removing the single cc4c_chromedata volume we were creating. After deleting the volume, everything started working again. Keep this in mind if you see this error, although now there are five volumes that would need to be deleted. Hopefully, that won't be needed. 
BTW, I added Spectrum support from "new chrome capture" to this build, so let me know how it goes if you try it out. I also added Peacock, but attempts to tune would show an unsupported device display.
@bnhf in your opinion with these latest updates to the docker container version, is this on par with the proxmox cc4c lxc tutorial you posted last week? Or is proxmox lxc still your recommendation over the docker version. You also mention spectrum in this latest docker, does the lxc version also have the spectrum support?
Excellent question! I'll be using the LXC version as my daily driver, though both seem to work well. My best guess is that the LXC version will work best for multiple cc4c streams, and it's certainly easy enough to add resources to it if needed.
I haven't pushed any updates to my cc4c fork of the repo yet, but it'd be no problem to do so, if you want to try it out. My fork was attached to fancybits, but I've moved it to dravenst. So the change to the step-by-step would be to clone my cc4c repo.
Glad to hear you're on the Proxmox train -- it's absolutely awesome, especially for "enthusiasts" like you and me.
I’ve been researching it for awhile off and on and it does seem ideal. I just haven’t had the time to make the switch yet. I’m debating a switch to spectrum from Hulu on the tv side and this would kill my ADBTuner usb capture with no android tv app. So I’ve been eyeing the cc4c feeds lately. So no hurry on pushing the updates.
1 Like
With your Ubuntu familiarity, it should be an easy transition. Given you can do most of what you need to do from the Proxmox WebUI, you might even find it easier to use -- but significantly more powerful when paired with some decent hardware. You can't go wrong with cores, RAM and a second Ethernet port (2.5 or 10Gbps) -- you can do a modest system too, but something with some muscle is extra fun.
I've installed your updated version and so far it looks really good with the Spectrum channels! I'll keep an eye on it for the next few days and let you know how if fares. Thanks again!
1 Like
Pushed a few minutes ago.
So far, good news with cc4c in a Windows Docker container! No container crashes and the videos look great.
An interesting sidenote, just for information only. I normally port these channels to Emby which works very well when I choose h264_vaapi as the video_codec, but when I choose h264_qsv, it errors out.
2 Likes
I definitely have the vaapi drivers in the container, so maybe that's why.
1 Like
So how is it working these days, does it use my node js mods to work with puffer, nbc, and DirecTV stream?
I believe I can safely say the Docker version is working better than it ever has. It's for amd64 machines only though, and they need to have decent specs.
I'm building the container with a fork of the dravenst code base, though I did merge about a dozen lines from your mods to support Spectrum. @daldana7296 reports this is working well for Spectrum, and I'm seeing similar solid results with Sling.
I am running the latest release from June 27, 2023 natively on my M1 Mac mini, and it runs well.
My question: is there a newer release and or patch set that I should be using? It seems like there have been quite a few patches/mods/changes here. I'm fairly nerdy (I think all of us running cc4c are nerdy, right? 
), so totally fine not "just" running the pre-compiled app.
Thanks!
My first thought is: if what you have is working for you, stick with it.
But if you want to try it out anyway -- set up a development environment, and clone my repository:
If nothing else, it'd be more configurable than what you're using now, with these command line flags available:
Usage: node main.js [options]
Options:
-v, --videoBitrate Video bitrate in bits per second [number] [default: 6000000]
-a, --audioBitrate Audio bitrate in bits per second [number] [default: 256000]
-f, --frameRate Minimum frame rate [number] [default: 30]
-p, --port Port number for the server [number] [default: 5589]
-w, --width Video width in pixels (e.g., 1920 for 1080p) [number] [default: 1920]
-h, --height Video height in pixels (e.g., 1080 for 1080p) [number] [default: 1080]
-i, --videoCodec Video codec (e.g., h264_nvenc, h264_qsv, h264_amf, h264_vaapi) [string] [default: "h264_nvenc"]
-u, --audioCodec Audio codec (e.g., aac, opus) [string] [default: "aac"]
-?, --help Show help [boolean]
Examples:
node main.js -v 6000000 -a 192000 -f 30 -w 1920 -h 1080
node main.js --videoBitrate 8000000 --frameRate 60 --width 1920 --height 1080
3 Likes
Brilliant. Thank you!
1 Like
Running CC4C on Intel Mac as a service (not in docker). Been using the 1.2 @dravenst code. Was notified that it was updated to 1.4 to add some Spectrum code, which is great, but now it will only start Chrome for the NBC channels. Any that are chrome://192.168.4.100:5589/stream?url=https://xxx don't spin up a Chrome window to start the stream.
Also, I wasn't sure the correct way to update the package, so stopped the service then did another git pull to download the latest. This required me to re-authenticate in the browser. Is there an easier way to update without starting over? At least the code uses options so I don't need to edit anything within the code any time it's updated.
After almost a week of working nicely, yesterday I had the "display already in use error" that I mentioned in post #1956. I had to stop the stack and then start it again to get it to work (stopping the container and restarting it didn't correct it).
My apologies, I fixed the bug in latest release now (version 1.4.1).
2 Likes
Thanks. Works for me. And I figured out git pull will update.
1 Like
Were you able to use your existing set of Docker Volumes, or did you need to delete those before starting the stack?