In your own words.Shades228 said:It's a HD box so it's primary function is HD. Just because they allowed people to use the SD outputs at the same time does not mean that they support or care about people who decided to use it this way...
They do not support or care about people who have faithfully been letting them hold us up every month for "HD" access fees. This is something akin to a protection racket.
They don't support them, and they don't care. But then they never miss an opportunity to cash the check, do they?
To me it is just one more hurdle to moving content to a DVDR (I have to reset the format of the DVR to 480p). I can put up with one more annoyance, and I will, but this is not the first and I fear not the last in a series of annoyances that underline how arrogant and non-caring this company is regarding the ergonomics of their product.
OK, now that is one way of looking at it, but I think it probably is not the right or realistic way.
From another point of view, I should probably cut them a break this one time because they may not actually have had any choice in the matter. If you look at what they are trying to do from a technical standpoint, the necessary hardware to do it the right and best way just isn't there already, and it needs to be to do it without annoying all of us that sometimes depend on the SD outputs.
The box has a hardware rescale to composite video built in, which is ubiquitous and cheap to do. That would make it just as cheap to do that for the GUI (rescale the HD GUI to SD for the composite ports) except that the existing legacy boxes would need a third hardware rescale process available to do that for the GUI overlay (the second one is the one that feeds the HD ports), and you can only up rev the software in a legacy DVR, and obviously can't up rev the hardware to include a third rescale process unless it is futured for that, which it very likely isn't.
Were the hardware available, it would be cheap and easy for the new GUI to take advantage of that. As a matter of fact, that is not too different from how the old GUI worked; they rescaled the SD GUI overlay on the fly to match the HDMI/component output format (you cant overlay a 480 GUI over a 720 or 1080 signal without rescaling it first), and sent an unconverted GUI overlay to the composite ports. Since both the composite ports and the GUI were both already SD, no rescale there was necessary.
But now that the GUI is HD, it has to be rescaled to fit both the HDMI/component output, and rescaled to SD for overlay on the rescaled composite outputs. Apparently there is no way to use the process that rescales HD video down to SD to do the same thing for the GUI, because it is an overlay and a second video source and the overlay can only happen after the down-rez of the main video to SD.
And that makes sense; if the original video is 720p, and you are using the HD rescale process to convert that to 1080i while simultaneously deinterlacing a 1080p GUI to 1080i for overlay, neither one of those processes can also be available to simultaneously rescale the 1080p GUI to 480 to match the rescaled SD video feeding the composite ports.
IOW, with the main rescale process busy feeding the HDMI/component ports, and the SD rescale only available for the main downscaled SD video, that leaves no rescale process available for the GUI overlay for the SD ports.
This means that the only possible workaround is to make us match the HDMI/component format to the SD port format; if the main format is set to 480 then the rescale that handles the GUI overlay can handle both the HDMI/component outputs and the SD composite outputs because then it is the same rescale process. And of course this also means the inclusion of two other one-frame overlays to use as nag screens when we don't do this.
So, they're off the hook this time in my book; you can't make an omelet without breaking an egg or two, and apparently you can't retrofit an HD DVR that has an SD GUI with a new HD GUI without a certain amount of compromise in the process, either.