Skip to main content

MPE PSI - PAT acquisition questions

10 replies [Last post]
amirn
Offline
Joined: 2009-05-06

I am currently looking at how PAT is being acquired in MPE and have some questions:

1. I would like to know why there is a 3000ms timeout when PSI is waiting for initial PAT section data? What would happen, for example, if there were no RF signal or that PAT is not available momentarily?
It looks like in that case there will never be a Decode call made by JMF, since an DATA_UNAVAILABLE error would be thrown and JMF would fall back to AlternativeContent.

2. My understanding is that the 3000ms is for the initial PAT acquisition and that if PAT/PMT revisioning is enabled, after 2000ms PAT would be re-acquired. Is that correct?
Would that allow JMF to still issue a Decode call, if the Tuner is still locked to the same program?

3. Should I have PAT/PMT revisioning turned on? I seem to recall there were some issues in MPE SI regarding that feature. Has that been fix in 1.1.4RelA

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
amirn
Offline
Joined: 2009-05-06

I tested with the change. It looks like this resolved the state machine issue:

======
- event = MPE_ETIMEOUT: etimeout while trying to acquire initial PAT go to idle
...
189000000:16:0x3
freq:0xb43e940
ts_handle:0x826e518
done, returning ret: 0 service_handle: 0x826f7a8
freq: 189000000 mode:QAM256
freq:0xb43e940
exit 0x826e518
- MPE_ETIMEOUT: set TsID status to SI_NOT_AVAILABLE
======

pmodem
Offline
Joined: 2008-12-17

SITP handles the timeout but leaves the filters set.
so we will continue to look for PAT even after the initial timeout.

I will confirm if the stack is handling this correctly.

pmodem
Offline
Joined: 2008-12-17

The method mpe_siGetTransportStreamHandleForServiceHandle() is to be used by Java callers that can handle a SI_NOT_AVAILABLE_YET error code which can be returned by this method and wait for PAT acquisition to complete.
But in this case SITP is the caller and it is handling a timeout. Its a catch-22. It is not expected to handle the above error code.

I will commit the change to trunk. Thanks.

amirn
Offline
Joined: 2009-05-06

For the reasons I explained in my initial post, I think it should expect to handle timeout.

But since it is not handling it now in that state, Is it fair to set the MAX timer value to forever (i.e zero).
In that use case, would the stack still handle a new Tune request correctly?

pmodem
Offline
Joined: 2008-12-17

In the method sitp_psi_state_wait_init_pat_handler() (case E_TIMEOUT)

Replace the
mpe_siGetTransportStreamHandleForServiceHandle(si_database_handle, &ts_handle) call

with
mpe_siGetTransportStreamEntryFromFrequencyModulation(g_current_ts_state_data->tuner_info.frequency, g_current_ts_state_data->tuner_info.modulation_mode, &ts_handle);

See if that works.

amirn
Offline
Joined: 2009-05-06

Okay. Do you think maybe that SI database does not contain the TS handle?
What would be the reason?

pmodem
Offline
Joined: 2008-12-17

Yeah it looks like there is a timeout acquiring initial PAT from the log snippet you attached.
Its likely the mpe_siGetTransportStreamHandleForServiceHandle() method thats returning a non success error code.

Looking into it..

pmodem
Offline
Joined: 2008-12-17

1. According to the spec(13818-1) PATs should be signaled every 100 msec. The RI implementation waits 3000 msec to compensate for delays and such. This timeout is the max timeout. If a section is received right away it will be processed immediately.
If a PAT section is not seen in 3 sec the internal states are reset so as to unblock any waiting callers (ex: JMF).

2. Your understanding is correct. 3000 msec is only for initial PAT acquisition.
If revisioning is on the SITP layer sets a negative filter and the timeout in this case is 2000 msec. If no sections matching the negative filter is received, SITP moves on to the next program in the PAT (round-robin). If a new version of PAT/PMT is seen the stack will post a table changed event (type: MODIFY). The JMF is coded to handle PAT/PMT changes.

3. PAT/PMT revisioning should always be turned on.
The issue has been resolved for a while now.

amirn
Offline
Joined: 2009-05-06

There are many reasons on a live network for PAT not being received in timely manner.:

- There could be programs with no PAT
- There could be network conditions causing PAT MPEG sections delivery to be delayed.
- There could be a signal problem,etc...

Looking at the current MPE PSI state machine, it is setting the MAX_WAIT Timeout, but then not expecting and handling MPE_ETIMEOUT event.

When I run into conditions where PAT is not delivered, the PSI stat machine is stuck in SITP_PSI_STATE_WAIT_INIT_PAT and will get MPE_TIMEOUT every 3 seconds.

The event handler is returning SITP_FAILURE in that case:
- event = MPE_ETIMEOUT: etimeout while trying to acquire initial PAT go to idle
###################
#####> ERROR <#####[4062.3058064272] 000101-00:09:28 - handler failed for event: MPE_ETIMEOUT, state: SITP_PSI_STATE_WAIT_INIT_PAT
###################

- Enter.
- Not setting machine for unknown Event: 4099.
- Exit.
- getTransportStreamDataForEvent did not get an transport stream for event: MPE_SF_EVENT_FILTER_CANCELLED, state: SITP_PSI_STATE_WAIT_INIT_PAT, tuner: 1

amirn
Offline
Joined: 2009-05-06

It looks like either mpe_siGetServiceHandleByFrequencyModulationProgramNumber or mpe_siGetTransportStreamHandleForServiceHandle is returning SITP_FAILURE. Causing the state machine to remain in the same state.