Jobs are not sceduled for the first half of half-finished recordings if the backend is restarted while a recording is in progress.

[justifiably@…]

Sometimes an interrupted recording will resume (e.g. because of backend restart) in another file. This is the preferred behaviour but doesn't seem to happen always (see related ticked #1060). In this case, however, it seems that the aborted recording(s) do not have the transcode/commercial flags set even if the schedule entry did, so for a program that is recorded in pieces the pieces have to be manually flagged/transcoded.

This is on r8631.

[anonymous]

Do you mean the first half doesn't get flagged or the second half doesn't get flagged or neither gets flagged?

[justifiably@…]

Good question. I think the final segment does get flagged/transcoded but previous segments do not. Easy to find out. A test I've just done on [8642] shows that an aborted (first) half doesn't inherit the flagging/transcoding setting, so presumably these settings are only made when a recording successfully completes.

[anonymous]

I'm going to mark this as "won't fix". These recordings aren't aborted, this is the same as if the backend had crashed or the power went out. Actual Aborted recording were aborted by the user and should have jobs scheduled for them. In that caes we currently don't know what was going on before the backend restarted (or even if it was restarted), so we can't schedule jobs for that half-finished program. If you have realtime commercial flagging turned on, it would be restarted by the JobQueue?, but if you run flagging when the recording completes, you'll have to run it manually. Also, considering what Bruce mentioned in $1061 about the way that the scheduler mady or may not reschedule the program for later when it can record the whole program, adding the logic to schedule jobs for that half a program is not a simple or possibly even desired action unless it talks to the scheduler, etc.. This is such a fringe case that needs a bit of code logic behind it, so someone will probably have to submit a patch before this is fixed.