Had the same issue a few days ago with two recordings while a third recording happening at the same time wasn't affected.
2024/02/03 04:13:07.113874 [DVR] Error running job 1706961600-74: failed after 36.825867161s: hls: temporary failure while downloading: hls: timeout while waiting for data
2024/02/03 04:13:25.079201 [DVR] Error running job 1706961600-72: failed after 32.237773997s: hls: temporary failure while downloading: hls: timeout while waiting for data
Hmmmm ok. Just happened again with no ping loss. Oh well...
This 
I imagine we'll see more of this on Sunday with all the Super Bowl streaming going on.
"And the entire HLS session gave up after 40 seconds of not succeeding in downloading a new segment."
Is there a way to change it to 60 or 90 seconds before it gives up and throws an error? Or better yet maybe force a retry or an automatic reconnect? Something like "Connection Timeout".... 'Attempting to Reconnect' and it auto-reconnects? Or at least a setting to enable/disable such action?
Just a thought. Thanks for all the great work.
Also use pingplotter instead of ping.exe in windows. Pingplotter will give you statisitics for each hop. You may have packet loss to one of the hops with your isp or something .
No, if it's taking that long, there's something wrong enough that it warrants giving up.
There are a number of reasons why this isn't something we're going to do, but to just explain one of them: When playback restarts, the old buffer is lost. If we automatically reconnected when you had gotten up for a moment, it could happen that you would come back and have no idea why you can't rewind anymore.
When you see the error, does it instruct you to press Play to restart? Does it work when you do that?
This generates output that is more forum friendly for copy/paste (and it's free)
WinMTR Statistics
| Host | % | Sent | Recv | Best | Avrg | Wrst | Last |
| OPNsense.lan | 0 | 27 | 27 | 0 | 0 | 2 | 0 |
| REDACT | 0 | 27 | 27 | 8 | 10 | 25 | 10 |
| REDACT | 0 | 27 | 27 | 10 | 13 | 28 | 21 |
| REDACT | 0 | 27 | 27 | 9 | 14 | 25 | 17 |
| lag-27.rcr01lsancarc.netops.charter.com | 0 | 27 | 27 | 11 | 13 | 29 | 14 |
| lag-26.lsancarc0yw-bcr00.netops.charter.com | 0 | 27 | 27 | 12 | 14 | 25 | 15 |
| 066-109-009-199.inf.spectrum.com | 0 | 27 | 27 | 11 | 13 | 18 | 13 |
| ae9.ctl-lax2.netarch.akamai.com | 0 | 27 | 27 | 12 | 24 | 75 | 52 |
| a184-50-27-50.deploy.static.akamaitechnologies.com | 0 | 27 | 27 | 12 | 14 | 25 | 14 |
I posted in your other TBS thread yesterday that my TBSHD (TVE-Hulu) is down. It's day 2 and it still doesn't work. You replied with some eyes 
. I am not sure what that means?
Link here: No TBS West. Lost local Fox and discovery channels. YTTV - #10 by troyhough
This is the error I am getting today still:
2024/02/09 10:51:03.740293 [ERR] Could not start stream for TVE-Hulu ch6033 TBS: TVE: Could not fetch playlist from turnerlive.akamaized.net: GET: https://turnerlive.akamaized.net/hls/live/572096/tbse/noslate/tv/master.m3u8?hdnts=exp=1707497762~acl=/hls/live/*~id=b716f441706eaaf7a6e330d18df8f918-1707497763~hmac=0eb380dcb3ea20420ac242728766d4e189ee7d01c3c333848a57ff87687289cb: 403 Forbidden
We are looking into it but it appears these channels may not be available to Channels DVR any more.
Thanks for replying @tmm1 I have since updated to 2024.02.09.0659 and it worked immediately after. Not sure if it was corrupt/stuck but all good now!
Ok TBSHD just did another "Connection Lost". I'll post the log as well as the WinMTR stats for the entire duration.
2024/02/09 12:54:41.008787 [SNR] Rewriter statistics for 192.168.1.150 (Office) for ch6033 TBS: discontinuity_detected=0 transport_errors=0 saw_pcr=true saw_pmt=true highest_pts=3452.862233
2024/02/09 12:54:41.008787 [SNR] Buffer statistics for 192.168.1.150 (Office) for ch6033 TBS: buf=0% drop=0%
2024/02/09 12:54:41.008787 [SNR] Streaming statistics for 192.168.1.150 (Office) for ch6033 TBS: timeouts=2 segment_timeouts=2 playlist_timeouts=0
2024/02/09 12:54:41.047390 [TNR] Closed connection to TVE-Hulu for ch6033 TBS
2024/02/09 12:54:41.047390 [TNR] Error during live stream for ch6033 TBS: failed after 33.9231296s: hls: temporary failure while downloading: hls: timeout while waiting for data
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|---|---|---|---|---|---|---|
| 192.168.1.1 - 0 | 5403 | 5403 | 0 | 0 | 9 | 0 |
| REDACT - 0 | 5401 | 5401 | 0 | 3 | 75 | 1 |
| REDACT - 0 | 5402 | 5402 | 0 | 3 | 112 | 2 |
| REDACT - 0 | 5401 | 5401 | 2 | 4 | 94 | 4 |
| 206.126.235.4 - 0 | 5401 | 5401 | 3 | 24 | 645 | 8 |
| a23-195-81-48.deploy.static.akamaitechnologies.com - 0 | 5401 | 5401 | 2 | 3 | 168 | 3 |
| ________________________________________________ | ______ | ______ | ______ | ______ | ______ | ______ |
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Are you watching the channel while recording it?
2024/02/09 12:54:41.008787 [SNR] Rewriter statistics for 192.168.1.150 (Office) for ch6033 TBS: discontinuity_detected=0 transport_errors=0 saw_pcr=true saw_pmt=true highest_pts=3452.862233
highest_pts=3452.862233 = 57 minutes, 32 seconds
2024/02/09 12:54:41.047390 [TNR] Error during live stream for ch6033 TBS: failed after 33.9231296s
33.9231296s = 33.9 seconds
Appears their CDN edge server may be having issues. Pinging w/ICMP and streaming HTTPS TCP/IP are different.
I am not recording it. Just watching it. Is there a diff address to ping test?
This is not a ping level issue. They are changing their TVE streams and these old ones are not working reliably anymore. The new ones are DRM.
Does DRM add additional reliability?
Is this a way of saying... "enjoy it while it lasts"?
This
DRM == Digital Rights Management aka "Encrypted, if you have to ask how to decrypt then you can't afford it."
Im pretty familiar with DRM via the disastrous ATSC3 rollout 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
