That's the format I'm using as well. But I think I figured it out. I was running CC4C headless with the custom node ncc-7-0 that you'll find digging around through this forum. I got rid of headless and the music plays. I'd prefer to run it in headless mode since this uses less resources, but if this is what I have to do to get the music to play, I'll keep it...I'm not using it that often. But just curious if anyone happens to know how to run it headless and still get the music to play.
To run headless you might want to try cheap HDMI/DP fob from Amazon. That solved all my issues with remote access to my headless server. The "fob" fakes the computer into thinking there is a 1920 display attached.
1 Like
Will need to look into that. Just wondering though if there is a simpler route to go by just editing or adding some code in the .js file.
I did see this line of code:
video style="width: 100%; height: 100%" onKeyPress="videoKeyPress(event)" onClick="videoClick(event)" src="/stream?waitForVideo=false&url=${encodeURIComponent(
req.query.url || 'https://google.com'
)}" autoplay muted />
Notice the autoplay muted line. Not sure if this has anything to do with it but is it possible to change this line to be unmuted? Not sure what you would type in there though to make that unmuted.
Once again figured it out with a little tinkering. After digging around in some forums from a google search, I discovered that if I add the following lines of code to the .js file, audio will play when running headless:
Under the args: [ section add the following code: '--autoplay-policy=no-user-gesture-required',
Under the ignoreDefaultArgs: [ section add the following code: '--mute-audio',
It works like a charm!
2 Likes
A couple of updates for those interested in a containerized version of chrome-capture-for-channels:
The first, which I reported a few posts ago, is that cc4c is running very nicely in a Proxmox LXC container with 4 vCPUs and 4GB of RAM allocated. Highly recommended for users with decent hardware running Proxmox.
The second, is that I built a new Docker container (amd64 only) based on the @dravenst cc4c repo, and that's also working very nicely. @dravenst appears to have really cleaned-up the cc4c code, with better error handling and improved performance. I'm testing this on a 10th generation i7, also with 4 vCPUs allocated and 4GB of RAM. Here's what resource usage looks like, including all overhead, with a single active stream:
I've circled back to cc4c many times since it was first released, and this is the first time I've liked the results enough to put it into "production". I'm using it with a Sling Starz/Encore package, which includes 15 premium movie channels for ~$11/mo.
The container is available as bnhf/cc4c:latest, and should be spun-up using the following Docker Compose in Portainer:
version: '3.9'
services:
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} # Add your timezone in the Environment variables section with "name" set to TZ and "value" to your local timezone
volumes:
- cc4c:/home/chrome/chromedata # Creates a persistent Docker Volume in /var/lib/docker/volumes for Chrome data.
restart: unless-stopped
volumes:
cc4c:
name: ${HOST_VOLUME}
Here's a set of sample env vars, that you'll want to customize to your requirements:
TAG=latest
HOST_PORT=5589
CC4C_PORT=5589
HOST_VNC_PORT=5900
VIDEO_BITRATE=8500000
AUDIO_BITRATE=256000
FRAMERATE=60
VIDEO_WIDTH=1920
VIDEO_HEIGHT=1080
VIDEO_CODEC=h264_vaapi
AUDIO_CODEC=aac
TZ=US/Mountain
HOST_VOLUME=cc4c_chromedata
Use the compose as-is, and put the env vars (with your values) in the section of the Portainer-Stacks editor designed for that purpose (use Advanced mode to copy and paste this list).
This container is designed to use a VNC client for connecting to the Chrome instance to enter credentials and the like. I use TightVNC Viewer, but others will work. The VNC server is on the standard port 5900, unless you change it.
If you're interested in the Proxmox LXC approach, I've updated the step-by-step here to use the @dravenst repo:
1 Like
I've added Project One-Click support for the new cc4c Docker container based on the @dravenst repo. This includes spinning-up the container, and creating an initial CDVR Custom Channels wth the Weatherscan channel. As a bonus, if you have the Sling StarzEncore package, it'll add those 15 channels as well -- ready to use. Pushed this afternoon as bnhf/olivetin:latest (aka bnhf/olivetin:2025.04.13).
Tweak any values you need/want to change, and the Portainer Stack will be created for you:
And, as always with Project One-Click, the Custom Channels Source is created too:
If you don't have OliveTin-for-Channels or Portainer installed yet, it's very easy these days:
Not sure if I'm missing something, but I can't change the ip address for the dvr. It only has three items as a dropdown.
Also, where would the main.js file be located after this install? I've found that the ncc-7-0 would very well for me when I used the windows executable, so I'd like to swap those two for comparison after install. Thanks.
My fault -- I'll fix that. I'll post here shortly once there's a new build available.
This one we'll need to put out heads together on. From my perspective, the @dravenst code base is the first time I've found cc4c to be usable in container form. As a matter of fact I'm watching Dante's Peak on StarzEncore now. 
All of the previous fixes/enhancements I've tried have perhaps been fine for folks running the code non-containerized. But, even with a 14th generation i9 running Proxmox the container version would, at best, have audio and video out-of-sync.
Having said that, I would like to add support for Peacock un-muting (similar to the Sling volume control in this repo), and whatever else you find you appealing in the version you're using. My number one goal though, will be to keep the Docker/LXC versions humming like they are now.
Long way around to saying the main.js in not exposed in this version, and I'm not sure you could replace it on the fly anyway, since it's running from container start -- and killing it would kill the container. I'm hoping we can get one version that serves everyone's needs, but is also solid, and can be containerized.
@daldana7296 OK, hopefully all rock and no roll now. Please pull :latest again, and let me know if we're good.
Also, any chance you could give me a rundown on the features you have with the version you're using now, that you'd like to see in this version?
Another interesting point, that I forgot to mention before, is that the new codebase is almost double the number of lines of the old. That's not necessarily indicative of anything, as I prefer to write compact code myself. But in this case, it appears to be mostly to do with reliability, configurability, error-handling and a few Sling-specific things.
@daldana7296 Thinking about this for a few more minutes, you wouldn't be able to swap out the main.js anyway.
The new version incorporates flags that are used to make things configurable. I did a few of these way-back-when, but this new version makes all the key settings tweakable.
I don't think it'll be difficult to merge code bases though. I don't believe the version you're using ever made it to GitHub -- but we can make that happen.
Thanks, the new version does allow the ip change (in fact, it was pre-populated with the correct address, kudos!).
I use cc4c primarily for Spectrum channels that are not TVE and the ncc-7-0 did very well at pulling in the videos at a decent rate. So far, with this version I can't seem to pull anything at over 200-300kbps. Also the NFL channel would stay at fullscreen after I initially opened it up, but with this version I seem to have to press fullscreen every time I start the channel.
As for Peacock, @m0ngr31 and @doug8796 were collaborating on a project they called CCEPG which worked for Peacock and ABC (although on Android devices only). Maybe you could check with one of them.
You're seeing that in client stats -- or using the CDVR WebUI? What are the specs on your Docker host computer?
That's likely something that would need to be merged.
I'll see what I can find.
I'm seeing that in the WebUI. I running a Windows 11 Pro PC with a 12th Gen I5 UHD 770 and 16 GB RAM. All drivers updated.
I just sent in a support ticket to CDVR because the server is not seeing any hardware transcoding hardware anymore. I just noticed that, so that might be the problem.
Try looking at a stream on a client if you could. The WebUI isn't a great way to compare, as it tends to make decisions on streaming rates too quickly.
Yup, you are absolutely right! On my android phone, the bitrate was no lower than 2Mbps and the picture was clear, not blocky. Thanks!
It was working pretty good but it wasnt 100% pulling the right channels. The goal was live events that happen as well similar to his sports channels ESPN+ etc and maybe also add others like Netflix live events.
The goal is to have the app work for people with Android devices as well that use the scripts and cc4c the guide data would be shared and it would be an instance both teams could work together
Below is the biggest problem, for me anyway, with cc4c in Docker. It will crash with a display already in use error.
'--enable-automation',
'--disable-extensions',
'--disable-default-apps',
'--disable-component-update',
'--disable-component-extensions-with-background-pages',
'--enable-blink-features=IdleDetection'
],
extensionPath: '/home/chrome/node_modules/puppeteer-stream/extension'
}
node:events:496
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at Pipe.onStreamRead (node:internal/stream_base_commons:216:20)
Emitted 'error' event on Socket instance at:
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
Node.js v22.14.0
(EE)
Fatal server error:
(EE) Server is already active for display 99
If this server is no longer running, remove /tmp/.X99-lock
and start again.
(EE)
13/04/2025 21:18:50 ***************************************
13/04/2025 21:18:50 *** XOpenDisplay failed (:99)
*** x11vnc was unable to open the X DISPLAY: ":99", it cannot continue.
*** There may be "Xlib:" error messages above with details about the failure.
Some tips and guidelines:
** An X server (the one you wish to view) must be running before x11vnc is
started: x11vnc does not start the X server. (however, see the -create
option if that is what you really want).
** You must use -display , -OR- set and export your $DISPLAY
environment variable to refer to the display of the desired X server.
- Usually the display is simply ":0" (in fact x11vnc uses this if you forget
to specify it), but in some multi-user situations it could be ":1", ":2",
or even ":137". Ask your administrator or a guru if you are having
difficulty determining what your X DISPLAY is.
** Next, you need to have sufficient permissions (Xauthority)
to connect to the X DISPLAY. Here are some Tips: - Often, you just need to run x11vnc as the user logged into the X session.
So make sure to be that user when you type x11vnc. - Being root is usually not enough because the incorrect MIT-MAGIC-COOKIE
file may be accessed. The cookie file contains the secret key that
allows x11vnc to connect to the desired X DISPLAY. - You can explicitly indicate which MIT-MAGIC-COOKIE file should be used
by the -auth option, e.g.:
x11vnc -auth /home/someuser/.Xauthority -display :0
x11vnc -auth /tmp/.gdmzndVlR -display :0
you must have read permission for the auth file.
See also '-auth guess' and '-findauth' discussed below.
** If NO ONE is logged into an X session yet, but there is a greeter login
program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need
to find and use the raw display manager MIT-MAGIC-COOKIE file.
Some examples for various display managers:
gdm: -auth /var/gdm/:0.Xauth
-auth /var/lib/gdm/:0.Xauth
kdm: -auth /var/lib/kdm/A:0-crWk72
-auth /var/run/xauth/A:0-crWk72
xdm: -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
dtlogin: -auth /var/dt/A:0-UgaaXa
Sometimes the command "ps wwwwaux | grep auth" can reveal the file location.
Starting with x11vnc 0.9.9 you can have it try to guess by using:
-auth guess
(see also the x11vnc -findauth option.)
Only root will have read permission for the file, and so x11vnc must be run
as root (or copy it). The random characters in the filenames will of course
change and the directory the cookie file resides in is system dependent.
See also: http://www.karlrunge.com/x11vnc/faq.html
[2025/04/13 21:18:50.890] Selected settings:
[2025/04/13 21:18:50.890] Video Bitrate: 9000000 bps (9Mbps)
[2025/04/13 21:18:50.891] Audio Bitrate: 256000 bps (256kbps)
[2025/04/13 21:18:50.891] Minimum Frame Rate: 30 fps
[2025/04/13 21:18:50.891] Port: 5589
[2025/04/13 21:18:50.891] Resolution: 1920x1080
[2025/04/13 21:18:50.891] Video Codec: h264_qsv
[2025/04/13 21:18:50.891] Audio Codec: aac
[2025/04/13 21:18:50.893] Chrome Capture server listening on port 5589
Makes me wonder if the node JS version and the container version are bumping heads.
I'll have a look at this today.