[Rejected] Patch to fix "No PMT" or "PMT Timout" errors (1 Viewer)

[mrwinch]

That might be only true for the specific HW / drivers you have been testing. So it would be still better to handle the error cases only (when tuning fails). Who knows if such quick pause & resume triggers another driver side bug on some other HW?

Of course and for this reason I've include also patch and compiled tvlibrary.dll so other people with same problem can check if my solution works (and not only in my configuration).

 

[tourettes]

Of course and for this reason I've include also patch and compiled tvlibrary.dll so other people with same problem can check if my solution works (and not only in my configuration).

Good approach, but it has one big flaw. How about the users (majority of the user and HW base) that aren't seeing any ill issues? They aren't going to test the patch and therefore we could introduce side effects with such change.

BDA environment is full of ugliness, this is one of those. So, we need always to take extra care with changes, trying to limit the possible side effects as much as possible (good way is to try to handle only the error cases and not to change the normal code path as it will limit the possible damage to much smaller area/user base).

 

[pilehave]

If it's any help I'll test it on my DVB-T setup, but I agree that a greater testbase than two people is needed

What version is it compiled against?

 

[quicksilver1]

hi

Just my 2 cent!

tourettes right this "fix" is a quick and dirty way, and there must be a better solution.

But right now I can't put my Mediaportal in to production because of this problem. It fail to record most of the wife’s series, as most of my channels changes PMT ID every 2 days (unhappy wife !!.... you know.

I am more than happy to try out this fix. At least I can use my MP until the right fix comes out

Using
2 floppyDTV DVB-T

 

[morpheus_xx]

I think this thread got mixed up here:

the discussed patch here should solve only the case when the PMT pids has been changed in the meantime.

what you (mrwinch) are dealing with is the, let's say "bad behaving" of some specific hardware / driver combination. mostly this issue is seen for Twinhan/Terratec cards (which are technically similiar/same)

But anyway I like your work to find a solution. I suggest following:

• Start a new thread for "tuning and pmt timeout" issue
• add other DVB types too (you only modified -S, not -C,-T)
• Add a debug log line before and after pause/resume call, so we can check the additional caused delay by these calls
• reduce the casts in your code like:

   mediacontrol = _graphBuilder as IMediaControl;
   if (mediacontrol != null)
   {
      FilterState state;
      mediacontrol.GetState(10, out state);
      if (state == FilterState.Running)
      {
         mediacontrol.Pause();
      }
   }

• Create some binaries for users to test, best for latests svn

maybe you can find a better place for pausing graph before tune request inside a "higher" class, so you don't need to modify more base classes.

 

[mrwinch]

This is the right way for discussion: sharing opinions and ideas. Well, I don't think my patch is the right solution or the best: it's only a patch and it can be improved or delete. My patch is based on idea that in some configuration directshow filter are overloaded so they crash generating this error and they required a pause: this may be right or wrong (right in my case...) but without some other test, when cannot definitely say if my idea is true or false or if generate other problem. If it works in other configuration, well we can implement in better and efficent way.

 

[morpheus_xx]

DMAN added a patch to current svn build https://forum.team-mediaportal.com/...t-09-17-2009-18-50h-revision-23652-rar-70650/

after one timeout it clears pmt pid and looks inside the PAT for service id. when a new one is found, it updates the tvdatabase. generally it's the procedure DJBlu implemented

meanwhile I also did some more testing:
I changed the "WaitForPmt" method this way, that it always do a PAT lookup. For me (DVB-C) there is no visible difference in tuning speed (60ms PAT to 40ms PMT)

PAT lookup for PMT by Service ID

17-09-2009 18:39:54.737 pmtgrabber: set callback:a1ffd8
17-09-2009 18:39:54.737 pmtgrabber: search pmt from PAT for sid:6d66
17-09-2009 18:39:54.794 Found PMT Pid 64 for ServiceId - 6d66
17-09-2009 18:39:54.795 pmtgrabber: grab pmt:64 sid:6d66
17-09-2009 18:39:54.795 pmtgrabber: got pmt 64 sid:6d66
17-09-2009 18:39:54.795 pmtgrabber: got new pmt version:20 -1, service_id:28006
17-09-2009 18:39:54.796 pmtgrabber: do callback

PMT lookup

17-09-2009 18:19:33.171 pmtgrabber: set callback:a0ffd8
17-09-2009 18:19:33.172 pmtgrabber: grab pmt:64 sid:6d66
17-09-2009 18:19:33.210 pmtgrabber: got pmt 64 sid:6d66
17-09-2009 18:19:33.210 pmtgrabber: got new pmt version:20 -1, service_id:28006
17-09-2009 18:19:33.210 pmtgrabber: do callback

the code for both ways is ready, can be switched on / off. If someone is interested in a test build, please tell me

 

[riksmith]

I guess your PAT lookup will be much quicker in the situation this patch was made for since the default timeout is something like 10 secs.

 

[morpheus_xx]

attached. you might test it.

put the "usePATLookup.txt" to c:\ to switch it on

 

[riksmith]

I did what you suggested but i don't see the logging you put up here. I see a difference tho between with and without the text file in the logging. I do not notice any zap changes.

Since i did not have the pmt timeout problems i cannot verify that is solved