[FEAT] EIT event: update running_status

[lyncher0]

Is your feature request related to a problem?

I'm using the plugin eitinject in an long running process and the input xml is updated every hour.
Currently we don't get the running_status of the events updated when they start (changed to running) unless I update the EIT xml more often and also keep track of the start time of each program.

Proposed solution:

I would like that an option in eitinject could be added, indicating if I would like to have the running_status of EIT events updated (according to their start time).

Alternatives:

Currently I think that the only way to achieve the update of running_status is to have an external process that generates the EIT XML file and also compares the start time of each event with the current time to update the running_status attribute. Then it needs to rewrite the XML file so eitinject is able to load the updated events.

Additional information:

[lelegard]

Hi @lyncher0,

Good question but no single response.

You would like to update the running status based on the event time. Why not. But this is probably not what the original designers of the standard had in mind.

Instead of asking "HOW do we update the running status field", the right question is "WHY do we want to update it in the first place", "what is the purpose of this field".

Setting the status to "running" based on the event time does not bring any information to the receiver. It is useless. The receiver knows the current time and knows the start & stop times of the event. Setting the status to "running" based on time is simply redundant with that. So, this cannot be the real purpose of the running status.

The usual problem with TV programs is that they are late most of the time. The EPG says "start at 21:00, stops at 22:00". However, in practice, it starts at 21:07 and ends at 22:08 (yes, longer duration, maybe enlarged commercials in the middle).

The running status is not a visual field, not something which is displayed for the end-user (unlike event name and times for instance). This is a technical field which is used by video recorders for instance, or other technical equipment which should synchronize on an event. To confirm this, see the list of values for running status in ETSI EN 300 468: "2 : starts in a few seconds (e.g. for video recording)".

This means that the value of the running status shall not be set based on time, but based on the real status of the event. In professional systems, it is set on receiving a trigger from the automation system, the one that actually starts the program, or manually from the TV control room. In all cases, the running status value shall be based on the reality, not on the schedule.

Not all systems do that. I see the following options for the running status:

• It is completely ignored, on broadcast and reception. No need to set it.
• It is set according to the reality, either manually or from an automation system, when the event actually starts and stops. It can be used by video recorders to record the actual program, not less, not more.
• It is set by the EPG, based on the start time. This is the worst possible solution. The value is redundant with the time information and useless for receivers. If a video recorder uses this field, it will start the recording too early and, much worse, stop the recording before the end of the event. In that case, to avoid event tuncation, most recorders will soon switch to time-based recording with a safety margin at the end (+30mn for instance). Which makes the running status even more useless.

So, in a real-world system, the responsibility of setting the running status belongs to an external system, not the eitinject plugin. At best, we could imagine some network interface on which eitinject listens for running status triggers. However, this is out of the scope of TSDuck which is a test, lab, debug, demo toolset.

An external system which regularly updates the XML files with events running status is both complicated, error prone, and useless.

[lyncher0]

Thanks @lelegard for the detailed explanation.

I tried to update the XML (without running status) and what I noticed is that each time the eitinject plugin reads the XML it will load all events as new events, even if the event was already present in the previous XML. The end result is that events will get duplicated.

Use case: have a XML where the new future events will be added. Update this file in a regular basis to have the new events loaded into eitinject DB.

Observed: if the same event is in the updated XML it won't be detected as "the same events that is already in the database" and it will be duplicated.

How to reproduce: create a XML with some events. After a while "touch" the file (save without changing the contents) and the events will get duplicated in EIT tables.

Maybe the expected behavior of the XML file is to have all the known events in the first version and all following update should only contain new events. Correct?

Thank you

[lelegard]

@lyncher0, this is a completely different question from the initial one of this thread. Please open a new issue for any new question or problem. Otherwise, tracking an issue becomes confusing.

Before opening a new issue with that problem, could you make more tests? I cannot reproduce the situation exactly that way. Precisely, touching an event file without changing the content, the events are not duplicated. Similarly, if you create new event files containing an exact copy of an existing event, it is not duplicated. This case is explicitly checked in the code and I see no duplication.

However, if the content of the event changes, there is a duplication. This means that when an event with the same service id / transport stream id / event id as an existing event is sent, but with a different content (start / end time, event name or any event descriptor), the two events are present, even though they have the same id. I assume that changing the running status should produce the same effect.

This is a bug and I will fix it.

In the meantime, please make sure whether you observe the same thing or not, and open a new issue for that specific problem.