Streaming corruption after time/fast forward

Channels DVR Server
#1

I have tried using 3 different servers to record/play back from my HD-Homerun Prime with CableCard. Latest version is a Rasp. Pi 4B w/4gigs RAM running PiOS Lite.

If I go into the filesystem and download the files to a computer and play them with VLC, they appear correct.

However, if I stream them to any client (including iPad, iPhone, AppleTV and Web browser), after a few mins I start to get this on the screen (see attached).

If things are streaming ok at the beginning, if I search ahead or even do a 15 second skip, it starts the spinner or immediately breaks up into similar corruption.

Any ideas on what's going on?

-Eric

Screenshot 2021-08-16 at 01.51.30 PM
Screenshot 2021-08-16 at 01.51.30 PM864×1854 158 KB

Screenshot 2021-08-16 at 01.51.51 PM
Screenshot 2021-08-16 at 01.51.51 PM860×1864 150 KB

#2

Is the Channels app streaming at home, and set to Home Streaming Quality: Original?

#3

Yes I'm at home on the same network using the app on AppleTV and iOS.

It's using the home streaming original quality.

Device is using a wired connection (although the phone when I tested was on Wifi but I don't have problems streaming direct from the HDPrime to my phone).

I don't think it's transcoding everything - and even it it was, it shouldn't just break and not recover if the buffering got overloaded.

-Eric

#4

Strange, at original quality the bytes should be transferred and played directly just like VLC does.

We need diagnostics submitted from the app after the issue occurs.

#5

I just submitted the diagnostics from the iPhone App.

And I've attached a link to a video which shows it happening.

#7

The video files are heavily corrupted on disk. You must have gotten lucky when you tried with VLC and gotten a file or watched a part that was fine.

2021/08/16 19:00:00.033430 [SNR] Statistics for "TV/WJLA 24-7 News ON YOUR SIDE at 1/WJLA 24-7 News ON YOUR SIDE at 1 2021-08-16-1830.mpg": ss=100% snq=98%,93%-100% seq=100% bps=8843499,3588544-8887136 pps=11,0-69 neterr=99%
2021/08/16 19:00:00.052311 [SNR] Statistics for "TV/Alison Krauss & Union Station Featuring Jerry Douglas/Alison Krauss & Union Station Featuring Jerry Douglas 2014-03-09 2021-08-16-1829.mpg": ss=100% snq=100% seq=100% bps=9194665,1487456-19243680 pps=59,0-1476 neterr=95%

Only five percent of the video packets are making it from the HDHomeRun to the RPI. Are the two devices plugged into the same physical switch or router?

#8

I work for a software company that also does video applications (not TV stuff), and what we have found is that VLC is good at dropping corrupted frames. Which makes it sometimes look OK, but with many missed frames.

#9

@muzicman0 thanks - that's probably exactly what happened to me.

As a followup, I moved the Pi to the same physical switch as the HDHomeRun and the problem seems to have stopped.

So I'm guessing the streams for HD video are very sensitive to packet loss or latency, even inside my home network. If a stream loses sync perhaps it's more difficult to reassemble them coherently via the Channels recording method than when just streaming from the HDHomeRun to their client? Just a guess.

I do probably have a few too many switches in-line to where the server used to be connected - but this does anecdotally show how even a 1gig wired network (using cheap $25 switches) can hamper a good digital video distribution setup.

Thanks everyone..

-Eric

2 Likes
#10

I have heard the same story from dozens of customers.

Exactly. The network stack on the HDHR is very sensitive, and even hops across switches can lead to packet loss.