Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 1115991" data-attributes="member: 82144">Unfortunately I don't have enough internet cap available to download the samples at the moment. However I'm still very interested to see if you find anything. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />From a TV Server perspective there isn't much that can go better or worse in terms of the decrypt request, because for DD hardware we only submit the service ID (program number) to the driver.In terms of other stuff: I do wonder if the decryption delay could in any way be &quot;magnified&quot; by TsReader's coping mechanisms (logging, flushing etc.). By that I mean, I wonder whether zapping would be any faster for the same situations if TsWriter were able to detect that the stream were encrypted and hold up the works until the stream came clear (rather than relying on TsReader to detect when the stream clears). We might be able to determine this without server side code changes if we noticed that the problem only happened with certain channels (channels that are encrypted at the PES level), or also happened with channels that are encrypted at the TS packet level (ie. those for which TsWriter should detect the encryption and function as designed)...</blockquote>

[QUOTE="mm1352000, post: 1115991, member: 82144"] Unfortunately I don't have enough internet cap available to download the samples at the moment. However I'm still very interested to see if you find anything. :) From a TV Server perspective there isn't much that can go better or worse in terms of the decrypt request, because for DD hardware we only submit the service ID (program number) to the driver. In terms of other stuff: I do wonder if the decryption delay could in any way be "magnified" by TsReader's coping mechanisms (logging, flushing etc.). By that I mean, I wonder whether zapping would be any faster for the same situations if TsWriter [I]were[/I] able to detect that the stream were encrypted and hold up the works until the stream came clear (rather than relying on TsReader to detect when the stream clears). We might be able to determine this without server side code changes if we noticed that the problem only happened with certain channels (channels that are encrypted at the PES level), or also happened with channels that are encrypted at the TS packet level (ie. those for which TsWriter should detect the encryption and function as designed)... [/QUOTE]

Verification