Are the only Channels DVR 'chromedata' directories on Mac in ~/Library/Application Support/ChannelsDVR/data/chromedata/ ? And do I only delete the files in that directory and not the entire chromedata directory itself? Thanks!
I don’t remember the answer to your first question from when I did it, but as far as deleting the entire directory vs deleting all files, I deleted the entire directory (after backing it up, to be safe).
On windows you can just disable the service. I did some diggiing and got a mirror of 138.0.7204.184
I've been iteratively refining / tailoring CC4C for my use case. It's not there yet, but if there's interest (and certainly no commitment on timeline here), I may look into cleaning it up and releasing it more fully. There's plenty of alternatives already and the world doesn't really need me to create another iteration I think. The challenge I've found and been trying to address is that, largely speaking, I have a desire to deal with some of the quirks in running something like this long-term and having it feel "system service worthy", if you will. It would be macOS-only...I've been slowly going through and updating dependencies and refactoring some of the setup code. So far, I've gotten it up and running for a few weeks on express 5 (a few notable changes there to async handling and parameters in routes that needed refactoring).
I'm curious to see if updating to puppeteer 24 will address any of the issues we've all encountered...it's been painful to play with it so far (lots of things break!), so I've parked this for the time being and will come back to it when I want to put more time into a side project. @tmm1 - have you looked into it much perchance?
Finally, there's also the chance that Chrome was just "broken unintentionally" in some way after 138 and will be fixed in a future version (139 is clearly busted...but who knows what 140/141/142 will bring...). It's not without precedent...we've all seen this before.
Thanks excellent to hear, @hjd! I'd love to see what you've done and am happy to test. Right now as a nerdy Mac user who doesn't (yet!) have enough time to sort this out on my own, I'd be more than thrilled to be a testing ground for whatever you've got cooking. 
Many DRM will start killing support for old chrome sometime in the next 2 years likely before then. If you want chrome to support it go to my chrome bug thread above and complain!
Apparently Chrome 138 is the last version of Chrome that will support Android 8.0 (Oreo) and Android 9.0 (Pie). It seems they are possibly upgrading widevine soon and we will be totally locked out.
Peacock already requires Chrome 121, so time is not on our side. Report to chrome development team asap or we will all lose out.
If yall need a 138.0.7204.184 link let me know.
EDIT: tmm1 why the downvote?
https://issues.chromium.org/issues/442371645
Official bug report to chromium team.
So, as others have asked, will upgrading to a new puppeteer help? or how much worse would
The devs said this:
Can you summarize what the issue is? That first link is a massive dump of text. The second one just points to the first.
Can you guys help me explain the issue?
This is all speculation. Please stop spreading fear, uncertainty and despair.
If you want to be helpful, you can describe what the issue is and find the actual error message that's happening with the new version of Chrome.
The first line of the cc4c README links to the project it is based on, called puppeteer-stream.
Last week there was a fix for this error:
Extension has not been invoked for the current page (see activeTab permission). Chrome pages cannot be captured.
It is available here: fix: "Extension has not been invoked for the current page (see active… · samuelscheit/puppeteer-stream@5d2bd65 · GitHub
Two weeks ago there was a fix for --load-extension not working. Maybe this changed in v139? Fix --load-extension · samuelscheit/puppeteer-stream@cbe211b · GitHub
In April the was an upgrade to puppeteer 24: Upgrade puppeteer-core to 24.5.0 by yuekui · Pull Request #193 · samuelscheit/puppeteer-stream · GitHub
If you figure out what the error is then you can copy the proper fix over.
Looks like someone reported the same error here: Error: net::ERR_BLOCKED_BY_CLIENT at chrome-extension://jjndjgheafjngoipoacpjgeicjeomjli/options.html#55200 · Issue #200 · samuelscheit/puppeteer-stream · GitHub
Error: net::ERR_BLOCKED_BY_CLIENT at chrome-extension
The fix is the --load-extension= which was removed in Chrome v139
At this point, I think hes just trolling. I added him to my ignore list (and I expect others to do the same)
I pushed some changes to the cc4c github and docker. I switched from nodejs to bun and made new windows/mac exes here: Releases · fancybits/chrome-capture-for-channels · GitHub
I'm not. I have contributed a lot to this sorry I got paranoid that Google would kill it just like they kill a lot of stuff. I'm working on peacock/hbomax + others guide now
I havent figured out the new version of cc4c. Maybe someone else will have better luck than me.
Tried standalone and got and couldn't get to work on 138, 140, or 142
Google devs are aware about 139+ having issues
I tried the development environment, but it wouldn't start up chrome on a Windows 11 PC. I do have Chrome version 135 installed with updates disabled. Below is the error message in the terminal;
[2025/09/03 19:31:34.353] failed to start browser page https://www.nbc.com/live?brand=golf ProtocolError: Target.setDiscoverTargets timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
at new PuppeteerError (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\common\Errors.js:19:9)
at new ProtocolError (unknown:1:28)
at new Callback (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\common\CallbackRegistry.js:106:21)
at create (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\common\CallbackRegistry.js:24:30)
at initialize (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\TargetManager.js:97:32)
at initialize (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\TargetManager.js:96:24)
at _attach (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\Browser.js:70:35)
at _attach (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\Browser.js:61:19)
at _create (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\Browser.js:26:23)
at _create (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\cdp\Browser.js:19:26)
at launch (C:\Users\Dave\chrome-capture-for-channels\node_modules\puppeteer-core\lib\cjs\puppeteer\node\BrowserLauncher.js:157:61)
at processTicksAndRejections (native:7:39)
This is the latest version that works until we can get a fixed canary
It's working for me on mac, but on windows I just tried and it was having issues with bun. Chrome launched but wasn't navigating to a page for me.
Using node main.js still works so I guess use that on windows.
EDIT: Found the bun + windows + puppeteer bug: [Bug]: Puppeteer fails to load unpacked extensions when running with Bun · Issue #21700 · oven-sh/bun · GitHub
Node isn't working for me either on 139.x, but I may be doing something wrong, as stated google devs are aware of the issue and maybe they can fix. Sorry for frustrating you tmm1.
Now that NESN (and NESN+) has DRM is it possible to add that to CC4C, too? Happy to provide details and/or test, of course.
I use the node version but I'm using @doug8796 custom version ncc-7-0.js
Is it possible to upgrade to CC4C version 2.0.1 but use ncc-7-0.js instead of main.js?
I was just testing to see if it would work and how it would look. I'm having pretty good luck with @bnhf's Docker container. Thanks though.
I tried that too, but a lot of errors popped up in the terminal window with paths not being found, etc., it wouldn't even start Chrome.