I have noticed that sometimes it take some time to jump forward, jump back, and skip commercials using the ATV remote. I would right click, get a pause of around 5 seconds, etc. Then, even in the same program, it’s working well.
Is this related to my home wifi? If so, how? Perhaps the show is not fully buffered in ATV yet?
Yes, the speed at which you can seek is completely dependent on the network throughput available. If your network speeds are slow, seeking will be slow.
I think server responsiveness would factor into it as well.
My fast forwarding is too slow.
I have a 100 MB/s hardwired connection to everything involved with Channels DVR. I'm using a 3 months old, Win10 mini-PC, that has 4-cores and 8GB of memory. The TV program is a new FireStick 4K Max that has about 8 GB of free memory.
It seems to be a buffering issue, not network throttling. The first 1-3, 30 second FF steps are very fast (less than .25 sec), after that it takes much longer (2-10 sec) for additional steps.
What does the speed test feature inside the Channels app say?
How can I run this test?
Settings > Support > Test Speed
Sorry, I can't find Speed Test under Settings.
On your FireTV inside the Channels app?
Found it:
100 MBPS and Latency of 2.71 ms
That's the issue then, it should be closer to 1000mbps. 100mbps is 12MB/s and 1000mbps (gigabit) is 125MB/s
Not much I can do unless I replace my LAN cables or try faster wireless connection, right? Is there no setting for the frame buffer size in the FireStick memory?
Why doesn't the DVR program move the pointer ahead to the next block of images on disk (30 seconds ahead or back), then start sending at that position. Does the program have to send all the frames between now and the next display point 30 seconds ahead before resuming the display?
The issue I’d like to see fixed occurs when I need to step forward manually through a commercial. Generally, I need to move ahead in 1-2 steps until I see the commercial end. Sometimes I have to wait up to 5 seconds between steps because the screen refuses to update after each step forward (or reverse if I overshoot the desired point) command. The wait time between steps is variable but can be 5 seconds. This is true for steps forward or reverse.
Example of sluggish “fast forwarding”
Try skipping quickly ahead 5 min during playback of any program. The position pointer will move ahead quickly in 10, 30 second steps. But then no screen updates will actually occur until about 4-5 seconds after the last step request, during which time the display is frozen.
The time to resume picture updating maxes out at about 4-5 sec after the step forward commands stop, no matter how many step ahead steps are requested. The resume playback starts up after about 1-3 sec for small number of steps.
I will guess that the Channels code is waiting to update the frame buffer in the TV receiver before it resumes playback.
Testing was done on the Windows 10 computer (that is running Channels DVR) monitor and on a remote FireStick TV.
For the above example, why doesn’t the software simply advance the disk read position in 30 sec intervals (or one 5 min interval) then display the requested new playback position after a small amount of time? Instead of waiting about 4 sec for the entire buffer to transfer to the TV, so I can determine if the commercial is over?
When stepping is being used, could the screen show a very small, initial portion of the buffer, instead of waiting until the full buffer is received? It could then begin continuous screen updates after the buffer continually fills.
Did you resolve your network issue? I can't replicate your findings. I can skip forward and back through the entire recording and every skip occurs instantly, with picture resuming instantly. It probably helps that I am hardwired gigabit to server and all clients. But maybe you could fix your wifi.
When seeking to a new location, the app will first consult the local cache for the data, if it is not available it must grab it from the server.
When you are skipping forward multiple times in quick succession after exhausting the cache, the app will start to download the data after each skip, then have to discard it as it starts to download the next place you have seeked to.
Because the videos we are talking about are large, there is just a practical limit to how quickly the video can be downloaded. You'll definitely find better performance on a gigabit connection vs 100mbit.
We are continuing to find ways we can improve the performance of this, but there will always be limits we can't overcome on non-gigabit connections.
My (simplified) suggestion to solve this issue is:
On the first FF click clear the TV device buffer and fill it with one frame 30 sec into the future, from disk. Wait for 500 ms (adjustable setting human response time parameter) to see if another FF click occurs.
If a new fast forward FF is received, send a single new frame into the device buffer and wait again (500 ms) to see if an additional FF is detected. If FF is received then advance the disk one 30 sec step, and repeat, if no FF occurs, then start filling the buffer as is currently done.
So as long as the user keeps clicking the FF the buffer will be updated by single frames that are 30 sec apart (or whatever the skip ahead setting is set to).
are you trying to add pauses and still frames? I think you are trying to solve a problem that doesn't exist. Just get your network up to a decent speed and your issue will go away.
As a workaround for your slow network, why not just stop 30-sec skipping through the commercials and use auto-skip or the skip button or double-click forward. Then you are only loading a new disk position once.
I seriously doubt the sluggishness is caused by a network being slow. I see a 4 second delay and it should be much faster than that. I would need to increase the network speed by a factor of 10-20.
The device buffer is set to 30 seconds (the minimum).
Plus what sense does it make to send the entire buffer every time the screen has to be stepped ahead? All that is required to see a single future frame.
Your understanding of how things work is not correct. It's not possible for the server to just end a single frame- video is not transmitted in frames, it is compressed and encoded. The bytes have to be transferred to the client and decoded to even figure out where the correct frame 30s ahead is. It is a bandwidth intensive process, especially when dealing with mpg recordings.
Seeking speed is directly tied to bandwidth available.
Like @eric said, we're looking into ways to make this faster and already have some improvements on Apple TV which will make it to Android TV in the future.