Better error handling?

[jkc120]

I'm wondering if we aren't blaming the HR20 for bad MPEG4 feeds. I saw in another thread where someone said the OTA broadcast toggled from SD to HD, and this coincided with people having problems.

So, I wonder if the HR20 were to better handle these sort of issues (SD/HD swapping, signal drops outs/loss, etc), if the lockups/bad recordings issues would go away. Obviously to be replaced with recordings with blanks in them.

But at that point, we'd be pointing the finger at the networks instead of the HR20. I just think that the problems are so random that it might be seemingly random because of the various local feeds and their respective quality (or lack thereof).

Perhaps if D* were to make the HR20 more robust in handling bad feeds or error conditions in the feeds, it'd remain more stable and we could focus on getting the problematic stations to fix their broadcasts!

[Tom Robertson]

Speaking about the 'E3 release, there was strong evidence that you are somewhat correct. MPEG4 feeds were not robust and exacerbated problems for some people. And I can understand where problems in the MPEG4 feed can easily occur. Many local stations are still toying with their HD datastreams, forcing many people to rescan OTA often; glitches; etc. So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.

On the other hand, many of us had similar problems without using MPEG4 or without even having MPEG4 feeds. Clearly, the box was not baked enough in testing to meet the standards for a piece of consumer electronics.

Cheers,
Tom

[jkc120]

So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.

Excellent point, the encoding is surely part of the equation. I'm simply not convinced that the unit itself is fully to blame.

Unfortunately, they probably did (do) all their testing with pristine MPEG4 streams. So perhaps adding some additional bad or broken feeds to their QA will improve things, since they will be able to better work around the broadcast issues.

It's just a suggestion. I know that I have been guilty in the past of only testing for positive conditions. But I quickly learned to think like my customers and do things outside of the bounds of what an ideal user would do. I'm fairly sure they are not testing with any garbage or broken streams. I think it'd help the stability and robustness of the unit immensely if they were to start doing so.

[pgiralt]

So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.


That brings up a question in my mind - Does D* transcode from MPEG2 to MPEG4 or do they get an uncompressed (e.g. ASI or HD-SDI) stream from the network and encode into MPEG4 (therefore it's just encoding not transcoding)?

[LameLefty]

Interesting observation that seems to hit the nail right on the head.

You know, about a year ago when the 5G video iPods hit the streets, there were lots of problems with MPEG4 videos for it, especially H.264 (the same standard picked by D* for MPEG4 locals). There were a variety of fixes released over the subsequent months, both by Apple (for the iPod itself and for QT7 which formed the basis for most encoding apps) and by 3rd party developers using QT and home-grown routines to encode or transcode video for playback on the boxes. After a few months as the bugs were worked out and the error-handling was tightened up at both ends, the boxes started working as advertised.

I hope (and still believe) that this is what's going on with the HR20. If it was an Apple "iHD" box, I might be more confident still. :lol:

[jkc120]

That brings up a question in my mind - Does D* transcode from MPEG2 to MPEG4 or do they get an uncompressed (e.g. ASI or HD-SDI) stream from the network and encode into MPEG4 (therefore it's just encoding not transcoding)?

Hmm I'm not certain but I think it's a raw OTA feed (but that feed is probably MPEG4 to begin with) so it's transcoding it in a sense (compressing it).

[jovac]

I do remember in the earlier days of my first non-dvr HD D* box, that variations in the adherence to standards from the OTA channels would cause lockups and other issue quite frequently. In fact I knew to never leave my system tuned to an OTS HD channel or I could expect with high certainty that when I next tried to use, it wouls require a hard reset. These situations subsided over time and with several firmware updates. So, it stands to reason that we might be experiencing the same things with the implementation of MPEG4 locals. Whether we blame the box or the networks, the net result is that in all likeliehood these issues will diminish over time.

[Wolffpack]

Does the H20 handle local MPEG4 HD channels? If it does, don't blame the stations. Remember the H20 had been out for quite some time now. If it can get MPEG4 signals shouldn't the HR20?

[jkc120]

Does the H20 handle local MPEG4 HD channels? If it does, don't blame the stations. Remember the H20 had been out for quite some time now. If it can get MPEG4 signals shouldn't the HR20?

Completely different. It doesn't have to record anything, it's just a tuner.

[Wolffpack]

Completely different. It doesn't have to record anything, it's just a tuner.
Yea, I knew that. My point was that if folks are thinking the problem is with the MPEG4 feed, from original HD OTA signal, through the DTV uplink and downlink, then the H20 would be experiencing the same signal problems. Since the H20 isn't, the problem doesn't seem to be the MPEG4 signal itself, just how the HR20 handles/records/plays that signal.

So, yes completely different as long as we don't start blaming the feed. The problem is with how the HR20 handles the signal. And if the H20 can do it correctly, maybe the HR20 team should grab some folks from the H20 coding side and ask them how they did it.

[Wolffpack]

Speaking about the 'E3 release, there was strong evidence that you are somewhat correct. MPEG4 feeds were not robust and exacerbated problems for some people. And I can understand where problems in the MPEG4 feed can easily occur. Many local stations are still toying with their HD datastreams, forcing many people to rescan OTA often; glitches; etc. So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.

On the other hand, many of us had similar problems without using MPEG4 or without even having MPEG4 feeds. Clearly, the box was not baked enough in testing to meet the standards for a piece of consumer electronics.

Cheers,
Tom
These are the comments I'm reffering to in my posts above. If the H20 can decode and play these same MPEG4 signals but the HR20 can't, I don't see how this is a signal problem.

[Wolffpack]

Excellent point, the encoding is surely part of the equation. I'm simply not convinced that the unit itself is fully to blame.

Unfortunately, they probably did (do) all their testing with pristine MPEG4 streams. So perhaps adding some additional bad or broken feeds to their QA will improve things, since they will be able to better work around the broadcast issues.

It's just a suggestion. I know that I have been guilty in the past of only testing for positive conditions. But I quickly learned to think like my customers and do things outside of the bounds of what an ideal user would do. I'm fairly sure they are not testing with any garbage or broken streams. I think it'd help the stability and robustness of the unit immensely if they were to start doing so.
Does anyone know what MPEG4 decoder chips the H20 and HR20 are using? Maybe it's at the hardware level.

[Twosted]

These are the comments I'm reffering to in my posts above. If the H20 can decode and play these same MPEG4 signals but the HR20 can't, I don't see how this is a signal problem.

I think the HR20 and the H20 probably use the same decoders. The HR20 is probably decoding the MPEG4 signals fine. I think the recording part of the HR20 is seeing minor glitches in the decoded signal (which wouldn't affect live viewing) and is dumping the recording (partial, deleted, or missed). This then has a domino effect screwing up other things in the unit (lock ups, unresponsive, etc.). Then most of the time a reset gets it back on track. Until it happens again. Then the cycle repeats itself. I am probably 100% wrong but just wanted to give my thoughts.:)