Running Ubuntu 22.04 LTS: doing "node main.js", I'm getting an error when opening any NBC streams. I've logged in, but I'm getting an error. "Sorry! We're having some trouble." It appears to be that the snap version of Chromium that installed with npm doesn't have Widevine support, and I have been unable to get it to install.
Disregard all of that. I solved this issue by setting the CHROME_DIR to my “normal” Google Chome instance.
The file came up great on my system.
Trying to get Philo to work so I can bring in stuff not on TVE.
Glad everyone is having some good success on YTTV. I'm wondering what happens to the browser when you drop the stream?
Great work and thank for the nice option.
Earlier today, channels I added via NBC.com played fine when switching between them, now all of them are requiring a click of the play icon, on the server.
I'm also playing around with channels on tv.youtube.com, those are playing fine.
I have this working with the NBC channels, weatherscan and Youtube. However, none of them are going over 628kbps. My chrome-capture-for-channels-win-x64 Windows 11 PC is a 12th Gen Intel Core i5-1235U with 10 cores and 32gb memory and only SSD drives. All my lan is 1gigabit and my Internet connection is 500 Mbps. So I am pretty sure it can easily handle transcoding. In fact my performance levels in taskmanager while using chrome-capture doesn't go above 25% utilization. My ChannelsDVR server is on a Synology 220+ with 10gb RAM and SSD drives.
In comparison, my androidhdmi-for-channels channels are transcoding at 10mbps and my HomerunConnect at around 9mbps. The TVE channels are remuxing on average at around 2x+.
So is the much lower transcoding rate on chrome-capture expected or is there something I should be looking at that is causing a bottleneck? Or is that rate I am seeing perfectly acceptable.
For what it's worth, I see this when playing via the Channels DVR web interface, but not in the dedicated Channels App. Edit: This also happens when using Channels DVR as a M3U source.
This is from a short DVR recording:
Format : MPEG-TS
File size : 70.0 MiB
Duration : 1 min 55 s
Overall bit rate mode : Variable
Overall bit rate : 5 082 kb/s
And not a criticism at all as obviously this is very early in development, but even at the full bitrate there is a noticeable drop in picture quality relative to other streaming sources (traditional TVE, HDMI).
Another edit: Not sure if related to the PQ issue, but after the video loads (running in macOS) the browser window is resized to a rather small size. 580x281 as per "stats for nerds" in YouTube TV.
Thanks! 
You should see my 600-page design and admin documentation from my prior life!
You got it! I'll make a few updates from things that came in overnight. A guy sleeps for a few hours and all this happens!
I notice that after stream is closed from client the Chrome Capture Tab goes to white page but does not close and when new stream starts it starts a new Chrome Capture Tab, while the older tab remains. I noticed I had 5 of these recent tabs still open. How to close these tabs when stopping a stream.
The latest macOS build seems to be crashing as soon as I open it. (macOS Intel).
I think that's what I'm seeing with the latest Mac arm64 version, too. I get a "killed" message in Terminal when I try to open it, both by right-clicking and selecting "Open", and by using the command prompts given earlier in this thread.
Looks like giving it all a rest resolved it for me, because I tried again this morning, and now all of those same channel selections are playing automatically again when I tune in, no extra clicks on the server required.
FWIW, I tried this, but once again got the "can't be opened because the identity of the developer cannot be confirmed" dialog. I was able to bypass it easily via the instructions I shared above.
Same here with ChromeCaptureARM64 0.1.4. Downgraded back to 0.1.3, now it's working fine again.
You no longer need to do this. See:
Can you get some additional keystrokes added? Namely, the space bar and backspace.
I'm curious about this, too. @Fofer, @Absenm, @KompilerDJ, do you have any insights on comparison of performance, image/sound quality, etc...?
I moved this over to my M1 Mac, and it runs well compared to the buffering I was getting on the old MacBook Air. I'm guessing that Chrome transcoding engine isn't as efficient as Plex?
I know these are early days (and I'm not a programmer, so don't know if either of these are even possible), but a couple random thoughts for down the road:
It would be nice if a source has all YouTube TV or other streaming channels, if the Chrome window could somehow stay on "standby" on a low-bandwidth YouTube TV page for faster loading (maybe a settings page, or with the player paused?). The biggest drawback of this right now is that it is even slower to load than the HDMI Encoder method.
It would be nice to be able to have a channel under multiple sources, but only show up once in the guide, and, in the background, be able to prioritize those sources. For example, tell Channels to first use any HDMI Encoders to tune a channel, and if they're tied up, then use the Chrome Capture. And even specify it in reverse priority for recording, since load time is less important.
Just spitballing ideas, which may or may not be doable.
I spoke too soon. As I use this more, the initial load time is very slow, but then it tunes into subsequent YouTube TV channels very quickly compared to the HDMI Encoder method — about 5 seconds. Very nice!
I'm only in the preliminary stages, but this method has me more optimistic than the HDMI Encoder method:
@tmm1, @maddox, can this change be extended into .strm links? I have an idea...
Or...
FYI, I can already get this to work in VLC:
In Channels Web UX it doesn't launch the video tab in Chrome. With a client, it it gives me a generic error of "Connection Lost" and doesn't even launch Chrome.
I was noticing yesterday the same things:
The video viewport size was small (something like 500x500) (on mac, Linux was a bit better)
The encoding bitrate from chrome never really went above 1000 after manual resize / full screen intervention
Sometimes the video doesn't auto start
Sometimes I get prompted to select my provider (even though I had previously been prompted) (NBC)
Hulu gets angry pretty much every attempt and demands a code that they email
Windowboxing / black space around video as turtletank mentioned
Was letting some of the dust settle and will do some more tests.
PS: not trying to be critical this does show promise!
I've used HDMI for Channels extensively (and contributed to that thread quite a bit).
I think it's too soon to make a fair comparison.
Right now the HDMI solution is far more refined and reliable.
In my experience, the Chrome Capture feature has relatively poor picture quality, the video often doesn't fill the screen (it's windowboxed with borders around all sizes, this is most noticeable on a television), the app often crashes, and a good solution for authentication is not yet in place. It looks very promising going forward, but one Chrome update could permanently break this option entirely. Something to keep in mind.
As a long-term solution, the HDMI encoder setup consumes less energy (compared to a running PC encoding video) and should be way more resistant to changes in DRM (will work until HDCP is replaced). But it's a pile of hardware you have to setup, which is a big negative.
I'm interested in seeing how all of these things evolve over time. It's good to have both options.
Running the “dev” steps, instead of just firing the executable, works.
