Skip to main content

Without cableCARD behavior

8 replies [Last post]
sivakumarmani
Offline
Joined: 2010-06-22

According OC-SP-HOST2.1-CFR-I11-100507 spec section 6.1, "The OCHD2.1 will function without a CableCARD Device and process the analog or digital signals received via the FAT channels directly...",

But in OCAP-1.1.4-B stack, in TimeZoneInitializer.java, method initTimeZone(), it seems it waits on pod ready event forever. App launcher never get launched. pod ready event get generated only after inserting a card and low level initialization.

Please clarify me that whether current OCAP-1.1.4-B behavior is not violating section 6.1 in the spec as mentioned above.

thanks,
Siva

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cpratt
Offline
Joined: 2008-12-18

Have a look at OCAP 20.2.1 (Boot Process) for more context. Here it describes both "Initialization of OCAP environment" and "Launch Auto-start Unbound Applications" as "optional" when the CableCARD device is absent.

I believe the intent is that the manufacturer-supplied "Watch TV" functionality described in HOST can be provided either as an OCAP xlet iff the host supports running OCAP applications without a CableCARD or as a non-OCAP application if not.

Also note that the environment where the "one application" in Step 5 (e.g. the Watch TV" application) runs is referred to abstractly as the "application environment" (not the more specific "manufacturer application environment" or the "cable application environment") - which also tells me that the idea is that the environment used to run the application should be considered manufacturer-dependant.

amirn
Offline
Joined: 2009-05-06

I would interpret the "optional" as optional mandatory. Meaning that if the optional feature is supported, it should be fully supported and compliant. It looks like the current RI implementation allows for the stack to start-up without CableCard.

And it even allowed for OCAP Applications to be launched, before the TimeZoneInitializer was introduced.

So, I think we should consider it a bug when OcapMain ends up blocking if isPodReady() is not true. This could actually happen even when CableCard is fully supported, since that state is heavily dependent on platform initialization and readiness.

The fix is also pretty straight forward.

cpratt
Offline
Joined: 2008-12-18

The RI may be close to being able to satisfy host requirements for CableCard-less channel navigation, but there are areas where it is definitely not operating in a card-less mode.

e.g. Per 20.2.1.4, the stack should not launch stored apps (e.g. a stored guide application) or the initial monitor app when the CC is not present - and then launch them when the CC is inserted. I don't believe this logic exists currently.

There may not be a large amount of work to be done to make the stack work in a CC-less mode. And I think some of the infrastructure is now in place. But I think we have to consider this optional feature ("C" from 20.2.1.4) unsupported until some effort is put into resolving a few missing elements.

greg80303
Offline
Joined: 2008-07-03

I believe you are correct. The stack should not be holding up initialization waiting for TimeZone information from the POD. Please create an IssueTracker issue and we will get to fixing it as soon as we can.

G

amirn
Offline
Joined: 2009-05-06

I believe the same problem exist in MPE sitp_si.c sitp_siWorkerThread()

In that case the stack may not be blocking App loading, but since the SI worker thread is block, it may prevent tuning operations.

greg80303
Offline
Joined: 2008-07-03

We are having some internal discussions on this topic. As per OCAP 20.2.1.1, describing the boot process when a CableCARD is absent:

-------------------
1. Power Applied or Reboot - The boot process is started following application of power to the set-top terminal or a software-requested reboot.

2. Hardware and Operating System Initialization - Low level initialization of the hardware and operating system.

3. Optional: Initialization of OCAP environment - All of the system modules and components of the OCAP environment are initialized and started.

4. Optional: Launch Auto-start Unbound Applications - For each abstract service in the services list that is signaled as "auto_select" by the Host Device Manufacturer, create a service context and select the abstract service in that service context.

5. Configure Environments – The implementation SHALL place exactly one application environment in the selected state. The OCAP environment MAY be placed in any of the possible environment states.

6. Begin Normal Operation – see Section 20.2.1.3 below.
-------------------

As you can see, steps 3 and 4 are optional. There is no guarantee that the OCAP stack (at least the application system) will startup without a CableCARD. We will have some internal team discussions to determine whether or not the RI will support stack startup without a CableCARD.

G

amirn
Offline
Joined: 2009-05-06

Well, Point #6 "Normal Operation" is not optional:

"At this point, the Host device has reached the normal operating state and user input is taken and processed
according to the applications that have been loaded and started through the boot process. Note that such interaction
MAY be limited while the terminal is in standby power mode (see Section 25.2.2.7.1). Normal Operation can be
'CE mode', 'watch TV', or normal cable operation. The implementation MAY present audio/video services at this
step as allowed by the security system and without first receiving consumer input. Audio/video services SHALL
NOT be presented during the boot process before this step except for EAS purposes as defined by [SCTE 18]."

Unless CE mode and WatchTV are operations perform by native (i.e. non ocap) applications, this implies that at least some part of OCAP must be initialized

amirn
Offline
Joined: 2009-05-06

Actually to fix the initial problem (blocking of stack in TimeZoneInitializer), the fix is very simple.

in OcapMain.java you can call "m_timeZoneIniter.initTimeZone()" in different thread
new Thread("timeZoneIniter")
{
public void run()
{
m_timeZoneIniter.initTimeZone();
}
}.start();

That will unblock the stack while it wait for POD to be ready.