Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 1068903" data-attributes="member: 82144">I note that the first tune request in the first test logs was slower than it would otherwise be because the channel details (PMT PID) had changed:[collapse][2014-03-08 01:57:03,744] [Log&nbsp; ] [4&nbsp; ] [INFO ] - subch:0 set pmt grabber pmt:30 sid:400[2014-03-08 01:57:03,747] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time[2014-03-08 01:57:03,749] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - WaitForPMT: Waiting for PMT 30[2014-03-08 01:57:13,751] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - WaitForPMT: Timed out waiting for PMT after 10.0016384 seconds. Increase the PMT timeout value?[2014-03-08 01:57:13,759] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - Setting to 0 to search for new PMT.[2014-03-08 01:57:13,766] [Log&nbsp; ] [4&nbsp; ] [INFO ] - subch:0 SetupPmtGrabber<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue&nbsp; &nbsp; :p" loading="lazy" data-shortname=":p" />id 0 sid:400[2014-03-08 01:57:13,773] [Log&nbsp; ] [4&nbsp; ] [INFO ] - subch:0 set pmt grabber pmt:0 sid:400[2014-03-08 01:57:13,779] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time[2014-03-08 01:57:13,784] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - WaitForPMT: Waiting for PMT 0[2014-03-08 01:57:13,870] [Log&nbsp; ] [25&nbsp; ] [INFO ] - subch:0 OnPMTReceived() pmt:13F6 ran:True dynamic:False[2014-03-08 01:57:13,874] [Log&nbsp; ] [4&nbsp; ] [DEBUG] - WaitForPMT: Found PMT after 0.0900601 seconds.[2014-03-08 01:57:13,885] [Log&nbsp; ] [25&nbsp; ] [DEBUG] - Updated PMT Pid to 13F6![/collapse]@[USER=107951]georgius[/USER]The first tune request in the second set of log files is a good example of this. TV Server tries the first tuner, fails to find PMT, then tries the second tuner and eventually finds PMT. This symptom is quite similar to the symptoms reported by T^2 - slow channel changes. I can't see any good reason why this should happen unless the IPTV filter is not receiving data, dropping some data, not delivering the data on the output pin, or TsWriter has a major bug in the PMT grabbing. At least I can see that TsWriter is not doing any PMT callback, so the issue is somewhere in the data reception or filter chain.For the tune request at approx. 08-03-2014 02:00:20...From the wireshark trace it looks like the tuner is delivering data. Can you confirm whether the IPTV filter was receiving data?Unfortunately the TS packets are not aligned to the UDP packets so Wireshark doesn't seem to want to decode them properly, so I can't see whether the PMT was being delivered.</blockquote>

[QUOTE="mm1352000, post: 1068903, member: 82144"] I note that the first tune request in the first test logs was slower than it would otherwise be because the channel details (PMT PID) had changed: [collapse] [2014-03-08 01:57:03,744] [Log ] [4 ] [INFO ] - subch:0 set pmt grabber pmt:30 sid:400 [2014-03-08 01:57:03,747] [Log ] [4 ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time [2014-03-08 01:57:03,749] [Log ] [4 ] [DEBUG] - WaitForPMT: Waiting for PMT 30 [2014-03-08 01:57:13,751] [Log ] [4 ] [DEBUG] - WaitForPMT: Timed out waiting for PMT after 10.0016384 seconds. Increase the PMT timeout value? [2014-03-08 01:57:13,759] [Log ] [4 ] [DEBUG] - Setting to 0 to search for new PMT. [2014-03-08 01:57:13,766] [Log ] [4 ] [INFO ] - subch:0 SetupPmtGrabber:pid 0 sid:400 [2014-03-08 01:57:13,773] [Log ] [4 ] [INFO ] - subch:0 set pmt grabber pmt:0 sid:400 [2014-03-08 01:57:13,779] [Log ] [4 ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time [2014-03-08 01:57:13,784] [Log ] [4 ] [DEBUG] - WaitForPMT: Waiting for PMT 0 [2014-03-08 01:57:13,870] [Log ] [25 ] [INFO ] - subch:0 OnPMTReceived() pmt:13F6 ran:True dynamic:False [2014-03-08 01:57:13,874] [Log ] [4 ] [DEBUG] - WaitForPMT: Found PMT after 0.0900601 seconds. [2014-03-08 01:57:13,885] [Log ] [25 ] [DEBUG] - Updated PMT Pid to 13F6! [/collapse] @[USER=107951]georgius[/USER] The first tune request in the second set of log files is a good example of this. TV Server tries the first tuner, fails to find PMT, then tries the second tuner and eventually finds PMT. This symptom is quite similar to the symptoms reported by T^2 - slow channel changes. I can't see any good reason why this should happen unless the IPTV filter is not receiving data, dropping some data, not delivering the data on the output pin, or TsWriter has a major bug in the PMT grabbing. At least I can see that TsWriter is not doing any PMT callback, so the issue is somewhere in the data reception or filter chain. For the tune request at approx. 08-03-2014 02:00:20... From the wireshark trace it looks like the tuner is delivering data. Can you confirm whether the IPTV filter was receiving data? Unfortunately the TS packets are not aligned to the UDP packets so Wireshark doesn't seem to want to decode them properly, so I can't see whether the PMT was being delivered. [/QUOTE]

Verification