Transcoder error

Channels DVR Server Troubleshooting
#1

I've been noticing an interesting error sequence lately.

If I tune to a TVE channel it will sometimes fail with a transcoder error on screen (sorry did not capture the exact verbiage).

I will typically try to tune the same TVE channel again and get the same error.

I then tune to a different source (usually I pick an OTA channel) and once it loads exit it.

Last, I reselect the same TVE channel again and it loads and plays just fine.

Diagnostics submitted as ebca903e-9fe2-445c-9e76-57d644ae62ce

Here are the logs:

In this case I tuned 6114 twice and received the transcoder issue, then tuned 7.3 successfully and then finally 6114 successfully.

2023/09/26 10:35:17.231445 [HLS] Stopping transcoder session ch9042-dANY-ip192.168.1.100 (out=2h9m48.892011s finished=false first_seq=1 last_seq=4621)
2023/09/26 10:35:17.231538 [ERR] Error during stream M3U-ChromeCapture ch9042 CNBC: read |0: file already closed
2023/09/26 10:35:17.231554 [TNR] Closed connection to M3U-ChromeCapture for ch9042 CNBC
2023/09/26 10:35:17.244624 [SNR] Buffer statistics for ch9042 CNBC: buf=0%-2% drop=0%
2023/09/26 10:35:17.283657 [HLS] ffmpeg: chrome-CNBC: av_interleaved_write_frame(): Broken pipe
2023/09/26 10:35:17.283715 [HLS] ffmpeg: chrome-CNBC: Error writing trailer of pipe:: Broken pipe
2023/09/26 10:35:17.283738 [HLS] ffmpeg: chrome-CNBC: Error closing file pipe:: Broken pipe
2023/09/26 10:35:35.738693 [TVE] action=xvfb display=:923
2023/09/26 10:35:48.963237 [TVE] action=version product=Chrome/117.0.5938.88 jsVersion=11.7.439.16 protocol=1.3 revision=@be6afae4721209be42944bbcd325665f9f44563b
2023/09/26 10:35:48.964168 [TVE] action=page_ready chromeVersion=117
2023/09/26 10:35:48.964631 [TVE] action=navigate url=https://auth.sciencechannel.com/login-affiliates?returnUrl=https://www.sciencechannel.com/live-now&hostUrl=us1-prod-direct.sciencechannel.com
2023/09/26 10:35:48.966988 [TVE] action=request type=Document method=GET url=https://auth.sciencechannel.com/login-affiliates
2023/09/26 10:35:48.967001 [TVE] action=auth_domain domain=auth.sciencechannel.com
2023/09/26 10:35:48.967009 [TVE] action=scienceauth reason=login
2023/09/26 10:35:49.555714 [TVE] action=wait_for_page
2023/09/26 10:35:57.688354 [TVE] action=page_ready
2023/09/26 10:35:57.688402 [TVE] action=wait_for_page done=true reason=page_ready
2023/09/26 10:36:03.274298 [TVE] action=click_interstitial
2023/09/26 10:36:03.277597 [TVE] action=tvejs msg="scienceSelect: path=/login-affiliates"
2023/09/26 10:36:03.359375 [HLS] Couldn't generate stream playlist for ch6114-dANY-ip192.168.1.100: Timeout waiting for session to start after 12s
2023/09/26 10:36:03.359491 [HLS] Stopping transcoder session ch6114-dANY-ip192.168.1.100
2023/09/26 10:36:03.398507 [TVE] action=wait_for_interstitial timeout=12s
2023/09/26 10:36:04.152292 [TVE] action=request type=Document method=GET url=https://api.auth.adobe.com/api/v1/authenticate
2023/09/26 10:36:04.404886 [TVE] action=request type=Document method=GET url=https://sp.auth.adobe.com/api/v1/authenticate redirected_from=https://api.auth.adobe.com/api/v1/authenticate
2023/09/26 10:36:04.613364 [TVE] action=request type=Document method=POST url=https://youtube.auth-gateway.net/saml/saml2/idp/SSOService.php
2023/09/26 10:36:04.740514 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authbypass/firstbookend.php redirected_from=https://youtube.auth-gateway.net/saml/saml2/idp/SSOService.php
2023/09/26 10:36:05.224320 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authbypass/firstbookend.php
2023/09/26 10:36:05.264598 [TVE] action=request type=Document method=GET url=https://accounts.google.com/o/oauth2/auth redirected_from=https://youtube.auth-gateway.net/saml/module.php/authbypass/firstbookend.php
2023/09/26 10:36:12.958456 [TVE] action=page_ready
2023/09/26 10:36:12.958519 [TVE] action=wait_for_interstitial done=true reason=page_ready
2023/09/26 10:36:12.958575 [TVE] action=wait_for_auth timeout=24s
2023/09/26 10:36:12.958602 [TVE] action=fill_form u=email_address
2023/09/26 10:36:12.962401 [TVE] action=tvejs msg="googleLogin emailPicker"
2023/09/26 10:36:12.964352 [TVE] action=tvejs msg="googleAccountPicker"
2023/09/26 10:36:13.805908 [TVE] action=request type=Document method=GET url=https://accounts.google.com/signin/oauth/consent
2023/09/26 10:36:13.805928 [TVE] action=interstitial
2023/09/26 10:36:14.082269 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authgoogle/linkback.php redirected_from=https://accounts.google.com/signin/oauth/consent
2023/09/26 10:36:14.947087 [TVE] action=fill_form state=done ignored=true err=&cdproto.Error{Code:-32000, Message:"Inspected target navigated or closed"}
2023/09/26 10:36:15.780669 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authSynacor/DiscoveryAssociationsResume.php
2023/09/26 10:36:15.828993 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authbypass/lastbookend.php redirected_from=https://youtube.auth-gateway.net/saml/module.php/authSynacor/DiscoveryAssociationsResume.php
2023/09/26 10:36:15.878543 [TVE] action=request type=Document method=GET url=https://youtube.auth-gateway.net/saml/module.php/authbypass/lastbookend.php
2023/09/26 10:36:15.969604 [TVE] action=request type=Document method=POST url=https://sp.auth.adobe.com/sp/saml/SAMLAssertionConsumer
2023/09/26 10:36:16.126573 [TVE] action=request type=Document method=GET url=https://us1-prod.disco-api.com/v1/gauth/callback/00eab5e0-7693-4232-8e3d-907162ffd8e1 redirected_from=https://sp.auth.adobe.com/sp/saml/SAMLAssertionConsumer
2023/09/26 10:36:17.013779 [TVE] action=request type=Document method=GET url=https://auth.sciencechannel.com/gauth-sync redirected_from=https://us1-prod.disco-api.com/v1/gauth/callback/00eab5e0-7693-4232-8e3d-907162ffd8e1
2023/09/26 10:36:17.013794 [TVE] action=scienceauth reason=sync
2023/09/26 10:36:21.281344 [HLS] Stopping transcoder session ch6114-dANY-ip192.168.1.100
2023/09/26 10:36:25.414082 [TVE] action=page_ready
2023/09/26 10:36:25.414138 [TVE] action=check_result
2023/09/26 10:36:25.465347 [TVE] action=request type=Document method=GET url=https://www.sciencechannel.com/live-now
2023/09/26 10:36:25.621093 [TVE] action=scienceauth done=true
2023/09/26 10:36:25.621114 [TVE] action=authed
2023/09/26 10:36:27.418863 [TVE] action=click_interstitial
2023/09/26 10:36:32.380386 [TVE] action=cookies num_domains=1 num_cookies=1
2023/09/26 10:36:33.714908 [HLS] Couldn't generate stream playlist for ch6114-dANY-ip192.168.1.100: Timeout waiting for session to start after 12s
2023/09/26 10:36:33.715010 [HLS] Stopping transcoder session ch6114-dANY-ip192.168.1.100
2023/09/26 10:36:34.086086 [TNR] Opened connection to 10A1FC47/2 for ch7.3 WITN-ME
2023/09/26 10:36:34.087952 [HLS] Starting live stream for channel 7.3 from 192.168.1.100
2023/09/26 10:36:38.299888 [HLS] Probed live stream in 619.030352ms: mpeg2video 704x480 tt 1153827bps
2023/09/26 10:36:41.329161 [HLS] Stopping transcoder session ch7.3-dANY-ip192.168.1.100 (out=4.125744s finished=false first_seq=1 last_seq=1)
2023/09/26 10:36:43.649607 [TNR] Closed connection to 10A1FC47/2 for ch7.3 WITN-ME
2023/09/26 10:36:43.653935 [SNR] Statistics for ch7.3 WITN-ME: ss=68%-69% snq=72%-73% seq=66%,0%-100% bps=1367136,0-2152224 pps=122,0-192
2023/09/26 10:36:43.653953 [SNR] Buffer statistics for ch7.3 WITN-ME: buf=0% drop=0%
2023/09/26 10:36:48.839031 [TVE] stream timestamps: motortrend: start_at=2023-09-26T10:35:48-04:00 end_at=2023-09-26T10:36:20-04:00 live_delay=26.45002699s
2023/09/26 10:36:48.839160 [TNR] Opened connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.841088 [HLS] Starting live stream for channel 6114 from 192.168.1.100 (bitrate=5535)
2023/09/26 10:36:48.841234 [TNR] Closed connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.906265 [TVE] stream timestamps: motortrend: start_at=2023-09-26T10:35:48-04:00 end_at=2023-09-26T10:36:20-04:00 live_delay=26.531260927s
2023/09/26 10:36:48.906338 [TNR] Opened connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.908607 [HLS] Starting live stream for channel 6114 from 192.168.1.100 (bitrate=5535)
2023/09/26 10:36:48.908715 [TNR] Closed connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.972312 [TVE] stream timestamps: motortrend: start_at=2023-09-26T10:35:48-04:00 end_at=2023-09-26T10:36:20-04:00 live_delay=26.580306673s
2023/09/26 10:36:48.972417 [TNR] Opened connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.973921 [HLS] Starting live stream for channel 6114 from 192.168.1.100 (bitrate=5535)
2023/09/26 10:36:48.991878 [TVE] stream timestamps: motortrend: start_at=2023-09-26T10:35:48-04:00 end_at=2023-09-26T10:36:20-04:00 live_delay=26.613874587s
2023/09/26 10:36:48.991962 [TNR] Opened connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:48.993370 [HLS] Starting live stream for channel 6114 from 192.168.1.100 (bitrate=5423)
2023/09/26 10:36:48.993450 [TNR] Closed connection to TVE-YouTubeTV for ch6114 MOTORTREND
2023/09/26 10:36:50.280076 [HLS] Probed live stream in 1.305673101s: h264 1920x1080 progressive 2690368bps
2023/09/26 10:37:09.520912 [DVR] Deleted #25295 /volume1/ChannelsDVR/TV/The Young and the Restless/The Young and the Restless S50E165 2023-05-25-1230.mpg (user)

#2

With TVE + YTTV, what you see is what you get. There are reauth attempts that are slowing things down. I'm not sure why you're using transcoding in the first place.

#3

I’m not using transcoding. That’s just part of your onscreen error message.

2 Likes
#4

You're using HLS in the home. I'm not sure what your streaming settings are but we recommend original quality at home.

3 Likes
#5

I understand that I'm using HLS. That's a recent change that I made because I found that by using HLS I don't get the annoying timeline pop-up every time there's a nano-second glitch in the source. Not all of us live in an area where we have great signal strength 24x7. Now, if we had an option (like requested) to turn off the timeline except when we pause, fwd/rwd, or otherwise pull it up I could move back to original.

But, the point is I didn't ask for a critique of my settings or for you to bash my provider. Especially since you didn't say that HLS is the cause.

BTW, I think YTTV is probably one of the more dominant providers out there so maybe some cycles could/should be spent on improving the experience. Yeah, I get it, they are causing some problems but why not see what can be done to help your customers instead of being dismissive?

Bottom line here is I see a somewhat (I can't cause it to happen) repeatable issue where source A won't tune and by tuning source B and then going back to A then A works. That's what I'm reporting and asking for comment on.

I've been a user of Channels for over 7 years I think. I've worked with you guys on a number of problems and enhancements. I'm not asking for special treatment. But, what I am asking for is to address some of the annoyances that a lot of us have reported over the years rather than adding pickle ball to the sports category.

I read the forums everyday (check - I don't think I'm wrong about that). And, more and more what I see is blaming the user, the network, the provider or the underlying OS. Credit where credit is due. I'm not saying this is always the case. Certainly you fix bugs.

Frankly, I think you could spend some time on the squashing some bugs and adding some usability features. Things like being able to disable rather than delete a source. Or, maybe giving us the option to use the native player so we don't have PIP or HomePod issues. I get it, you've developed a player because of lack of support for mpeg, but how much of the content is truly mpeg anymore?

You guys still have the VERY best solution out there. I know, I routinely test others. And, you provide fantastic support. But, I and I think a couple of others, are growing tired of the finger pointing.

Kudos still for all that you do. Great product! Would just like to see it get better and better!

1 Like
#6

The issue you're experiencing is specific to HLS. I understand that you have reasons to use HLS, but that is the tradeoff.

#7

If you are getting pausing with TVE then you likely have network issues. Either between the server and the TVE source or the client and the server. I have zero issues with TVE pausing. I have everything hardwired and a standalone server.

#8

It sounds as if your OTA source is not super-consistent, and that is why you are asking the server to handle distributing the streams (for its error correction). If that is the case, I can completely sympathize with your situation.

However, have you also tried with original delivery and tuner sharing? That way nothing is transcoding, but the server handles the streams (and maintains a small buffer), which seems like it would be the best of both worlds. (Your posts have not indicated whether this was an avenue you attempted; and I ask because tuner sharing is not enabled by default.)

1 Like
#9

Yes, to both tuner sharing and original delivery. I've had it set that way for the last 7 (almost years) in two different houses. Neither had great OTA reception.

And, you're also correct about having the server do the error correction. The timeline popping up because of the slightest stream issue - seriously not noticeable most of the time in the show - is very annoying.

I'd really like to see either 1) address the HLS issue; whatever it might be or 2) provide more user control over the timeline showing up as I said earlier.

#10

How many times per show would you guess this happens?

Honestly, without more details like the specific error message on the screen and diagnostics from the client after that happens, it's hard for any of us to know specifically what set of circumstances are causing the problems you're seeing and how we would best fix them.

I see some Chrome Capture sessions, I see a TVE YTTV re-authenticate that caused the HLS session to timeout...

Part of the reason why @tmm1 said what he did about HLS is that there are some fundamental aspects of the way that HLS works that are in conflict with what we're trying to do with TVE.

Everything about HLS expects for data to be ready as soon as the stream is initiated, which ends up not being the case with these TVE feeds that need to re-authenticate. We have to delicately balance timeouts to try to make the most connections work the first time while not making it so that your video player spins for 2 minutes if you really are on a network connection that can't connect to your DVR.

We can certainly continue to try to improve the behavior of TVE re-authentication with HLS and continue to try to improve the behavior of the timeline when you experience OTA reception issues, but making these changes without negatively impacting other parts of the experience takes a lot of detailed work and understanding.

1 Like
#11

Thank you Eric. I appreciate your reply. The message on screen indicating a transcode error happens once in a while. I’ll get the exact text the next time I see it.

The timeline popping up when there’s a slight glitch in the feed can happen frequently during a show. It also varies though due to weather conditions. We live on the coast on the Outerbanks of NC. The nearest stations are 50ish miles away. Having access to OTA is critical for us to understand weather from a safety standpoint. For example, Ophelia this past weekend was a direct hit in our town.

For the timeline, if I had the option to disable it except for when pausing, fwd/rew or swiping up that would be perfect. What I don’t want is it popping up because of a slight glitch in the stream as a lot of times you can barely even see the on screen effect.

2 Likes
#12

Hi @eric

I just got the error this morning on another source than YTTV. The message on screen is “The Channels DVR Server had a problem. Press Play to try again. (Transcoder)”

In this case the source is a custom m3u channel.

#13

Please submit diagnostics so we can investigate

1 Like
#14

Yes, I just submitted them.

1 Like
#15

In order to capture the message I did change the setting back to HLS temporarily but have now gone back to original again.

#16

It looks like your camera is not responding or sending any video.

What behavior were you expecting here that we could improve?

2023/09/27 07:33:04.483962 [TNR] Opened connection to M3U-UniFiProtectCameras for ch8002 UniFi Protect
2023/09/27 07:33:04.484919 [HLS] Starting live stream for channel 8002 from 192.168.1.60
2023/09/27 07:33:04.499923 [HLS] ffmpeg: rtsp-Driveway:  rtsp://…..: Invalid data found when processing input
2023/09/27 07:33:04.502661 [ERR] Error during stream M3U-UniFiProtectCameras ch8002 UniFi Protect: exit status 1
2023/09/27 07:33:04.502681 [TNR] Closed connection to M3U-UniFiProtectCameras for ch8002 UniFi Protect
2023/09/27 07:33:04.502911 [HLS] ffmpeg: ch8002-dANY-ip192.168.1.60-remux:  Output file #0 does not contain any stream
2023/09/27 07:33:04.538434 [HLS] Couldn't generate stream playlist for ch8002-dANY-ip192.168.1.60: Stream stopped
2023/09/27 07:33:04.539112 [HLS] Stopping transcoder session ch8002-dANY-ip192.168.1.60
2023/09/27 07:33:04.539660 [ERR] Probe failed for live stream after 53.972022ms and 0 bytes
2 Likes
#17

Hi @eric

Please don't be concerned with the camera issue. That was on my end and is corrected. I was only trying to get you the onscreen error message that I had seen previously.

If I've overly confused the situation I apologize. And, if that's the case I can turn HLS back on and provide more realistic diagnostics from both the client and server when the problem happens again.

John

#18

I see. Okay.

So, looping back to that error and TVE and what you saw before: It's taking 40 seconds to re-authenticate a channel for you. If you're using HLS, it's going to show you an error like the one you're describing after a 10 second timeout. What you do in the mean time (tuning to an OTA channel, sitting there doing nothing, trying to watch the same channel again) won't really make an impact on what happens. After that 40 seconds of re-authentication finishes, it's going to be able to play like you expect.

When you stream directly, we are able to have longer timeouts that will just make your client wait for those 40 seconds and then start playing.

#19

Thank you so much for the explanation. It really helps to understand what is going on.

Is it possible to display a message? Something like "Reauthenticating: This will take about a minute" and have it wait for that period and the retry to tune.

Also, could we have an option to turn off timeline pop-ups due to stream glitches? Is that even possible?

#20

Not really at the moment. The way everything works just doesn't give the code that sort of visibility where it would need it.

It's something we're investigating.