This content has been marked as final. Show 2 replies
You have right. Wondering why no one replied to this?
I believe there can't be the same service when you tune to another TS.
Saying TS A has service 1, 2, 3 and TS B has service 2, 3, 4. Even thogh the contents of service 2's in TS A & B are the same, it can't be the same object because DVB triplet should be different if it follows MPEG-2 TS standard. (You may read the first sentence saying "The scope of the monitoring is determined by the original network identifier, transport stream identifier and service identifier." So different transport stream identifier(by tuning to 'another TS') means different scope of monitoring.)
The second sentence seems to say very duly thing and seems to be redundant when we see description of other similar method like "addEventScheduleMonitoringListener."
Or this may say that if terminal returns to the TS that carries the service requested to monitor of EIT PF actual, the terminal should resume monitor and report the change, which I think is also duly.
In any case, 'permenantly'(stopping...) sounds false because MHP implementations initiate EIT PF or EIT S monitor whenever it tunes(hence resume the monitoring whenever it returns to the TS), so we can't say 'permenantly.'
Edited by: Yali on Jun 13, 2010 1:53 PM