Agree entirely.
There are certainly some serious issues on the table. But, at least I can now see that when it is working it works well.
So, I’ve been involved in product design and development for over 25 years now. And I’ve see products plagued by problems such as are evident here.
What I’ve noticed is that over the decades, as the software has become more prominent, is that the overall product development tends to be driven more by the software team. And for all the magic that the software guys can deliver, I’ve noticed that robust testing at the physical layer isn’t normally their strong suit. This seems to be a good example. It seems fairly clear to me (and I think you) that the Tablo Roku video decoder isn’t “robust”. It doesn’t degrade gracefully in the presence of errored or dropped packets. One suspects that the software team had a nice little test platform in their lab were they had decently clean OTA signals and a wifi network that probably extended for a lab bench or two. It probably never occurred to anyone that you might want to test the product on a somewhat lousy Wifi network (indeed, an intentionally lousy WiFi network) or that maybe you ought to throw some less than ideal OTA signals at the receiver.
If they had done that, I believe they would have discovered that “hey, this works ok with the Android app or in a browser, but it’s not working so well on the Roku”.
And, just looking at the history, it does seem that they need to stop adding features for awhile and focus solely on bug killing.
But, as I said the basic concept of the product seems sound. If they could just work their bug list down I think they’re on to something. They should take some comfort in this as I’ve definitely been around product developments that were never going to be successful even if the engineering had been perfect as it was just a bad product concept.