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

[DJBlu]

Hi,

The following patch files will irradicate the PMT Timout errors and No PMT errors.

One thing that I haven't included into this is to send the new PMT Pid back to the TVLibrary. Sorry I did try for 4 hours but couldn't find a solution.

What these patches will do is,

If the PMT lookup timesout, the PMT Pid is set to 0, The PATSearch will look up the new PMT Pid and the TSWriter will continue. As I couldn't send the new PID to the TVLibrary it is set to 0 as to instruct the TSWriter to look for it again next time you tune to the channel.

Hope this helps.

 

[riksmith]

Perhaps it would make sense to always lookup the PMT in the PAT instead of storing it in the database.

 

[DJBlu]

Perhaps it would make sense to always lookup the PMT in the PAT instead of storing it in the database.

It is quicker to have the PMT pid stored in the database as they rarely change. This is just a feature to overcome the problem when they do change.

If you have a pid set to 0 and keep it like that then you need to search the PAT everytime which is a waste. If you know what the PID is then why look for it just incase? This will slow down your channel change time.

If the PMT timesout then look for it and update it. simple.

 

[riksmith]

Well i guess it depends on the DVB specification if it indeed rarely changes and if you are supposed to store the values. BTW does it really take that long? Your logging seems to indicate a few milliseconds. On the other hand waiting for a PMT timeout takes much longer with default settings.

 

[morpheus_xx]

Can you please clarify/confirm this?
a) When I look at the TvLibrary side of your patch, you are updating tuning details inside database with the newly found PMT pid, right? This would be used for the next tune, but not for current try?

b)

One thing that I haven't included into this is to send the new PMT Pid back to the TVLibrary

Isn't this what a) does? If not we could extend the tswriter interfaces to pass back the information we need. (I currently don't have the full source here)

In which places the new PMT pid would be needed in TvLibrary?

 

[rtv]

Nice - this would be part of a solution for "timesharing" channels. Now we just need to detect and handle (maybe retune) a changed PMT while timeshifting the channel...

 

[DJBlu]

Can you please clarify/confirm this?
a) When I look at the TvLibrary side of your patch, you are updating tuning details inside database with the newly found PMT pid, right? This would be used for the next tune, but not for current try?

b)

One thing that I haven't included into this is to send the new PMT Pid back to the TVLibrary

Isn't this what a) does? If not we could extend the tswriter interfaces to pass back the information we need. (I currently don't have the full source here)

In which places the new PMT pid would be needed in TvLibrary?

If the PMT timesout, which is caught in the TV Library it sets it to 0 updates the database with this value and sends it to the TSWriter.

This is the only method I could get to work, as I didn't know how to send the value from the TSWriter --> TVLibrary.

 

[morpheus_xx]

please check the "IPMTCallback" interface.

you could extend the method:

   /// <summary>
  /// Interface to the PMT callback 
  /// </summary>
  [ComVisible(true), ComImport,
  Guid("37A1C1E3-4760-49fe-AB59-6688ADA54923"),
  InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  public interface IPMTCallback
  {
    /// <summary>
    /// Called when the PMT has been received.
    /// </summary>
    /// <returns></returns>
    [PreserveSig]
    int OnPMTReceived();
  };

to

public int OnPMTReceived(int newPid)

then do the same in tswriter interface + member function definition.

 

[DJBlu]

Testing this last night I found a few problems.

Setting the PMT to 0 on BBC HD results in errors.

I am currently working on it. I will report back later today.

 

[riksmith]

I still think that it is NOT a good idea to store the PMT id in the database and wait for a timeout (which can take very long with the MP default settings) before looking up the (new / correct) PMT id. It is a fact that the PMT id can change, some provider however change this more often than others. For timesharing channels it can be completely different, then it is almost certain the PMT id changes at least once a day.

If the logging you provided is correct, always scanning for the PMT id (and not storing this in the database) only takes a few milliseconds. It seems to me that would be a much more straight forward way of handling this.

The same thing is going to happen when you have a timesharing channels and you need to poll for PMT changes. There is no timeout involved there either.