Start / End bookmarks missing on recordings

[IanSav]

The start and end bookmarks can be lost in an active recording if the recording is played back via the media player while the recording is still happening.

To reproduce the issue:

• Create and allow a timer recording to start.
• Once the timer is running press MEDIA.
• Find the active recording and press OK to play it.
• Ensure that you stay in playback mode until after the recording and any padding completes. (I simply skipped back to the beginning of the recording when it was more than half way completed.)
• Stop playback.
• Start playback of the same file (no longer active) and note that the start and end bookmarks are missing.

It is also possible that the same or similar conditions created during overlapping recordings can cause bookmarks to be mishandled.

[prl]

Is there any evidence or replication steps for the possibility that "the same or similar conditions created during overlapping recordings can cause bookmarks to be mishandled"?

[IanSav]

I'll see if I can get the details from IanB or get him to add the details.

[prl]

Is there replication information for "the same or similar conditions created during overlapping recordings can cause bookmarks to be mishandled"?

[IanSav]

I don't know why IanB didn't respond but from what I understand the issue arises when there are multiple overlapping recordings on the same broadcaster / channel. The start and end markers can be written at the correct time but to the wrong recording.

[prl]

From the code I can't see how that could happen, but I might have missed something.

[prl]

If the second recording on the channel is shorter than the padding then I would expect that the markers in the first recording would be: start of program 1, end of program1/start of program 2, end of program 2.

I don't think it would be easy to fix that.

[IanSav]

Would it be possible to write each marker as soon as its trigger is encountered?

If the markers don't have to be remembered so as to be applied at the end of the recording then the fault triggers may effectively be eliminated without needing to find the exact cause.

[prl]

I don't think that's either necessary or sufficient. There remains a problem about how to merge markers when they may be being updated from two sources, the recording and its playback. They maintain independent cuelists.

I think the solution is to feed recording events into the playback class so that it knows when and from where to pull cuelist updates from the recording. But once that's done, the write of the recording's cuelist becomes a bit more complicated if the recording completes after the playback.

It's probably doable, but it may get to be a bit messy.

[IanSav]

Issue fixed in this commit by Prl.