Recording start/end marks set to last "now" event rather than the last

While a recording is being made, the recording's eDVBServiceRecord instance maintains a map

eventId -> PCR

for events received by m_event_handler.m_eit_changed in eDVBServiceRecord::gotNewEvent(). PCR is the Program Clock Reference.

The problem is that if more than one m_eit_changed event is received for an eventId, the most recent one is recorded, rather than keeping the oldest one.

This can be fixed by changing m_event_timestamps[event_id] = p; to m_event_timestamps.insert(make_pair(event_id, p));. The bool part of the return value insert() can be used to flag whether the insertion succeeded or not in the debug log.

I observed this as the result of a m_eit_changed event being generated when the recording's tuner lost, then regained, tune lock.

However, other users have reported additional m_eit_changed events being generated without tune lock being lost. I've attached a log extract that shows multiple m_eit_changed events being generated for a single program event without tune lock being lost and regained. I haven't been able to establish what the cause of those events is. Some are losely associated with AutoTimer scans or EPGRefresh updates, but I haven't found whether there is an actual connection. The suggested fix would also work correctly for the instances in the attached log extract.

Replication steps

Deliberately put the input signal to the T series box into the region of the "digital cliff" so that there is fairly frequent video breakup. I can do this by attaching the short stub internal antenna that was supplied with the Beyonwiz USB tuner, and placing it where it gets fairly poor reception.

Restart the GUI to get a log that only shows the test recording, and only allow one recording to run during the test.

Start a short recording with short padding (to reduce the test time). When the recording completes, check for updates to the start/stop marks (search for "pcr of eit change") against the actual transitions of the "now" data (search for "now running:"). This can be done conveniently with egrep 'pcr of eit change|now running:' <logfile>.

If the signal strength is of about the right poor quality, there will be several "pcr of eit change" log entries between "now running:" log entries. The actual start/end markers will be at the last "pcr of eit change" log entry for the program event, rather than at the first one.

If the string "Recording to" is added as third alternative search string to the egrep command, the approximate time offset of the marks in the recording can be calculated by subtracting the timestamp on the "Recording to" entry from the "pcr of eit change" entry timestamps. These can then be used to check which "pcr of eit change" entry corresponds to which recording now/next mark.

Comments (7)