I have encoutered a sort of unclarity in the method's javadoc, when reading the MHP 1.1.3 spec.
The description says that once the network interface starts tuning to another transport stream, then the monitoring stops silently and permanently.
The word "permanently" caused the confusion to me. As is goes apparently from the next sentece which says that when a referenced service is carried in the currently tuned transport stream (i guess it is the "another" one), the terminal shall monitor thes EIT p/f and report changes to (..) listeners. Shall this be treated as an exception to the "permanence" of the monitoring stop?
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.'