Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 921149" data-attributes="member: 82144">Hello again ehfortin&nbsp;Thanks for testing. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite24" alt="(y)" title="Thumbs Up&nbsp; &nbsp; (y)" loading="lazy" data-shortname="(y)" />Yes, I tried to get clever, but obviously I wasn't quite clever/careful enough. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite10" alt=":oops:" title="Oops!&nbsp; &nbsp; :oops:" loading="lazy" data-shortname=":oops:" /><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite29" alt=":coffee:" title="Coffee&nbsp; &nbsp; :coffee:" loading="lazy" data-shortname=":coffee:" /><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />&nbsp;On a more positive note, I think I was wrong when I said it may not be possible to integrate this patch. Lets see how we go...&nbsp;Obviously I need to provide you with a new patch. However, this first patch raises an interesting question. In the sequence of PMTs I see audio type changing as follows:1. AC32. AAC3. AC34. &lt;consistently AC3&gt;&nbsp;So it looks like we may need to wait for the 3rd PMT to be sure that the STB has changed, not the 2nd as I had previously thought.&nbsp;Do you agree, or do you think that I should still just go with the 2nd and treat other PMT changes as normal?&nbsp;Waiting for the second PMT effectively added a delay of ~3.3 seconds.Waiting for the third PMT will bump that delay up to ~4.5 seconds.&nbsp;Alternatively, should I wait until the PMT version number is stable?This would probably be the most fool-proof, but it would bump the delay up another second or so.&nbsp;&lt;Everyone else&gt;Do you like the idea of this modification?Effectively what it would mean is cleaner channel changes. In other words, you wouldn't get the (1) enter ch# on the remote, (2) MP channel change completes, (3) channel actually changes sequence. However, channel changes might appear slightly slower.&nbsp;mm</blockquote>

[QUOTE="mm1352000, post: 921149, member: 82144"] Hello again ehfortin Thanks for testing. (y) Yes, I tried to get clever, but obviously I wasn't quite clever/careful enough. :oops::coffee::D On a more positive note, I think I was wrong when I said it may not be possible to integrate this patch. Lets see how we go... Obviously I need to provide you with a new patch. However, this first patch raises an interesting question. In the sequence of PMTs I see audio type changing as follows: 1. AC3 2. AAC 3. AC3 4. <consistently AC3> So it looks like we may need to wait for the 3rd PMT to be sure that the STB has changed, not the 2nd as I had previously thought. Do you agree, or do you think that I should still just go with the 2nd and treat other PMT changes as normal? Waiting for the second PMT effectively added a delay of ~3.3 seconds. Waiting for the third PMT will bump that delay up to ~4.5 seconds. Alternatively, should I wait until the PMT version number is stable? This would probably be the most fool-proof, but it would bump the delay up another second or so. <Everyone else> Do you like the idea of this modification? Effectively what it would mean is cleaner channel changes. In other words, you wouldn't get the (1) enter ch# on the remote, (2) MP channel change completes, (3) channel actually changes sequence. However, channel changes might appear slightly slower. mm [/QUOTE]

Verification