I think server responsiveness would factor into it as well.
1 Like
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?
1 Like
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
1 Like
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?
1 Like
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?
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
I have other TVs with FireSticks. They don't have the problem. All use WiFi (not in the 5 GHz band). After that realization I was able to fix the problem.
The only TV that was wired used the Amazon FireStick network interface module. I removed the Amazon wired interface module and instead used WiFi on the poorly performing FireStick. The 2.6 MHz band WiFi speed tested 80 Mbps and the 5 MHz band was 90 Mbps. Previously, the wired network speed had tested at 100 Mbps. The FireStick then behaved well when fast forwarding commercials, etc.
So something is going on in the Amazon wired interface module. Perhaps it is buffering? I had purchased the wired interface module to presumably speed up my network connection to the FireStick. That was a waste of money.
Thanks for your patience and assistance.
1 Like
Just to add something to this discussion. I recently updated my Channels DVR from a Windows 10 Core i5 PC to a Windows 11 Core i7 with double the RAM and a much more recent (9th gen) processor.
My clients are Nvidia Shields. The 30-second skip and fast forwarding worked instantly on my old setup even though my PC was taxed more (I also run a Blue Iris server on it). The 30-second skip on the new server has a long pause (2-5 seconds) when skipping. Clients and connections are still the same. Speedtest shows to channels DVR shows 991 Mb/sec and latency under 2 (jitter is under 1).
Not sure why it worked so well under the prior setup when all I did was replace the server to something more powerful.
A couple of questions for those in the know....
- Is there anything else on the server that could be causing he delay issue? NIC settings, etc.?
- What does the Buffer Protection setting on the client do? I think it is 30 seconds by default, should I bump this up to be longer? Or is this setting only for live shows?