Reply to thread

Message

Thanks HTPC_Sourcer

Unfortunately I think this test does not actually check the behaviour due to the nature of the PMT changes.

"Planet der Affen - Revolution" starts with the following streams:
[collapse]
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3
[/collapse]

At 20:55 we have the first change as you say:
[collapse]
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[/collapse]

Note that the English AC3 audio is removed but the other streams remain the same. This scenario has never been a problem for DD. It is only when a new stream is added (or PID changes) that a problem occurs.

At 21:15 we have the second change exactly as you said:
[collapse]
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3
[/collapse]

This change reverses the previous change. In other words, the English AC3 stream is back using the same PID as before. I think since the CAM was previously configured to decrypt that stream, it would automatically start again even without any notification from TV Server. That means the DD driver doesn't have to handle this situation - it should just work.

So, as I said, I don't think this test captures the scenario that we need. You're close... but not quite. The scenario we need is to have [for example] the recording start at 21:00 when the English audio stream is missing, and then observe what happens to channel A and B at 21:15. I hope this makes sense, and please feel free to ask if anything is not clear.

Thanks again for taking the time to test.

<blockquote data-quote="mm1352000" data-source="post: 1143782" data-attributes="member: 82144">Thanks HTPC_SourcerUnfortunately I think this test does not actually check the behaviour due to the nature of the PMT changes. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown&nbsp; &nbsp; :(" loading="lazy" data-shortname=":(" />&quot;Planet der Affen - Revolution&quot; starts with the following streams:[collapse][2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:FF pcr[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:60 pmt[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:20 teletext type:6[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; map pid:20 teletext type:6[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:30 type:5[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:FF video type:H.264[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; map pid:FF video type:H.264[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:103 audio lang:deu type:AC3[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; map pid:103 audio lang:deu type:AC3[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; pid:104 audio lang:eng type:AC3[2015-07-17 20:43:38,977] [Log&nbsp; ] [scheduler thread] [INFO ] - subch:0&nbsp; map pid:104 audio lang:eng type:AC3[/collapse]At 20:55 we have the first change as you say:[collapse][2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:FF pcr[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:60 pmt[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:20 teletext type:6[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:20 teletext type:6[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:30 type:5[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:FF video type:H.264[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:FF video type:H.264[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:103 audio lang:deu type:AC3[2015-07-17 20:55:46,120] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:103 audio lang:deu type:AC3[/collapse]Note that the English AC3 audio is removed but the other streams remain the same. This scenario has never been a problem for DD. It is only when a new stream is added (or PID changes) that a problem occurs.At 21:15 we have the second change exactly as you said:[collapse][2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:FF pcr[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:60 pmt[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:20 teletext type:6[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:20 teletext type:6[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:30 type:5[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:FF video type:H.264[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:FF video type:H.264[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:103 audio lang:deu type:AC3[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:103 audio lang:deu type:AC3[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; pid:104 audio lang:eng type:AC3[2015-07-17 21:15:16,033] [Log&nbsp; ] [26&nbsp; ] [INFO ] - subch:0&nbsp; map pid:104 audio lang:eng type:AC3[/collapse]This change reverses the previous change. In other words, the English AC3 stream is back using the same PID as before. I think since the CAM was previously configured to decrypt that stream, it would automatically start again even without any notification from TV Server. That means the DD driver doesn't have to handle this situation - it should just work.So, as I said, I don't think this test captures the scenario that we need. You're close... but not quite. The scenario we need is to have [for example] the recording start at 21:00 when the English audio stream is missing, and then observe what happens to channel A and B at 21:15. I hope this makes sense, and please feel free to ask if anything is not clear.Thanks again for taking the time to test. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /></blockquote>

[QUOTE="mm1352000, post: 1143782, member: 82144"] Thanks HTPC_Sourcer Unfortunately I think this test does not actually check the behaviour due to the nature of the PMT changes. :( "Planet der Affen - Revolution" starts with the following streams: [collapse] [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF pcr [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:60 pmt [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:20 teletext type:6 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:20 teletext type:6 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:30 type:5 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF video type:H.264 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:FF video type:H.264 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3 [2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3 [/collapse] At 20:55 we have the first change as you say: [collapse] [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3 [2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3 [/collapse] Note that the English AC3 audio is removed but the other streams remain the same. This scenario has never been a problem for DD. It is only when a new stream is added (or PID changes) that a problem occurs. At 21:15 we have the second change exactly as you said: [collapse] [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3 [2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3 [/collapse] This change reverses the previous change. In other words, the English AC3 stream is back using the same PID as before. I think since the CAM was previously configured to decrypt that stream, it would automatically start again even without any notification from TV Server. That means the DD driver doesn't have to handle this situation - it should just work. So, as I said, I don't think this test captures the scenario that we need. You're close... but not quite. The scenario we need is to have [for example] the recording start at 21:00 when the English audio stream is missing, and then observe what happens to channel A and B at 21:15. I hope this makes sense, and please feel free to ask if anything is not clear. Thanks again for taking the time to test. :) [/QUOTE]