Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#1060 closed defect (invalid)

Backend crash/restart does not always resume interrupted (aborted) recordings

Reported by: justifiably@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

If the backend crashes or is restarted for some reason, then in-progress recordings are not always resumed as they used to be: they may get marked as "aborted" instead. Sometimes I see this behaviour but I have also seen the old behaviour of re-starting the recording in as a new recording. I'm not sure why the behaviour differs. Anyway, the old behaviour is much better (in case a film is half-way through and a power glitch occurs, for example).

This is on svn 8631 (but probably due to changes a wee while back).

Change History (5)

comment:1 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

Is this a multi-backend machine? If so was the recording on a slave backend?

Please try the latest SVN as well, I made some changes to this in the last couple days.

comment:2 Changed 14 years ago by justifiably@…

Yes, I have a multi-backend configuration, but only one backend (the master) has tuner cards in it. I run a slave backend on my desktop PC just to help with transcoding. Ideally I'd like the setup to work smoothly when the desktop PC isn't on 24-7, so transcoding jobs that aren't complete when it shuts down should be relinquished automatically (but that's a different issue).

I'll test the latest SVN soon and report back, but I think the problem should be easy to duplicate if still present: simply restart/kill the backend during recording and see what happens.

comment:3 Changed 14 years ago by bjm

Resolution: invalid
Status: newclosed

While the rsAborted status is new, the behavior has not changed.

http://www.mythtv.org/docs/mythtv-HOWTO-12.html#ss12.2

"Future start time beats past start time -- If there is an episode in progress and also a later showing of the same episode, it is better to record the complete episode. If there isn't another showing, start recording now to record the remaining portion. This should only happen if you add a new rule while the show is in progress or if the master backend is started after the start time of a scheduled show."

If you do want to restart the current showing rather then waiting for the complete recording, highlight the show on any scheduleing page, press Enter and click "Reactivate".

Things that have changed are; if a slave is recording when the master restarts, the scheduler will discover this and display the recording in progress as it continues, and if a recording slave fails but there is another available input and there isn't a later showing (see above) then the recording will immediately be restarted on the available card.

comment:4 Changed 14 years ago by justifiably@…

Aha, thanks for spotting this and explaining, this is probably what was happening. I'll play around to verify. Sorry for the noise.

comment:5 Changed 14 years ago by justifiably@…

Hmm. I'm reluctant to reopen this since I missed a nuance of the scheduling and obviously don't understand the internals, but I just did a couple of tests and didn't get quite the results expected:

  1. Interrupt a recording with a future repeat. Partial recording gets marked as aborted and as you suggest, future showing is lined up to be recorded (this seems to happen after a re-run of the scheduler, when I first looked at upcoming episodes, I saw "Aborted" followed by "Already recorded" for the repeat). This is good.
  1. Interrupt a recording without a future repeat. I set a recording "any time on any channel" by choosing a program from the guide. Then I restarted the backend, the recording was marked as aborted but did *not* automatically begin recording again.

This is not so good --- I want the scheduler to continue recording this show, and it should, shouldn't it?

In both cases the aborted recording does not inherit the default transcode/flag setting, see #1061.

Note: See TracTickets for help on using tickets.