Roku presents a particularly difficult platform for synchronizing with media which arrives from another computer (Tablo), especially if noise corruption is present.
Having also witnessed, like zippy, very long and very frustrating periods of very unstable Tablo / Roku performance over the nearly 8 years of Tablo ownership, I have seen the struggles which software engineers have encountered trying to get synchronization. When the two devices, Roku and Tablo, are not synced in lock-step, the stalling, freezing, crashing, rebooting is inevitable.
Obvious changes have been made over the years by Tablo software people to recognize this issue, which I once described using software engineering parlance as a “software race” condition. Google this term if you want further clarification.
There is a very good reason why, for example, the deletion process has eventually, years later, been broken into two successive steps , first stopping the recording, then deleting the file. Similarly, adding extended time delays to slow the attempted synchronization process, affectively giving extra time for the two devices to avoid the race condition, uses the same design trick/philosophy.
Adding delays deliberately to prevent failures in both scrubbing the timeline (fast reverse or forward), and file deletion creates additional waiting time and makes jumping commercial breaks and file deletions take longer.
Operating systems on other players can use “semaphores”, (another software engineering term worth googling) to ensure lack step synchronization , thus avoiding longer waits and allowing fast scrubs, deletes, etc.
Therefore, having seen eight years of Roku issues, none of which have shown up in any substantial way on the numerous Apple TV, Amazon fire TV, nexus, or iOS players, I am not very surprised that we now have yet another round of this horse sh*t going on, eight years into the product life cycle.