Skip to main content

Section Filtering after NetworkInterface tune

10 replies [Last post]
tgwozdz
Offline
Joined: 2009-06-23
Points: 0

I perform a NetworkInterface tune, and get a NetworkInterfaceTuningOverEvent event with status SUCCEEDED. Then I try to set up a SectionFilter on the TransportStream associated with that NetworkInterface. However the filter gets no sections.

I also notice that right after tuning, calling NetworkInterfaceController.getNetworkInterface().getCurrentTransportStream().getTransportStreamId() returns -1, until the RI traces out:
20100928 16:29:16.169 INFO RI.Stack- IB_PAT event, ts_handle: 0x15e849e8
at which point getTransportStreamId() returns a valid value.

If I start the filter after I see this trace, then the SectionFilter works as expected.

My question is, when I get the successful NetworkInterfaceTuningOverEvent, does that imply that I'm able to use the TransportStream associated with the NetworkInterface for filtering right away? If not, how do I know when its safe to set up the SectionFilter?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pmodem
Offline
Joined: 2008-12-17
Points: 0

Expanding on what Greg said above regarding getTransportStreamID - the stack does not wait until PAT is acquired to return the value. Here is the text from Annex T of the spec. If PAT acquisition is in progress the stack simply returns a 0xFFFF.

T.2.2.21.1 getTransportStreamID
When the LVCT is available, this method returns the channel_TSID for the corresponding channel number from the
LVCT. If the LVCT is not available and the SVCT is available, this method returns the channel_TSID from the
channel_properties descriptor for the corresponding virtual_channel. If TSID is not available from either the LVCT
or SVCT, then this method SHALL use the PAT to obtain the TSID. If the TSID is not available from any source,
then this method SHALL return 0xFFFF. This method SHALL return 0xFFFF for an analog source.

khendry
Offline
Joined: 2004-08-13
Points: 0

I don't read that as indicating that it should return 0xFFFF if they PAT has not been ready yet, but that it would attempt to read the PAT if has not yet been read before returning. The statement "use the PAT to obtain the TSID" implies that it should actually be attempting to read the PAT before it would return 0xFFFF and I don't think that having not done it yet is an acceptable reason to claim that the TSID is not available from any source.

rdecker
Offline
Joined: 2009-02-25
Points: 0

You need to use a ServiceContextListener and wait for the NormalContentEvent. Then you can get the transport stream and filter it. I don't think using the NetworkInterfaceController to tune will provide that. If you use java service selection it will handle the NetworkInterfaceController tune for you and provide the aforementioned event you need to know when to start filtering.

tgwozdz
Offline
Joined: 2009-06-23
Points: 0

So this is OK that the RI is giving a successful tune event, even though the TransportStreamId isn't yet known?

greg80303
Offline
Joined: 2008-07-03
Points: 0

I believe a successful tune only implies that the hardware was able to lock onto the desired frequency and achieved "transport lock" (i.e. seeing a steady stream 0x47 packets). It makes no indication of the acquisition of PSI.

G

tgwozdz
Offline
Joined: 2009-06-23
Points: 0

Is this documented in a spec somewhere? I haven't been able to find anything that reliably states one way or the other...

greg80303
Offline
Joined: 2008-07-03
Points: 0

After looking at this a little bit more, I actually believe that the stack should allow filters to be set once the NetworkInterfaceTuningOverEvent is received. We actually have a test Xlet that uses the exact same mechanism you described to set filters.

I would recommend creating a bug on this issue. Because this is most certainly a timing-related issue and will probably difficult for us to reproduce, please attach a log of your run with JAVA level debug enabled.

G

tgwozdz
Offline
Joined: 2009-06-23
Points: 0

I created the issue for it: https://ocap-ri.dev.java.net/issues/show_bug.cgi?id=264

However, with Java trace enabled, it becomes very difficult to reproduce (in other words, the filtering succeeds most of the time). With the Java trace disabled, I can reproduce the failure 100%.

I attached trace with Java disabled, but I'll try re-running a few more times with it enabled as well.

tgwozdz
Offline
Joined: 2009-06-23
Points: 0

I tried many many times, but I can't reproduce the problem with Java trace enabled. I can reproduce it 100% with it disabled though. It could be that the trace is somehow synchronizing things in just the right way to make the timing work out correctly...

greg80303
Offline
Joined: 2008-07-03
Points: 0

Thanks anyway for trying. I think we might already have enough to go on from the information you have provided. We'll take a look at the bug to see if we can come up with a fix.

G