Expiration for TMC system messages (especially ON)
Currently, Qz keeps information from TMC system messages (tuning information, service names etc.) cached forever, or until they are explicitly overwritten (which is the case for AFI network information, as well as for TMC service names, but not for Other Network (ON) information.
AFAIK the TMC specs do not mention any lifespan for this kind of information. The authors possibly assumed that receivers would discard such information upon tuning into another station—however, caching this information helps us process messages more quickly after tuning into a station, or quickly assess whether a new station is likely to have any new messages.
To sum it all up (edited to reflect changes):
AFI network records (PI, LTN, SID):
- are updated when a different LTN/SID pair is received, either from a station in that network, or when another station sends a Variant 8/9 Tuning Information message with a different LTN/SID
- are deleted when a station of that network is received and the AFI bit is unset (although, if the receiver never moves into that network’s service area and gets information on that network only via Tuning Information, the update won’t happen until the receiver actually picks up a station of that network)
- if outdated, will cause:
- incorrect message management, until the correct LTN and SID is received (until then, messages will be attributed to the wrong service, potentially causing message updates to behave incorrectly
unless addressed by #14 (closed)) incorrect tuner behavior when #9 (closed) is implemented (stations getting skipped when they shouldn’t, or not getting skipped when they should)
- incorrect message management, until the correct LTN and SID is received (until then, messages will be attributed to the wrong service, potentially causing message updates to behave incorrectly
TMC service names:
- are updated when a different service name is received for the same CC/LTN/SID tuple
- are never deleted
- if outdated, will result in incorrect service names being displayed, until the correct service name is received (which will remedy this also for messages received previously)
ON mappings:
- are never updated (which is probably OK if we have a way to delete them)
- are never deleted
- if outdated, will
result in incorrect tuner behavior when #9 (closed) is implemented (stations getting skipped when they shouldn’t, or not getting skipped when they should)- cause message updates between services to behave incorrectly (service A not updating messages from service B when it should, or updating them when it should not)
- currently have a bug that causes the latest ON mapping for a station to overwrite all previous ones in memory (not in the database)
Therefore, the question is:
- Should we keep AFI information and TMC service names until they get overwritten, or should they expire after some time?
- Is there any way to get an ON message out of the cache again?
- If we need to impose an expiration date on this information, what should it be? Ideally, it should be stable even if the device is not used/the station is not picked up for some time—something from a week to a year, I’d gravitate towards the latter.