Congrats, Bill!
Looks like Eric and Maddy had it right the whole time, network requires 1 gbit for skipping to be smooth.
It doesn't need 1gigabit, but 100mbit is a bit slow for seeking with MPEG2 at a pace that feels good.
MPEG-TS (the video container format used by broadcast TV) does not contain any indexing to allow for a client to know the byte offset of a particular time offset in a file. Not having this index is part of the reason why it's so easy for clients (TVs, etc) to watch a stream and for us to record at any point, etc.
Because there is no index, it requires the client do a binary search of the file which requires it to download a large number of parts of the file to identify exactly where you are looking to seek.
There is no perfect file format, there is no technical solution that will work for all situations that possibly exist. What we've done is identified the best solution that provides the best trade-offs for the use cases that we have. We've decided to trade benefiting from higher network performance in exchange for lower delays in playback and lower CPU requirements on the server as our default. If you don't like that trade-off, you can select "Stream" for "Original Quality Delivery" instead of the default of "Direct", which will be slower to start, use more CPU and IO on your server, but may be quicker in some instances for seeking.
1 Like
Thanks for that explanation Eric! I don't really know how public domain software works, but SageTv software has been in the public domain for a long time. (5+ years since Google put it out there) I wonder if they have a clever way of doing these skips? Especially considering they even allowed us to edit how long a skip we wanted for each press, and in either direction and I never saw an issue with skips in the twenty years I've been using it, and back in the day, it was all 10 mbit networks at my house.
And those skips worked against all my my HDHR OTA mpeg2-ts videos, plus the same for mp4, mkv and avi video files. (oh the horror thinking back to those usb tuner dongles and that Hauppauge junk. Silicon Dust made DVR life so much easier. -Bill
We have to admit, Bill, that was back in the day when programmers had limits to work with.
We are happy with our design decisions and the trade-offs we've made. We have done an incredibly good job of handling a huge verity of environments and hardware choices. As I said previously, we also provide an alternative with the "Original Quality Delivery" setting that requires more processing on the DVR in exchange for less network traffic. We are unlikely to optimize for faster seeking time on a small capacity network beyond what we have.
Honestly, we've already put a lot more effort and energy in working around adversarial network conditions than any other streaming platform or service that I have found and on top of that, we spend a lot of time providing diagnostic tools to help identify bottlenecks to help understand and resolve issues that people have and want help with.
If you were to watch and seek around on Standard Definition video recordings with Channels you would also find that it was very fast to seek. HD broadcasts are in the 8-16mbit range which would (basically) not work on a 10mbit ethernet link considering overhead...
We deeply understand the physical constraints of the CPU, disk IO and network bandwidth that plays into the complex balancing to get the best result for our users and are very happy and proud of the result.
@Kryptonyte I'm not sure what the point of your continued snark is but it's all pretty offensive.
I once had a developer tell me that they could get 50 lines of Java done with 1 line of what they were using today. Is that really true?
What's truly offensive, is that even at a fraction of that efficiency, this DVR software still can't warn the user within a few minutes that a recording was missed, and why. How in the world did Kardatzke and his tiny little team (like yours) manage to pull off the truly extraordinary list of DVR features that SageTV has with such a terribly inefficient drawer of tolls?