New Tablo Quad HDMI ATSC 3.0!

With that said, probably talking 5+ years. (just being honest)

5+ years is in the realm of “whole new world” tech wise.

1 Like

Indeed.

When we first launched Tablo, Roku channels looked like this:

The Amazon Fire TV hadn’t even launched yet and the original Chromecast had just come out.

The Apple TV didn’t have an app store.

Technology will catch up. We just want and need to give it time.

1 Like

It may take 5 years until broadcasters provide full 4K support.

I own a hdhomerun 4K kickstarter device. What changes in the standard are you talking about. If you go to the silicondust download WEB site what changes are listed in the software and firmware change log caused by changes to the ATSC 3.0 standard.

If the standard was changing as you suggest the tablo ATSC 3.0 model is doomed to failure.

And Korea doesn’t seem to have all the problems suggested by ever changing ATSC 3.0 standards.

South Korea literally paved the Road to ATSC 3.0, adopting its Next Gen TV standard in 2016 and launching 4K UHD ATSC 3.0 broadcasts in May 2017. Momentum continues to build since the landmark UHD broadcasts of the Winter Olympics. In addition to UHD, broadcasters continue developing new services on Korea’s ATSC 3.0 service roadmap.

By chance, what ATSC 3.0 DVRs are used in S Korea? I’m just curious (as in, maybe there are “things” out there that we don’t hear about in N. America).

1 Like

What does Korean DVR’s have to do with anything. I thought Korea(Samsung and LP) were major contributors to the development of the ATSC 3.0 standard. Aren’t they the largest producers of TV tuners.

They have been producing consumer TV’s with ATSC 3.0 tuners since 2017. A ATSC 3.0 tuner with the appropriate demodulator will convert the RF to the specific ATSC 1.0 or 3.0 standard. The TV must take this standard to display it on the screen with sound. A DVR just takes the standard and wraps it up with the DVR specific metadata and writes it to a disk.

You seemed to think it was very very very very important. Therefore, if very important, then they probably have already “solved” dvr and dvr streaming. So I was curious if you knew what everyone there was using to do that.

1 Like

The point is that I don’t think the ATSC 3.0 standard is actually changing as often as implied. And the ATSC 3.0 standard has little to nothing to do with DVR’s. It’s a standard to encode/decode RF signals.

Of course if my wife and I move to Korea I’ll let you know what DVR’s they are using.

On this forum we have all seen that not all broadcasters currently implement the ATSC 1.0 format correctly (split flickering screens, incorrect audio, etc.). So, my guess as to why there are so many complaints about the current ATSC 3.0 DVR’s is at least partially due to the broadcasters not being completely compliant with the new standard.

I think we’ll see the broadcasters start to get their act together once ATSC 3.0 capable TV’s are mass produced. Until then, we are all going to have to work with the broadcasters, TV manufacturers and DVR manufacturers to come up with workable solutions.

If there was a change that “broke things” once a month, and you have support for all the devices that need the change implemented, not to mention possible firmware updates to the DVR itself, that is a lot of employee time to write the code, test the code, beta testing the code, and then releasing to the public. Working with software developers for years, it may be a simple bug fix that takes a few minutes to write, but testing can often extend 3-5 days or more, then beta testing, and then release to the public.

When it takes on average of 2 weeks (this is an assumption), and it breaks every 4 weeks, new development almost crawls to a stop, and bug fixing becomes the primary focus. And it isn’t just one device they are fixing, it could be many devices (just think Roku, FireTV, AppleTV, GoogleTV, XBox, Windows, Android, etc - and not to mention the possibility of multiple platform differences). And to get one fix in before the next is discovered…

When taking it to simple terms - only supporting a main box (no streaming), the primary focus is the DVR itself, and it would be easier to roll out changes (as only one device would be affected), and when the platform is stable enough, then start the focus on streaming.

The thing I find most exciting about the Tablo version is the 4-tuner all-hybrid (not 2 ATSC 3.0 tuners and 2 ATSC 1.0 tuners - all 4 ATSC 3.0), and the Tablo platform.

Great summary. Right now its all about control and being able to adapt as needed. Having the only factors be the Tablo itself and the broadcaster keeps it manageable to support in the early days.

My wife and I were in software R&D for over 40 years. What you describe is called waterfall development versus agile development. You write the test as you write the bug fix and after the change is compiled it’s automatically tested. Often there are multiple development lines of code which will be merged when a release is desired.

When and/or if bug fixes are released is a strategy independent of when a fix is done.

There is a “server version” that runs on the DVR. This requires programming to display the audio/video format of the video on the screen. There is a separate function, that possibly transcodes the video to be shared with streaming devices. And all of them have different APIs, requiring different methods to communicate.

I admit that I am not an expert on programming for video services, but remembering back to the early 1990s and 2000s, it used to be a major ordeal to put up a website that worked with Chrome, Firefox & Internet Explorer. It would work on one, but not the other, and when you fixed one, it broke on the other.

I was trying to “keep it simple” as to the possible answer - It seems quite obvious to me they are concentrating on their hardware in the initial release (no streaming), and when things settle down, they have the option of adding streaming into the mix. If they advertise is supports streaming, and customers buy it to stream, and it breaks often - it would be a nightmare to support. Keeping their release simple, allows for a working product on release date, and the option at sometime to add in other functionality as time allows.

If ATSC 3.0 was mainstream, and everyone was viewing it across the country, and the broadcasters were all on a standard that wasn’t changing, I think it might be a different story. My HDHomerun works most of the time for ATSC 3.0, but often goes haywire when a broadcaster makes a change, and they have to fix it (it could be either the broadcaster or the device).

And reliability among all the streaming devices? Yeah, that is really hit or miss…

I don’t know about that. The 4 week cadence he is talking about is closer to a long agile sprint than it is a months long waterfall development cycle.

I don’t know who you did development for but a fix ready for customer installation is 2-3 days max for actual software bugs versus customer screw ups… We promised our forturne 500 customers 24 hours fix turn around. Customers get kind of upset when their database software eats dirt during the black fridays sale. One hour of outage is millions of dollars of revenue.

It takes longer to complete the actual release documents shipped along with the software package to our general software delevery system.

Those must not have been bugs that potentially affected multiple areas that required

I can see 2-3 days on a critical bug that is resulting in customer Production downtime. Heck, I’ve been involved in situations where we went from a critical bug being reported to a fix being deployed in Production less than 12 hours later but that was a bug in a single, isolated place. I was talking a general/overall SDLC.

The bugs that only impact a limited area in the database engine of over 5 million lines of code are few and far between. They usually center around newer features being used in an unexpected way. And these bugs spread up the software stack from engine to middleware, to drivers to apps. All requiring tweaks.

That’s why each area had multiple senior R&D developers assigned to respond for those critical days. But customer support charged customers extra for that level of response. That gave their CEO the right to call our CEO. And tons of people would be called in to toss code if one of the largest retailer in the world crashed and burned.

Fair enough. That clarifies the specific scenario you are talking about isn’t really an apples to apples comparison with the Tablo/DVR scenario that @ronintexas was speaking about.

I need a unit that can do wireless connections. This is not going to work.

2 Likes

I know that spring has just sprung, but I was curious if there is any update on when the new Tablo Quad HDMI ATSC 3.0 will start shipping?

1 Like

Did you hear any updates yet?