Since I am STILL waiting with abated breath for my Tablo QUAD, I have a “Burning Question” about what seems to be a possibly annoying behavior regarding what happens when there is a disturbance in the incoming signal during an OTA Recording, to wit:
I think I have read in this Forum that, if there is even the SLIGHTEST anomaly in the incoming signal, that the Tablo software ENDS a Recording-In-Progress, and (I think) starts a new Recording starting from that point forward. Is this true?
If the above IS true, is there any sort of automatic Post-Processing that attempts to Concatenate those “Segments” together; so that Playback can be achieved without having to keep loading/playing multiple “Segments”, or does the User have to chase-around after those (possibly multiple) Segments?
Or, in the alternative, is there any place in Tablo Setup where you can set a (Hopefully Per-Channel) “Error Rate Threshold”’; so that minor Errors would just be “coasted-through”, possibly with the insertion of black and/or silent frames during the “Error Event”, but that a separate “Segment” would NOT be created (unless the threshold was exceeded, of course)?
So, what, if any, provisions for the very-real possibility of momentary OTA signal interruptions/corruptions does the Tablo software/firmware currently employ? I ask partially because I live on a “flight path” for a major Airport, and even with a normally rock-solid signal, the “reflections” off the airplane body cause “picket-fencing” of the OTA signal (those of us old enough will remember this effect from the old days, when everything was OTA). So, since that often causes a couple of frames of stutter/pixellezation of even the strongest channels, does that mean that I can never expect to get a decent OTA recording during the times of airplane traffic over my house?
Weak signals can also cause reboots, so that comes into play.
If there were, you wouldn’t hear so much about these segments . No, you’re kind of SOL from what I can tell.
These vary widely. I seldom have an issue. As others have recently mention, couple weeks or so, I noticed a few on channels I never had issues with… now for no reason at all, I haven’t had any problems.
There is no adjustment. A nice one would be - just stop and don’t bother rebooting just because the signal is weak.
Speaking as an Embedded Systems Developer, WHY would you have the entire Tablo “Reboot” just because 1 of 4 Tuners is temporarily having a signal-lock issue? That is the HEIGHT of non-fault-tolerant design, and smacks of insufficient planning for a common-place problem with the incoming data stream(s).
From a software-design standpoint, simply throwing up your hands and “Jumping to the RESET Function” should NOT be tolerated in ANY Real-time embedded system, even one as prosaic as a “DVR” Application.
My Cisco/Arris Cable DVR NEVER “gives up” on Recording-In-Progress, even during a momentarily bad signal (even if the data errors go on for tens-of-seconds). I live at the end of our neighborhood “drop”, and so my Cable signal sometimes experiences the same sort of stuttering/pixellezation that a shaky ATSC OTA signal demonstrates. So, if my 6-tuner Arris Cable DVR can do it, so can a 4-tuner Tablo OTA DVR. After all, once you get past the Tuners, there is essentially NO difference in the “DVR part” of both of those Devices.
I think… if there’s a momentary blip it can affect either thumbnail creation or commercial skip (or both). But some of my first recordings I purposely recorded channels that had very weak signal bordering on drop out. The recordings came through with pixelation, sound anomalies, stutters, but they completed unless the signal fell right off the cliff. But even then I can’t recall the Quad just flat out puking on the floor and rebooting. The recordings in that case were garbage and didn’t complete, but honestly, I was feeding it garbage and didn’t expect it to give me roses.
Yup, very often complained about. It does not happen each and every time! It happens, for what ever reasons, which, as you state, doesn’t seem to make sense.
As I said, I am an Embedded Systems Designer (Developer) (and have been for nearly 50 years!), and in NO WAY is this an acceptable design.
Jumping to the Reset Vector is usually reserved for a "We are COMPLETELY Borked here, and so we might as well “Start from the Top” ", since there is basically “Nothing left to lose” at that point.
But to resort to that sort of “Last Ditch Effort” just because a Tuner (or Tuners) has a momentary signal/lock/decoding problem just smacks of “Well, we really don’t have any way to figure out what is actually wrong; so this’ll fix it for sure!” mindset.
At least they could do is simply re-initialize the “unhappy” Tuners, rather than the WHOLE system…
But then again, I don’t really know what’s going on specifically in their hardware; so a “Cold Start” (or “Warm Start”) may actually be the only reasonable option to their Developers. If so, I genuinely feel for them.
I think we all do. Quite honestly, that situation is really the only “beef” I have with my Tablo. The fact a single recording’s issues results in issues with other recordings is frustrating.
Maybe we can get @TabloSupport to chime in and let all of us know if it’s a bug or by design.
If it is by design, maybe they can share why that is the only way to clear a tuner when it encounters a signal drop out.
I agree that there must be a better way to do this including possibly showing an error has occurred and the unit needs to be rebooted. This would allow the user to manually reboot the Tablo when no other recordings are in progress.
. No, you’re kind of SOL from what I can tell.
