The classical situation in a “real-time” client/server environment is that the client makes requests, and the server obeys. The client says “fast forward please” and the server response “here’s your next point to resume playback”.
If the server (Tablo) can keep up with demands from the client (Roku), the client is making requests such as:
Fast forward
Fast forward
Fast forward
And the server fulfills each demand shortly thereafter.
The critical word here is “shortly”.
Should requests be made at a speed which the server cannot abide, due to latency arising from hard disk delays or other Tablo resource issues, the client gets ahead in a way which ultimately breaks the essential synchronization between the two computer systems, Roku and Tablo.
If the hardware supports it, which the Roku does not, interrupts can be used to pend / delay The second and subsequent client request until the first one has been fully satisfied.
In systems where interrupts do not exist, a software approximation can be achieved using semaphores, locks, or flags to signal completion by one computer before the other computer starts another request cycle.,
Without these essential controls, the “race” problem arises where the receiving server needs to complete its service before the client makes the subsequent demand, and, if insufficient time waiting to send the next command is permitted, then premature sending takes place, and the synchronization breaks the lock step.
Although buffers can be constructed to attempt to overcome the race, the potential for loss of synchronization is not entirely mitigated.
Absent the availability of software semaphores or hardware interrupts,classical technique to solve such a problem is to slow down the requesting
client
so that enough time will ALWAYS be available for the worst case delayed server response. This solution unfortunately brings with it a penalty in scrubbing speed, making the whole process appear sluggish.
A similar situation arises when file deletion is requested by the client and the server needs to first stop recording, wait briefly, and then delete the file. This problem arises specifically when deleting files which are cURRENTLY being recorded.
Once again, a potential race situation is created.
If the server has not fulfilled the first step to stop the recording, and attempt to process the delete request prematurely, errors in improper file deletion then arise.
Not surprisingly, both for the case of incomplete file deletions leaving ghost icons on the Tablo desktop, as well as freezing and crashing problems when scrubbing have both occurred for months until the Tablo software added long and noticeable delays to these two processes. In the case of file deletions, there was never any dismissive finger-pointing by Tablo. In the case of freezing and crashing of the Roku however, Roku became the long awaited solution for many months with most attention, distraction being pointed to Roku. I am just trying to get back to a properly working solution here, and see similar issues and attitudes reoccurring over nearly 8 years of ownership of Tablo, much to my frustration.
gGood software people with the proper tools to analyze packet traffic, look at Netwerk activity, and use debuggers to step through these processes can quickly see and correct these problems, but only if they can be reproduced. Although many of us are experiencing these problems frequently, it is not consistent as a failure mode to the extent that beta testers or software quality assurance people can easily provoke.
A simple and very informative alternative is to temporarily insert time delays, typically using instructions in the code which are affectively wait/“no-ops” to slow things down, minimize the opportunity for a race, and see if this fixes the issue for all the users who are complaining. It takes very little time and very little coding effort, and need not be pushed out to all users. This is a much better and more proactive approach than waiting for Roku to bring out another release.
Larry