I never said it was a GOOD Design… 
1 Like
That’s a REALLY bad sign!
Actually, “Inexcusable” is the word that comes to mind…
I try to stay away from using words like that until I know the full background and context of a situation. I full well know that I don’t know everything. 
1 Like
Couldn’t that be interpreted as, maybe, an unintentional [by] design flaw?
@Nilex @Radojevic @FlyingDiver
Sorry for the multiple replies…
The fact that this is a “forever bug”, especially with no “chime-in” by Tablo Support, suggests to me a couple of possibilities:
-
Tablo really DOESN’T know how to “fix this” any other way than a Hard Reboot.
-
The issue occurs in a “Pre-Compiled Library”, most likely a vendor-supplied Driver for the SoC and/or Tuner chips, and that Nuvyyo doesn’t have the “Source Code” to research and effect a fix.
-
There is a Hardware “feature” that is actually causing the Reboots. For example, if the Tuner chips all have a “Common-Drain” RESET/FAULT pin, that is in turn connected to all the other Tuners’ and the SoC’s RESET/FAULT pin (any of which can then “Drive” the rest of the RESET/FAULT pins “Active”), then, as soon as ANY of the Tuners has a problem, it ends up RESETTING EVERYTHING. This would partially explain why this has gone on forever, especially if Nuvyyo doesn’t actually DESIGN that part of the Tablo devices. Maybe someone with more knowledge of the Tablo Hardware can speak to my “hardware” theory. If that is the case, perhaps a little Power-On-Reset circuit could be used, and separate-out any common RESET/FAULT signals from the Tuners, and keep them from getting to the SoC. The downside is that the Tablo would probably want to “grow” a RESET button (or 2 to 4 RESET buttons…). Unfortunately, one of the reasons that they just “Punk out” and Jump to the RESET Vector in the SoC, is that is likely the ONLY time the Tuners get Initialized (and they all get Initialized, one after another), and so simply RESETTING one or two of the Tuners would likely just leave it crazy-fied, because it would be uninitialized. In fact, it might even tend to “bring down” the rest of the system…
Obviously just thinking out loud. 
1 Like
Hence my additional “hypotheses”, below.
Howabout “Extremely Concerning”, then?
You’ve got a great career ahead of you in Politics, LOL! 
Well, it’s like if you look at #feature-requests topic and sort by activity… not necessarily market driven, but what users want and - boy oh boy how cool is commercial skip!?
We still can’t prioritize scheduling, the popular Roku seems to be lacking in features, and grand overhaul with scanning/adding channels. Then some user/pass security integrated with simpler remote access.
Understood. I was commenting after the time of that posting and prior to your additional details and theories. You obviously have a designer background as you stated but I was just pointing out that you also don’t necessarily have all the information for this particular situation.
Your theories make sense, just saying throwing out words like “inexcusable” without all the information can cause confusion, which has happened on several topics in the past. I’m just trying to put it in context for when others stumble on this thread later.
I like the term “undocumented feature” 
That’s when an undocumented behaviour is beneficial.
In this case, I believe, it’s a b-b-bug.
Well, and as the author/maintainer of many a software Project, I fully understand how bugs, even serious ones, can languish for what seems (or actually is) an inordinate period of time. This is exacerbated in a small company like Nuvyyo, where the “Development Team” is actually about 1 to 3 people, and “Marketing” is forever pushing to add features (like Commercial Skip), that end up eating a LOT more resources than first anticipated, and “Engineering” (hardware Engineering, that is) is seemingly FOREVER needing “a new build” of the software, to test something out on, and/or prepare for a new (unreleased) product still on the R&D bench…
But it would be nice to at least hear a “Yeah, we know. We are getting to it, but it will be a few more (days/weeks/months) before we can reasonably have a fix for you. Please Stand By…”
Which is why I asked @TabloSupport give us some additional information regarding this problem. Hopefully they will respond soon so everyone can stop guessing about what can and can’t be accomplished. If @TabloTV has any information, it would also be greatly appreciated.
Agreed! 
[Just an Observation]
In the three days this thread exits there is not a single comment from @TabloTV.
Certainly they are aware of this…as there are recent comments from them in other threads…
Indeed.
I posted a new topic a few days ago, and there was a Comment by “TabloSupport” no more than 15 MINUTES later!
Since tablo has probably been using Xcode processors since day one, they might have also been using the Vixs Xtensiv™ software stack.
If they are still using that stack maybe you can read up on it.
I have noticed TabloTV and Support are very busy posting rtfm type replies to commercial skip issues - overwhelmed.
I wasn’t looking for a Developer job, LOL!
I couldn’t find much of anything on Visx or Xtensiv., unfortunately…