Chrome Capture for Channels

[cyberskier]

Do you mean running it via node main.js? That's how I do have mine setup. Will that work even with the crashes?

[afs1990]

@cyberskier

Do you mean running it via node main.js? That's how I do have mine setup. Will that work even with the crashes?

@Accustiver

I ran into this same issue and here’s what I did. I uninstalled chrome. I completely deleted my chrome capture for windows install. I installed chrome version 135. I went into services.msc and found the 2 google update processes, right clicked and went to properties, then changed automatic to disabled and applied that. I then reinstalled chrome capture for windows. I use the node option as I customize my main.js file. After doing all these steps, it’s working like normal for me again.

I was using the downloadable executable file before. Try following Accusitver's steps (uninstall and reinstall both Chrome and Chrome capture for channels.

[Accustiver]

Yes…using main.js although I use the customized version that someone on here created…ncc-7-something along those lines. I tweaked some code in there as well to my liking. But bottom line is, uninstalling everything and re-installing with chrome 135 and immediately disabling updates SHOULD work.

[hjd]

Just to add for others...in my testing, Chrome 138.0.7204.169 was the last working version with CC4C. Chrome 139 seems to have broken things, though it's unclear (to me at least) whether that's intentional or unintentional breakage on Google/Chrome's part.

For those that need to download it: Download Google Chrome 138.0.7204.169 for Mac | Uptodown.com - that's the macOS link. You can find the other OSs at the bottom.

My suggested path for folks who want to pin versions on macOS:

1. Download the above and install it, but don't start it.
2. rm -rf ~/Library/Google/GoogleSoftwareUpdate ; mkdir ~/Library/Google/GoogleSoftwareUpdate/ ; chmod a-rwx ~/Library/Google/GoogleSoftwareUpdate - this will delete the Google software update cache directory, recreate it, and set permissions to prevent Chrome from being autoupdated.
3. Delete chromedata directories under the CC4C directory (and possibly in ChannelsDVR as well if you're using TVE). The directories aren't downward compatible with older versions and generate errors.
4. Reauthenticate for TVE as- needed for CC4C and ChannelsDVR.

Hope this helps folks like me who need it...and here's hoping future Chrome releases fix things.

[acavender]

@hjd

chmod a-rwx ~/Library/Google/GoogleSoftwareUpdate

Thank you!

That worked brilliantly, and confirmed my suspicion that a recent Chrome update was the culprit. I'm back up and running with my NBC-owned channels (the only ones I need CC4C for).

[scottuf]

Thanks for this!!!

[doug8796]

This is all well and good, but how long until the chrome dependencies become deprecated - does someone have a backup plan to port to Firefox somehow? Someone that knows much more than me.

[tmm1]

Not afaik. The project is called chrome capture. All the code is based on chrome.

[Bobby_Vaughn]

Firefox doesn't have the ability to capture audio and video like Chrome does. Their API only allows for image capture of a tab.

[AeroR1]

Can you push an update that will work to GitHub?

[doug8796]

Your certainly a codemaster for channels, any hope you could port to its own chromium-based portainer - edge or brave or whatnot?

If we can find it, 138.0.7204.184 should also work? The changes also broke puppeteer and early 139 canaries also fail. Could we submit a bug report or was the fix / patch intention.

According to chatgpt, things might start breaking as early as 2 months and as late as 12 months, maybe even as early as mid 2026, so we are on life support here.

If I can find a pre-final 139 it will probably give us 3-6 more months.

Is it because puppeteer is not compatible?

Please report the bug here

https://support.google.com/chrome/thread/368988217/chrome-capture-broken?hl=en&sjid=16089971997407949323-NA

Widevine TVE DRM cracked down in 2022 for Chrome 106 and below being deprecated. So that means we have 2-36 months left until 138 is not supported any longer.

EDIT:

Can the chrome capture be updated with the newer puppeteer?

[resjus30]

@hjd

• Delete chromedata directories under the CC4C directory (and possibly in ChannelsDVR as well if you're using TVE). The directories aren't downward compatible with older versions and generate errors.

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!

[cyberskier]

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).

[doug8796]

On windows you can just disable the service. I did some diggiing and got a mirror of 138.0.7204.184

[hjd]

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.

[DaveTheNerd]

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.

[doug8796]

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

DEPRECATED: PC Stream for Channels (DRM Workaround) | No new hardware required!

UPDATE 2023-06-20: While this solution can and does still work, it is unnecessary to do so because this now exists: Please follow along there as I will no longer be updating this workaround. Inspired by the HDMI for Channels project, this solution attempts to do the same thing. Namely, this project allows the user to stream any station, including ones protected by DRM, in Channels--so long as there is a web source to get the content from that the user has legal access to. However, this solu…

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?

[tmm1]

@doug8796

start killing support for old chrome sometime in the next 2 years likely before then

@doug8796

we will be totally locked out

@doug8796

time is not on our side

@doug8796

asap or we will all lose out

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.

[tmm1]

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.

[tmm1]

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