Recording Segmentation


Sorry for the delay. Before responding, we wanted to sit down with our subject matter experts to make sure we had the most accurate and up-to-date information.

Short fluctuations in signal strength or slight errors will NOT trigger a Tablo to reboot. For your DVR to get into a state where a reboot is required, one or more of the incoming Over-the-Air signals to your Tablo must be significantly and persistently corrupted.

By undertaking a system reboot to clear the corruption from the ‘bad’ channel, the Tablo can recover and re-attempt recordings coming in from ‘good’ channels. While we agree this may not be the most elegant solution, we believe it is the best choice we have available currently.

Our recommendation to avoid this rare occurrence has always been to improve your Over-the-Air setup to strengthen reception on ‘bad’ channels. Barring that, these channels should be removed from your lineup for optimal performance.

In order to help end-users better identify problematic channels, we are working to provide improved diagnostics and in-app feedback so stay tuned for more on that.


@TabloTV Would it be possible to expose an end user control preference that would continue recording if other channels are clean and are recording at the same time as the corrupt channel?

This way the user not the machine determines when a reboot occurs.


For your DVR to get into a state where a reboot is required, one or more of the
incoming Over-the-Air signals to your Tablo must be significantly and persistently

Does this mean that a tuner must be actively tuned to the channel with bad signal, OR does the channel merely need to be on the user’s channel list?

Thank you for the time to research.


Yes. That’s correct. This reboot will only trigger if you’re viewing live or recording a channel that is corrupt.


First, as the originator of this Topic, thank you VERY much for both keeping an eye on these “Discussions”, and even MORE for actually having one or more meetings with your Development team(s) regarding this issue!

One question though: Is it actually impossible/impractical to Re-initialize JUST the single Tuner chip/card that is having difficulty, instead of just Jumping to the tippy-top of the code?


The problem with that is that it would END the Recording on the “bad channel”, without the “good thing” of attempting to Resume that Recording, too.


If we can’t have a user control preference prioritizing show preference… but we can control weather or not when it fault to a reboot – now you’re being silly :slight_smile:


Your “good thing” also interrupts what could be up to three other perfectly good recordings.

If I have a program recording on a channel that breaks up bad enough to lock up the tuner, I’d rather completely lose that one recording than lose all four recordings because that one channel repeatedly causes the Tablo to reboot and just incase you don’t believe that would happen, I can assure you that it has happened to me in the past where a bad signal has caused a recording to be divided into four or five parts. Everytime the Tablo reboots, you lose two to three minutes of every recording, not just the one problem tuner. Just give me an error message with the failed recording letting me know I need to reboot the Tablo to gain back access to the locked up tuner.


Hear, hear!!!


So now you’ve locked out a tuner. What happens to all the recordings that are now going to fail because the unit is one tuner short of what it had when you scheduled the recordings?


1 continuously failing tuner is better than 3 other immediate failures. IMHO


Continuously? When this has happened to me, it’s been very intermittent. Like once per week, maybe. I’ll take a couple of split recordings over a dozen missed recordings (due to missing a tuner) any time.


In my personal case, I have two 4 tuner Tablos. It is extremely rare that I have all 8 tuners in use at the same time. So, I would gladly lose the use of 1 tuner because of a failing signal than to lose 1, 2 or 3 good recordings. Even before I purchased the second Tablo, I still would have preferred losing one tuner and it’s associated recordings rather than losing recordings from all tuners.

When I had a station that was regularly causing a reboot I removed it from my selected channels until I could adjust my antenna to improve the signal strength. I had a 30 year old yagi antenna that would occasionally get hit by a tree limb during a severe storm causing the antenna to be rotated slightly. I recently replaced the yagi with an Antop AT-400BV which hopefully won’t have a problem with the tree.

I also check my scheduled and completed recordings daily, so again it would be most beneficial to me to reboot the Tablo on my schedule rather than when it senses a corrugated signal.




Or, if that is not possible, then expose a preference that allows the USER to decide!


That would be even better!


I know it is easy for us to be “Arm Chair Quarterbacks”, as we are not the ones doing the work. But I think it would cut down tremendously on your support load, if this particular issue was addressed.

As a person with both Electrical Engineering (very old) and Software Engineering (very current) backgrounds, I find it hard to believe that an individual Tuner can not be reset programmatically via a call to the Firmware. Most signal processing chips have reset lines, and it seems like the Processor could “tug” on that line when it is unable to talk to the Tuner to for it to reset.

If that is missing, I suppose that should be a design specification requirement on the next board revision. If that is not easy, perhaps a more “Brute Force” approach, and have a line that could cut power to that tuner, and thus cause it to reset on its own.

As for the UI, the Processor could put a warning in the Tablo App that shows there is a Tuner fault, or better yet, shows the Health and Perceived signal strength of each of the Tuners. This could be in the Header Bar, or even a Header Bar color change with the details in the Settings or a new Menu Group.

Just my 2 cents…


Aren’t both the Maxlinear MxL603 and Mxl69X dual tuner Soc chips. Wouldn’t that mean resetting one might reset both?

“As for the UI, the Processor could put a warning in the Tablo App that shows there is a Tuner fault”.

Isn’t the tablo a headless device and thus might not be connected to any specific tablo device. Especially if you have multiple tablos. And the last menu I want to be in or visit is the settings menu.


As I have stated before, I am an Embedded Systems Designer (Developer),with over 50 years of paid both Software and Hardware experience.

I agree with you that there most certainly should be a way to Reset/Reinitialize a single tuner (having never seen the inside of a Tablo QUAD (or any other Tablo for that matter, nevermind actually seeing a schematic!)), and if someone made the mistake to “Wire-OR” the multiple tuners’ RESET lines together, it is high-time that that design shortcoming be addressed with a board and software rev!

I also propose that the Tablo Firmware be able to Raise a Notification to any “logged-in” Watchers, giving not only detailed Error info, as well as the ability to Remotely-Reset a single Tuner, or Reboot the whole system.

Add to that the ability to easily automatically and/or manually Concatenate Segmented Recordings into one file, and you’re pretty much “there”.

I mean, Linux prides itself as being an OS that hardly EVER requires a Reboot, and yet the best the Nuvyyo Dev. Team can do is “Press Ctrl-Alt-Delete” (yes, I know I’m mixing OSes, LOL!) whenever things get the least bit dicey.

Good thing I didn’t take that same approach when writing the motor-control software for a Dynamic Balancing Machine, that spun-up 1-ton 4-ft. diameter Flywheels for Caterpillar Earth-Movers to 1800 RPM, while they sat on a Pneumatic “Chuck” which was controlled (along with the mechanical brakes) by my same code, running on a simple 6502-based single-board-computer.

Can you imagine the “fun” if I just elected to "Jump to RESET’ and Reinitialized the system as if a Cold-Start, with that flywheel spinning at 1800 RPM? Talk about the world’s largest frisbee!!! :grin:


I used to call that forcing a unix kernal panic by looking at the console terminal funny.