Forums - When does "resetStreamingNotification" get called?

2 posts / 0 new
or Register
Last post
When does "resetStreamingNotification" get called?
jancoffee
Join Date: 9 Jun 13
Posts: 1
Posted: Wed, 2016-05-11 09:20
Top

Hi,

I'm currently using your LTE Broadcast SDK and I hope you can help me understand the "resetStreamingNotification" callback function in the IMSDCStreamingControllerEventListener, the SDK documentation says:

"Reset Notification to UI if there is any corruption in streaming service info in MSP."

* What is MSP? 

* How can I detect "if there is any corruption in streaming service info in MSP"? 

* What is the recommended action after this callback has been received? re-initialize listening for streaming services? 

* When does it get called (after starting to listening for streaming services OR after a streaming service has been start)?

Otherwise great work with the SDK,

I really appriciate the fact that you have made a Stubbed, configurable version for making the development and testing a lot easier! =)

Keep up the great work

Jan

  • Up0
  • Down0
Re: When does "resetStreamingNotification" get called?
elmira Moderator
Join Date: 11 Aug 14
Posts: 26
Posted: Wed, 2016-05-11 12:08
Top

Jan,

Thanks for using the LTE Broadcast SDK. We appreciate your feedback.

"MSP" refers to LTE Broadcast middleware. It is a typo in the document and I will make sure to fix that.

The LTE Broadcast middleware keeps the service information in its local database. If for any reason that database gets corrupted, then the previous serviceHandles may not be valid any more. Therefore the middleware sends the streamingReset notification to let the application know about it.  If the application does not store the serviceHandles and uses the latest ones after each serviceListUpdate notification, it can ignore the streamingReset notification. If not, then app needs to make sure to reset all cached serviceHandles after receiving the streamingReset notification.

Cheers,

Elmira

 

 

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.