Pause buffers and seeking major issues

Channels Fire TV
#1

After seeing the progress that's been made with Channels DVR in the past year, I was super excited to try it out. I signed up, got it all set up, and installed it on my Fire Stick with my HDHR Prime.

However, I'm surprised and confused by three issues:

  1. Seeking forward and backwards inside a program is difficult, since it does not show you the seconds of the timestamp. You really don't know how far or back or forward you have gone without accurate timestamps if you are looking for a very specific scene in a program.
  2. The vertical line that is supposed to indicate your current position does NOT SHOW YOUR CURRENT POSITION. It is always fixed to the far right of the playback buffer. This is a massive issue.
  3. It seems that there is a limited pause buffer for Live TV, only about 10 minutes!? I assume this is because Channels is not using the DVR server to store the pause buffer, but rather caches it locally??

Am I missing something here?

#2

That doesn’t sound great. We’ll get this sorted out for you. What model of Fire TV Stick do you have?

#3

For 2, I've noticed this problem with the Android client. Sometimes it does correct itself when the timeline changes, though.

For 3, yes, the buffer is local. There is no option for a buffer shared on the server.

#4

This is a bug which has been fixed and will be released next week.

#5

You are correct about # 3 I hope that they move the buffer to the server... buffering locally is really limited.

#6

Thanks for the quick replies everyone.

This is the Fire TV Stick 4K.

I also noticed just now, that if I use TV Everywhere to watch a stream, I get up to 30 minutes of a buffer. After 30 minutes it unpauses and all video on screen turns red and blue. As I was seeking forward and back, it crashed the application.

I don't understand why Channels stores the buffer on the server for TV-E, but not for HDHR streams. If the DVR is buffering TV-E, why is the TV-E playback buffer only 30 minutes? Even moreso, why is any local buffer is used on client devices at all? The constant writing of dozens to hundreds of gigabytes per day to the NAND will greatly shorten its lifespan. Even Google warns users of the Live Channels app that using their internal storage for pausing TV is not advised for this reason.

If this is the expected behavior and not a glitch, as the other users have suggested, this is a real shame. It's not acceptable and completely kills this product sadly.

1 Like
#7

We're still working on getting out that release and making sure that we fix all of the seeking bugs you're running into, but I realized that there's a lot of background that we should go over to help set the context for how and why things are working the way they are.

Why is there a Live TV buffer on the client at all?

We sell two products:

  1. a Live TV only client that connects directly to the HD Homerun
  2. a DVR product (Channels Plus) that includes a client and a server component.

Because the Live TV client doesn't have any server component, we must store the Live TV buffer on the client because there's no where else to store it.

Why isn't the Live TV buffer just stored on the DVR if one is available?

We've tried a lot of things and made changes over the years based on customer feedback and support requests and found that the over-all experience for watching Live TV was much better when having the client connect directly to the HD Homerun.

A few of the biggest issues were:

  1. Any issue with the network (WiFi interference, bad cables, misconfigurations, etc) became that much more damaging to the quality of the steaming by adding another node to the system. People would have more pauses, glitches, streams not starting, etc.
  2. Any disk, CPU or other temporary spike on the DVR could cause stalls in the stream
  3. Because there are more components involved, it just takes more seconds from when someone presses on a channel and when they start seeing video

Because of those issues, we decided that if the client was able to directly connect to the HD Homerun, we will do that.

Why isn't the length of the client buffer always the same?

When we are playing, we also monitor the available disk space and make sure that we don't run out. If we are getting close, we will limit the buffer.

Why is the buffer longer for TVE feeds than HD Homerun feeds?

Most cable and broadcast TV streams are MPEG2 at around 15mbits/second. Most of the TVE feeds are H.264 at around 3-4mbits/second. Because of this 5x difference in storage, we are able to fit much more in the buffer for TVE streams than HD Homerun streams.

How can I get a Live TV buffer on the DVR instead of the client?

If you change the DVR Streaming Quality setting for "Home Streaming" in the app from "Original" to "1080p 8Mbps" it will use the DVR as a cache for Live TV.

2 Likes
#8

Thanks for the informative post. I have a further question, though. If you enable tuner sharing, you are already using the DVR server as the point from which all streams reach the clients. As such, would it be possible to have the DVR maintain the buffer when tuner sharing is enabled (thus maintaining the original bitrate, which although rare, would allow for higher bitrate cable/OTA feeds to use the server buffer without loss of quality)?

1 Like
#9

Buffer on the Client is the main reason I do not use Channels DVR to view LiveTV. I rather use HDHomeRun dvr or SageTV for LiveTV.

The HDHomeRun app if you do not have the DVR installed it buffers to the Local Client ... if you have DVR installed it buffers to the DVR server.

#10

I think it was mentioned previously that the tuner sharing buffer is rather small. And what if you have more than one client using tuner sharing and one skips way back, or pauses, or...

I could see the use cases and understand, but it would be a mess and I think technologically impossible since Channels DVR and it's clients don't have exclusive control over the tuners or streams being utilized like some closed box (TiVo for example) systems do.

#11

I understand the current tuner sharing buffer is small. But changing the default/max buffer size for tuner sharing to me makes more sense.

Plus, since the basic foundation for this exists in tuner sharing, expanding that feature seems like the next logical step.

#12

Just my personal opinion (since I came from TiVo which has a ~30 min buffer per tuner).
If I want a buffer like that in Channels, I record it and chase the recording (view it while recording).

I really don't think the devs would be able to pull off what you're asking for, but I'll let them speak for themselves.

#13

Just trying to understand the use case and limits of this.

How big is that cache and is it for all clients using tuner sharing that have that "1080p 8Mbps" setting in the app?

Could you have 3 or more clients watching the same channel all day and it will cache the whole day for them all where some pause while others skip about forward/backward, etc?

I also assume in this case a web browser isn't considered a client since the web ui doesn't have "Original" quality and maxes out at 1080/8Mbps, sometimes having to transcode and other times remux depending on content.

Forgot to add and thinking out loud, since HDHR devices are limited to the number of tuners thay have and a TVE device is basically unlimited tuners (streams), how would that fit in?

#14

Setting the quality to anything besides original forces the server to transcode the video, so it has to do some buffering as well. Not sure how much it buffers in that case.

#15

Not really. The way that tuner sharing is implemented (by providing the exact same interface as the HD Homerun to the clients) doesn't provide any way to rewind, etc. It would have to be a different mechanism for providing a buffer that could be rewound.

The server keeps a separate cache for each client that contains the last hour of video that that client has been watching. If there are 3 clients watching the same show, there are 3 caches of 1 hour.

The only limit to the number of concurrent clients is the number of tuners, amount of bandwidth, and CPU of the DVR system.

1 Like
#16

Thanks for that informative explanation.

1 Like
#17

Thank you for the clarifications. I can now see that a shared DVR buffer on the server would require what appears to be a few changes to the structure of Channels itself. Hopefully these features will come along with Channels DVR 2.0, along with PIP, guide overlay, and multiple concurrent streams to toggle between (à la DirecTV DoublePlay).

1 Like
#18

True?

#19

There's definitely a lot more we do with our native apps that we aren't able to do with the web player. It's unable to play MPEG2 so it always must be transcoded to H.264, it doesn't give us control over when to switch bitrates for ABR, etc.

1 Like
#20

Thanks, most of this post should be made into a helpful sticky.

1 Like