Recording Segmentation

[AppleCordCutter]

@FlyingDiver

You’re assuming this is by design. I think it’s more likely a bug that happens to cause a system crash.

I never said it was a GOOD Design…

[AppleCordCutter]

@Radojevic

Possibly, but it’s been there since from the beginning.

That’s a REALLY bad sign!

[AppleCordCutter]

@Nilex

The fact a single recording’s issues results in issues with other recordings is frustrating.

Actually, “Inexcusable” is the word that comes to mind…

[Nilex]

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.

[djk44883]

@FlyingDiver

I think it’s more likely a bug that happens to cause a system crash

Couldn’t that be interpreted as, maybe, an unintentional [by] design flaw?

[AppleCordCutter]

@3rdRockOKC

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.

@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:

1. Tablo really DOESN’T know how to “fix this” any other way than a Hard Reboot.

2. 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.

3. 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.

[AppleCordCutter]

@Nilex

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.

Hence my additional “hypotheses”, below.

Howabout “Extremely Concerning”, then?

[AppleCordCutter]

@djk44883

Couldn’t that be interpreted as, maybe, an unintentional [by] design flaw?

You’ve got a great career ahead of you in Politics, LOL!

[djk44883]

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.

[Nilex]

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.

[yardbird]

I like the term “undocumented feature”

[Radojevic]

@yardbird

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.

[AppleCordCutter]

@djk44883

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.

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…”

[3rdRockOKC]

@AppleCordCutter

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.

[AppleCordCutter]

@3rdRockOKC

If @TabloTV has any information, it would also be greatly appreciated.

Agreed!

[Lysander]

@AppleCordCutter

@3rdRockOKC

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…

[AppleCordCutter]

@Lysander

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!

[zippy]

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.

[djk44883]

I have noticed TabloTV and Support are very busy posting rtfm type replies to commercial skip issues - overwhelmed.

[AppleCordCutter]

@zippy

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 wasn’t looking for a Developer job, LOL!

I couldn’t find much of anything on Visx or Xtensiv., unfortunately…