Please consider this minor request for increased consistency.
The EXTEND models appropriately issue an the 802 Unknown Transcode Profile error when the
?transcode parameter is used incorrectly. It’d be great if all other models always issued the 802 error when a transcode is requested.
Want to write your own code to work with a HDHomeRun or work with the HDHomeRun DVR? We are happy to help with concepts, APIs, best practices.
9 posts • Page 1 of 1
- Posts: 9678
- Joined: Wed Jan 24, 2007 1:04 am
- Device ID: 10A05954 10802091 131B34B7 13231F92 1070A18E 1073ED6F 15300C36
- x 29
It has been awhile since i checked that but as i recall it shouldn't have any error as transcode is simply ignored since they can't transcide
I understand the point, this seemed like a simple/easy ask to introduce into all non-transcoding models. When I made the request I didn't understand that the EXTEND product was defunct. My hope was to have a single test suite for all product lines. It would sure make it easy to have a single test plan that works for each product without hardware detection. Second, I'd like to have an application "preferred" stream and fall back to the raw stream upon receiving an error.
Why can't you just use ?transcode=heavy (or whatever) on everything, then fall back to ?transcode=none if it errors? The EXTEND will respect the transcode setting and everything else will ignore it and just send the original video.
For sure! That will work and we can come up with a hundred other ways of slicing this apple. I'd just preferred a more explicit result. When requesting ?transcode=mobile I'd much prefer a guarantee that I'm getting a transcoded stream up to 720 or nothing at all. I can accomplish this by first checking the hardware type. Similarly, I'd prefer that ?transcode=dialup errors on every hardware platform so that I can maintain a singular test suite for both the EXTEND and the CONNECT.
OK, and people who are just passing the transcode parameter and expecting it to work universally are going to be broken by that, so I don't really see why people who use their TV tuner to watch TV should potentially be broken vs. whatever the hell it is you're doing, especially when SD already provides /discover.json to retrieve model information to make it easier for developers to identify the hardware and adjust accordingly. I know you don't want to do that, but you're the one doing the weird thing, not everyone else, and the onus is on you to adjust your application accordingly. On the other hand, if there's something that might be beneficial that won't potentially break existing workflows, you should suggest that, as it's much more likely to actually happen.