HDHomeRun Prime Tuner Locked (1 Viewer)

[georgius]

Based on the names of the log files I don't think that code is used anymore:
https://github.com/MediaPortal/Medi...Library.Interfaces/Logging/FileLogger.cs#L243

In that case I'm giving up, but I suppose that asynchronous logging is not implemented for tv service.

 

[A Happy Cloud]

I'm trying to handle closing connection problem, but I'm unable to test it. All my RTSP servers (live555 and VLC) doesn't close connection, so I need help from you @A Happy Cloud. I attached to this post special build for you. If it is possible, make test with Wireshark running to see, if connection is really closed and opened.

Sorry for the huge delay, I've been a bit pre-occupied this week. I finally got around to running three tests with the special build you've provided. The first test went rather well, however subsequent tests were subject to hiccups. It appears that it may have trouble using the same tuner when changing channels. Perhaps the MediaPortal and WireShark logs will shed some light on this since I couldn't really infer anything based on what I observed in the WireShark logs. For the record, all these tests were conducted with Windows Firewall enabled. The good news is, it appears to free the tuner (based on HDHomeRun Confi) although the LED on the HDHomeRun Prime does not immediately go off. Thanks for the amazing work you've done so far!

 

[georgius]

From my point of view, I don't see any problem with filter. Connection is reopened and TEARDOWN request is correctly send and processed (also stream is stopped in Wireshark log).

Edit: I commited changes and in first post of merged filter thread is normal build, which can reopen connection.

 

[A Happy Cloud]

From my point of view, I don't see any problem with filter. Connection is reopened and TEARDOWN request is correctly send and processed (also stream is stopped in Wireshark log).
.

Yeah it sends the requests and they are indeed processed correctly. However, after subsequent use of the filter, I noticed that channel changing has become significantly slower compared to the current filter. It tries to use the same tuner when changing the channel but sometimes it just hangs there and after it realizes that its not working, it tries a new tuner which then displays the channel. It worked great on the first use after installing it but for some reason that performance appears to have degraded. I'll see if I can get more logs showing you what I mean.

 

[mm1352000]

The first test went rather well...

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 SetupPmtGrabberid 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]

...however subsequent tests were subject to hiccups. It appears that it may have trouble using the same tuner when changing channels.

@georgius
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.

 

[georgius]

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.

Yes, filter was receiving data. From filter log:

08-03-2014 02:00:30.476 [2614] [{13CD4B2C-F9F0-4C3F-AF77-3A65406E0781}] [Verbose] MPUrlSourceSplitter_Protocol_Rtsp: instance 'Main': CurlWorker(): address: 192.168.1.217:50000, received bytes: 20994352, sent bytes: 0

From Wireshark log (packets 678 - 17156, if you use filter "(frame.number >= 678 && frame.number <= 17156) && rtp", you get raw RTP stream) there were 15809 packets, each 1328 bytes (7 MPEG2 TS packets, each 188 bytes, 12 bytes of RTP header), totally 20994352 bytes. Anyway, PAT is in packet 755, PMT is in packet 833. I'm using Wireshark 1.10.2 and I can correctly see parsed PAT and PMT.

So, at least, data were received, but I can't say if they were delivered to output pin. There's no information about this in IPTV log.

 

[georgius]

Special build with logging how much data were sent to output pin (successfully) and also how much data were flushed (in best case it should be zero).

 

[A Happy Cloud]

Special build with logging how much data were sent to output pin (successfully) and also how much data were flushed (in best case it should be zero).

Sorry for the late reply, its been a busy week. I just tested out the build, and noticed that it takes a while to find the PMT when you first tune a channel. Channel switching appears to be relatively fast however, I haven't done much testing to reach a verdict yet. I'll continue testing the filter throughout the rest of the week and post any new developments I come across. As always, here are the logs from my first test.

 

[georgius]

Special build with logging how much data were sent to output pin and also with dumped data. This can produce big files in log folder (it depends how much data are sent to next filter).

 

[T^2]

Tried the filter as instructed before... this time with logging. Noted during channel changes... Tuner 2 had live TV... then tried to change channel. LED for Tuner 2 would stay lit and LED for Tuner 1 would light up. After a while LED for Tuner 1 would go out and LED for Tuner 0 would light up (LED for Tuner 2 still lit). After a while more Tuner 0 LED would go out (Tuner 2 LED still lit) and finally the channel change would happen (on Tuner 2 apparently - Tuner 2 still lit).

Logs attached for what it's worth... Don't know at this late day if they have any value...