Hey @beaucop1, @kathyeck, @FlyingDiver, @Jimhyer, @bravo…
We just heard from the team at WBBH. They have made some tweaks that may have patched this issue up.
Can anyone take a peek and let us know how things look?
Hey @beaucop1, @kathyeck, @FlyingDiver, @Jimhyer, @bravo…
We just heard from the team at WBBH. They have made some tweaks that may have patched this issue up.
Can anyone take a peek and let us know how things look?
I’m not seeing the issue anymore. I’ll watch for a bit more and report if there’s any change.
Awesome! Glad to hear it @FlyingDiver .
Can you also do a quick test recording for us and let us know if you see any issues? I don’t think there would be any problem, but always good to double check!
Did a 2 minute recording. No artifacts.
Thanks @FlyingDiver!
If anyone else sees anything different, let us know!
I also confirm that it looks good. Awesome response Tablo!
All looks good here too. Watched live and recorded for a few minutes. The issue seems resolved. Thanks!
Just checked my Tablo and it all looks good. Thanks Tablo for such quick responce.
@TabloTV
Interesting that this problem is something that the broadcaster can easliy fix with just a tweak.
Do you know, technically, what is happening with the broadcast signal when this problem occurs?
The geek in me would like to know the details
From what we can see on our end, it’s a missing parameter called ‘picture structure’. In regular 1080i broadcasts the parameter called ‘field’ is always present for the ‘picture structure’ parameter.
In both cases this parameter was missing.
Since the the tools/interface we use is not the same as what the broadcasters use on their end, it’s not clear exactly what checkbox/switch isn’t quite right.
But to be fair to them, their video monitoring equipment does not transcode, so they’d never know that this is happening unless someone (like us or another customer using transcoding hardware) notifies them.
Thank you for the info.
I guess it goes without saying that digital TV broadcasting today is not as simple as it was in the days of analog TV.
Thanks again.
@beaucop1, @kathyeck, @FlyingDiver, @Jimhyer, @bravo
The team at WBBH let us know that they switched back to their main encoder yesterday and for part of today… Is everything still looking right?
It’s broken again.
Just sent you DM; we’d like to take a quick look.
UPDATE - WBBH has switched back to the working encoder again while they work through why the new one isn’t performing as expected.
It is back to bad! Split picture. Please have them fix it!
Funny thing is they are under no obligation really to do so. Apparently it works just fine with all the TV’s the viewers are using. Something that might be an issue in the future when a station just says, nope…not our problem.
Isn’t the question not whether a TV tuner can play the stream but does the stream conform to the ATSC 1.0 standard?
Here is some light reading that’s good for when one is sitting on the throne.
Clearly:
6.4.2.3 Reed Solomon Encoder
All bytes output from the data randomizer shall be sent to the RS encoder. The data byte
processing shall be as specified in Section 6.4.1.2, and the M/E flag shall be maintained as
Enhanced for the 184 Enhanced bytes and shall be set to Main for all other bytes. All RS parity
bytes are Main mode bytes and shall have their flags associated to their Main states.
Need I say more?
True, but how loose is that spec and how many devices tolerate the changes vs those that don’t. In the end if the Tablo users ended up being the only people that couldn’t receive a signal the station could in theory just ignore the problem, even if it’s out of ‘spec’. I think the best solution would be to update the Tablo to work with the out of spec signal if possible. Clearly other TV tuners are working just fine.
Just a bit of hypothetical of course.