Clarification on tuning events
I am noticing unusual behavior such that the stack times-out into alternate service content (drip feed) mode even after an apparent successful tune/decode recovery.
Here is what I am seeing:
1) Start WatchTv and it comes up fine on the 1st channel and decodes it fine.
2) According to one of the ATP tests, we need to physically disconnect the cable feed. We notice that the AV freezes. In about 10 secs, we put the feed back, but the AV does not resume.
3) We perform a channel change immediately after this, and the platform tuning takes palce fine with the AV decoding just ok.
4) After few more seconds on this decoding channel, the stack pushes the box into the alternate content (drip feed) mode - this should have never occured because we were presenting the AV just fine on this channel!
My questions are as follows:
1) Is the underlying RI implementation responsible for a tune-retry upon a signal loss (unlocked tuner condition)? Or is the stack responsible for it?
2) What is the sequence of events that the underlying RI platform implemetation needs to post to the stack when:
a) A successful tune takes place?
b) When the tuner is unlocked due to a signal loss?
c) When the tuner is unlocked due to new tune request?
3) What is the sequence of events/messages that the underlying RI platform implementation needs to post to the stack on a successful AV decoding session when:
a) The AV presentation starts?
b) The AV presentation stops on its own (due to stream deocding issues, etc)?
c) The AV presentation stops due to a channel change?
4) Is there an updated flow-diagram of these tuning & presenting sequences that can help clarify these scenarios?