HDHomeRun Prime Tuner Locked (7 Viewers)

[georgius]

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

Yes, this problem we are solving. But we still don't know where exactly problem is. Can you use filter from post 79 (MPUrlSourceSplitterWithDump.zip) and do same test? Before it, clear all TV service logs. It produce logs and also dump files. After that will be easier to say, where we have problem.

 

[T^2]

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

Yes, this problem we are solving. But we still don't know where exactly problem is. Can you use filter from post 79 (MPUrlSourceSplitterWithDump.zip) and do same test? Before it, clear all TV service logs. It produce logs and also dump files. After that will be easier to say, where we have problem.

Ok... Will do as soon as I get a chance. Things are hectic at the moment though, so I can't say exactly when that will be.

 

[A Happy Cloud]

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).

Well, I finally got around to testing out MediaPortal with dumping enabled on the filter. The first test created quite a big dump file, so I ran the test a second time to produce a much smaller dump file. Hopefully these logs should aid in figuring out the cause of the excessively long PMT.

 

[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).

Well, I finally got around to testing out MediaPortal with dumping enabled on the filter. The first test created quite a big dump file, so I ran the test a second time to produce a much smaller dump file. Hopefully these logs should aid in figuring out the cause of the excessively long PMT.

I saw only one RTSP stream in each test. As I analyzed stream it seems one channel was exchanged with another channel, but RTSP stream wasn't closed. Maybe @mm1352000 will know, what happen.

 

[mm1352000]

I saw only one RTSP stream in each test. As I analyzed stream it seems one channel was exchanged with another channel, but RTSP stream wasn't closed. Maybe mm1352000 will know, what happen.

Yes this is normal.
So, how it should work is that the first channel tuned will open the RTSP session. After that when you change channels TV Server just tells the tuner to switch to a different channel without closing and re-opening the RTSP session. We do this for faster channel changes. When TV is stopped we close the RTSP session (TEARDOWN). If TV is restarted we open a new RTSP session.

 

[georgius]

Maybe is problem related to closing and opening RTSP session. Anyway, @A Happy Cloud, try to do more channel changes, if it is possible, try to change also tuners, because it seems that RTSP session is closed and opened when another tuner is used. It is not needed to capture logs after each channel changes. Just cleanup all logs before test and post all of them (with dump files) after test.

 

[A Happy Cloud]

Maybe is problem related to closing and opening RTSP session. Anyway, @A Happy Cloud, try to do more channel changes, if it is possible, try to change also tuners, because it seems that RTSP session is closed and opened when another tuner is used. It is not needed to capture logs after each channel changes. Just cleanup all logs before test and post all of them (with dump files) after test.

Ok, I conducted multiple tests by changing the channel and setting up multiple recordings and tuning to a new channel. In Test 1, I tuned to one channel, set it to record, tuned to another channel, set it to record, and then tuned to one last channel before stopping all the recordings and terminating the current live stream. Since I was tuning to HD channels, I noticed the dump file was much larger than when I've conducted testing with SD channels. Unfortunately, the dump files were way to large for me to upload, so I was only able to upload the dump files for one of the tuners along with the log files. As a result, I decided to just use SD channels for the rests of the tests to make the file sizes more manageable. For Test 2, I did the same thing I did in Test 1 but with SD channels. For Test 3, I constantly tuned to a new SD channel once the current one started streaming. In this test, I noticed it used the same tuner for maybe the first few channel changes until it appeared to stall for a bit and then decided on using a new tuner to display the channel. This happened a few more times before I decided to conclude the test. There should be enough channel changing to cause the RTSP session to open and close throughout the tests. Hope this helps!

 

[georgius]

I analyzed only TEST3 case and found something. First, filter wasn't designed to allow calling Load() method multiple times. In that case, filter drops received data. IPTV filter was always destroyed and created before calling Load() method. I know that stopping graph and calling Load() is much more faster, but in current case it doesn't work. Good news, this can be fixed

Second thing is missing data in RTSP stream. In TEST3 case was tv service started and on tuner 0 was selected BBC WORLD (PMT 0x13BA). Then was channel changed to NATIONAL GEO SD (PMT 0x053C) and then was channel changed to SCIENCE CHANNEL (PMT 0x0564). Then was channel changed to INVESTIGATION DISCOVERY, but in dumped output is nothing about that channel. In tv service log I found that for SCIENCE CHANNEL was some sequence:

[2014-03-21 16:25:10,883] [Log    ] [34       ] [INFO ] - DRI CC: tune channel 122 "Science Channel", sub channel ID 0
[2014-03-21 16:25:10,884] [Log    ] [34       ] [DEBUG] -   existing subchannel 0
[2014-03-21 16:25:10,886] [Log    ] [34       ] [INFO ] - subch:0 OnBeforeTune
[2014-03-21 16:25:10,888] [Log    ] [34       ] [DEBUG] - DRI CC: tuning...
[2014-03-21 16:25:10,904] [Log    ] [24       ] [INFO ] - DRI CC: device 7 descrambling status update, old status = Possible, new status = Unknown
[2014-03-21 16:25:11,223] [Log    ] [24       ] [INFO ] - DRI CC: device 7 descrambling status update, old status = Unknown, new status = Possible
[2014-03-21 16:25:11,573] [Log    ] [34       ] [INFO ] - subch:0 OnAfterTune

but for INVESTIGATION DISCOVERY

[2014-03-21 16:25:15,575] [Log    ] [28       ] [INFO ] - DRI CC: tune channel 123 "Investigation Discovery", sub channel ID 0
[2014-03-21 16:25:15,576] [Log    ] [28       ] [DEBUG] -   existing subchannel 0
[2014-03-21 16:25:15,578] [Log    ] [28       ] [INFO ] - subch:0 OnBeforeTune
[2014-03-21 16:25:15,580] [Log    ] [28       ] [INFO ] - DRI CC: already tuned
[2014-03-21 16:25:15,581] [Log    ] [28       ] [INFO ] - subch:0 OnAfterTune
[2014-03-21 16:25:15,583] [Log    ] [28       ] [INFO ] - RunGraph
[2014-03-21 16:25:15,584] [Log    ] [28       ] [INFO ] - DRI CC: signal locked immediately

 

[georgius]

Build with dumping data and fixed first problem when calling Load() method multiple times.

 

[mm1352000]

but for INVESTIGATION DISCOVERY

This one I can understand and explain. TV Server thinks that INVESTIGATION DISCOVERY was on the same frequency/multiplex as SCIENCE CHANNEL, so it didn't need to tune... but with CableCARD tuners you always have to tune. It is difficult to solve this problem in TVE 3; the problem is already solved in the TVE 3.5 code.