Request 802 error

[mski]

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.

[signcarver]

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

[mski]

transcode is simply ignored

That is the current behavior.

[jasonl]

[mski]

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.

[jasonl]

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.

[mski]

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.

[jasonl]

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.

[tmm1]

Even if SD changed this behavior, you would need to look up the model/firmware to deal with older firmware where the behavior is different.