Skip to main content

Retrieving long channel names from service details

5 replies [Last post]
abysubin
Offline
Joined: 2011-07-31
Points: 0

Hi,

Issue:

While retrieving the long channel name from the service details, we are getting empty string in RI 1.1.4 code and actual source name in RI 1.2.1 code.

Reason:

In the native cache element (mpe_SiTableEntry), there are two structures present : source_names and source_long_names. The operations in populating the cache elements and retrieving are as follows in 1.1.4 and 1.2.1

RI 1.1.4 Implementation:

While parsing the SNS Subtable, we are using the method - mpe_siSetSourceLongNameForSourceId () for populating the long channel name, but it populates the structure- source_names instead of source_long_names.

While retrieving the long channel names (using methods in mpe/mgr/simgr/simgr.c- mpe_siGetNumberOfLongNamesForServiceHandle and mpe_siGetLongNamesForServiceHandle ) the iteration is done on source_long_names structure (which is not the populated one) and hence we are getting empty string as long source name.

RI 1.2.1 Implementation:

While parsing the SNS Subtable, both the source_names and source_long_names are populated with same name.

While retrieving the long channel names (using methods- mpe_siGetNumberOfLongNamesForServiceHandle and mpe_siGetLongNamesForServiceHandle) , source_names structure is being used for iteration and hence we are getting the actual source name from the service details object.

Please share your thoughts on the following queries:

1. In RI 1.2.1 code, why are we iterating on source_names structure when asked to get the long names in mpe_siGetNumberOfLongNamesForServiceHandle and mpe_siGetLongNamesForServiceHandle ? As per the current code, the source_long_names structure is redundant, right?

2. In RI 1.1.4 code, we have an obvious bug in retireving the long channel names - population is done in one structure and retrieval from another structure, right?

Regards

Aby

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

Here is what the spec says regarding service names and long names.

T.2.2.16.2 getLongName
For an inband service, when the Source Name Sub-Table is provided a component of the source_name is returned from the MTS string. When none of this sub-Table is not provided, NULL is returned.

T.2.2.3.1 getName
When the LVCT is provided the short_name is returned. When the LVCT is not provided but the Source Name Sub- Table is provided a component of the source_name is returned from the MTS string. When none of these Tables or sub-Tables are provided, an empty String object with 0 length is returned. The javadoc for this method in [Java TV] specifies the return value is the string representation of the service number if the service name is not available. This section asserts the service number is the empty string for purposes of the getName method.

So to answer your questions:

1. The RI stack is Profile-3 SI compliant i.e the OOB SI tables processed are NIT-CDS, NIT-MMS, SVCT-DCM, SVCT-VCM, NTT-SNS. The long form virtual channel table LVCT(available in higher profiles) is not supported. So based on the spec language we are returning the service name found in NTT-SNS for both service name and long name queries. The field 'source_long_name' is a place holder for when other profiles are supported.

2. Yes, looks like there is a bug in 1.1.4, it is not populating long_name field. You can file an issue for it.

abysubin
Offline
Joined: 2011-07-31
Points: 0

Thank you for the reply.

So, in RI 1.2, the field 'source_long_name' is a place holder for future support. Then, for retrieving the long channel names (in mpe_siGetNumberOfLongNamesForServiceHandle and mpe_siGetLongNamesForServiceHandle), as per the current code, we are using the field- 'source_names' and not 'source_long_name'. Won't this cause issues in the future ?

Regards

Aby

pmodem
Offline
Joined: 2008-12-17
Points: 0

We will need to fix methods

mpe_siGetNumberOfLongNamesForServiceHandle and mpe_siGetLongNamesForServiceHandle

to read the correct field 'long_source_name' and not 'source_names'. Thanks for pointing it out. I will file an internal issue to resolve it or you can file an issue tracker issue.

abysubin
Offline
Joined: 2011-07-31
Points: 0

Thank you for confirming the issues in 1.1.4 and 1.2 versions. I have raised the following Issue trackers

OCAP_RI-590 : For the issue in 1.2 version (Incorrect field being used for retrieving long channel names)

OCAP_RI-591 : For the issue in 1.1.4 version (Returning empty string as long channel name)

Regards

Aby

pmodem
Offline
Joined: 2008-12-17
Points: 0

Issue 590 has been resolved on trunk (29040).