Forgive the dumb question, GTFan, but how do you "kill" the instance (on a Mac M1)? I downloaded 1.08 and upgraded to 1.10 and I am getting the same issue around EADDRINUSE.
One way is to open the Activity Monitor app, search for "Chrome Capture" in the box at the top right, and force quit. That works for me in many instances, but there are times where that process isn't running, and I still get the error.
1 Like
Previously noted issue:
So I did some more testing. I tested with the docker version, the node version and the exe version all with the same results. If I use chrome://localhost:5589/stream/windy for example I keep getting the same error unsupported protocol scheme. My channels is running on a windows 11 machine btw. If I change the chrome to http://localhost: then I can see the program open up chrome on the server and start playing. However now I have a different problem in that I can hear sound, but I can't see video in the player. On the server the chrome is opened and is playing the video properly. I have tried on a few different machines with the same results. Loading the exe on a different computer and opening up a video stream with VLC I do get the video and audio. What else can I try to get this to work properly? Why is the chrome:// not working and the http:// is?
You have to update your DVR to prerelease
Thank you, that seems to have worked. MSNBC is running nicely, with some buffering, but that is probably my channelsdvr machine that is not good enough to handle it.
Is anyone else having an issue with Chrome Capture after the pre-release update of July 6th? I had channels working on both the NBC website and from Spectrum, but now neither one work. The server PC opens the channel correctly, but neither the app on my phone nor the my PC ever get the video. Below is an example of the log when I tried to open the Golf Channel.
2023/07/07 10:10:02.749903 [HLS] Starting live stream for channel 170 from 192.168.88.245
2023/07/07 10:10:12.786629 [ERR] Probe failed for live stream after 10.0324206s and 0 bytes
2023/07/07 10:10:14.745139 [HLS] Couldn't generate stream playlist for ch170-dANY-ip192.168.88.245: Timeout waiting for session to start after 12s
2023/07/07 10:10:14.745139 [HLS] Stopping transcoder session ch170-dANY-ip192.168.88.245 (out: 0s, finished: false)
2023/07/07 10:10:14.745139 [TNR] Closed connection to M3U-NBCStreaming for ch170 Golf
2023/07/07 10:10:14.745139 [ERR] Error during stream M3U-NBCStreaming ch170 Golf: read |0: file already closed
2023/07/07 10:10:14.759937 [SNR] Buffer statistics for ch170 Golf: buf=0% drop=0%
2023/07/07 10:10:59.286612 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
2023/07/07 10:10:59.287210 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
2023/07/07 10:10:59.287210 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
2023/07/07 10:10:59.287210 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
2023/07/07 10:10:59.287210 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
2023/07/07 10:10:59.287210 [HLS] ffmpeg: chrome-Golf: http://localhost:5589/stream/golf: Unknown error
No problems on my end, running server 2023.07.06.1740. My capture source is setup as MPEG-TS streams, not HLS. Not sure if that is the issue?
Also, I discovered the source of my "juddery" video, at the Channels client. My capture PC is running headless with a 4K HDMI dongle. And, for some reason the screen was set to go to sleep after 30 minutes. The video would become juddery when the screen was asleep. I changed the setting to never sleep, and the video on several recordings has been smooth.
So, have been able to confirm smooth playback with a GTX 1050 GPU, GTX 1650, and RTX 2060. Haven't tried going back down to the onboard graphics in the i7-8700.
Changed all the source url's to Fubo, since that source appears a bit more stable than the NBC site. I would still see a bit of stutter on NBC sources, every once in a great while. But overall, it is great to have the old TVE channels back, and also be able to add some channels that never supported TVE, like Smithsonian.
Thanks again for all the work put into this, still very early solution.
FYI, found my problem. I had restarted the PC and manually started the Chrome Capture executable, totally forgetting that I had set up task scheduler to start it. So I had two instances of it running, which of course doesn't work too well. Ooops!
That did it. Thanks!
Regarding the black bars around the display. I found that I can toggle to full screen display (no black bars) by pressing the [ f ] key on the keyboard of my Chrome-capture-for-channels server (Windows 11). I haven't yet figured out a way to retain full screen after channel changes. Video resolution is 1920 X 1080. I thought maybe some of you clever coders could figure out a way to automate this keypress action after each channel change. Edit... this works when streaming YTTV channels. Haven't tried it yet for other sources.
Run your display at 2560 x 1440. I run this resolution with a headless hdmi display. No borders.
2 Likes
Thanks, but the max resolution of my current server hardware is 1920 X 1080.
Do you mean your monitor?
No, the integrated video graphics card. It would require an upgraded plug-in video card.
I had the same issue with my old I7. Bought a cheap headless PC and voila, no issues.
1 Like
Yeah I think that's the solution for a lot of these black border issues, spend a few hundred for a mini PC (refurb or new). The integrated graphics from the last couple years apparently work way better. I have an older i5 with an Nvidia GTX 750ti card and have the border issues.
1 Like
Something to note regarding playback.
I've noticed that when I playback a CC4C station on a FireStick there is a significant lag/stutter in the video playback. This lag/stutter is not seen when I playback same channel on an AppleTV.
Any options to optimize the video specifically on a FireStick?
I believe the black border issues are a resolution issue on the capture machine, not necessarily a hardware issue. You need to be greater than 1920x1080 to get rid of the bars completely. A cheap 4K HDMI dongle can do the trick, and just make sure the chrome capture window is running on the virtual display, that has the resolution above 1080p. Less powerful CPU/GPU will likely show issues when trying to capture more than 1 stream.
1 Like
Yeah I mentioned above I already tried increasing res to 4K and I have a 4K LG TV that it's hooked to. Didn't change the borders.