Opened 19 years ago

Closed 18 years ago

Last modified 18 years ago

#190 closed defect (fixed)

Max recordings can delete recording while being watched

Reported by: kuphal@… Owned by: Isaac Richards
Priority: major Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Tonight I was watching an episode of Friends I had recorded and my recording profile specifies that a maximum of 3 episodes will be saved. At 10pm a new episode began to record and my playback halted and the frontend segfaulted (maybe related to #130). When I restarted the frontend I found the new episode recording and my episode gone.

The max recording deletion should check to see if the recording is currently being played back, and if so, abort deletion and instead let the next recording delete 2 episodes.

Attachments (1)

autoexpire-do-not-expire-playing.patch (10.1 KB) - added by danielk 19 years ago.
partial fix

Download all attachments as: .zip

Change History (13)

comment:1 Changed 19 years ago by jcaputo1 (at) comcast.net

Just wanted to point out that I *think* this behavior applies to auto-expire in general, not just the 'max episode' feature. I've been bitten by this at least once, as well.

comment:2 Changed 19 years ago by danielk

Milestone: 0.19
Owner: changed from Isaac Richards to danielk
Status: newassigned

Changed 19 years ago by danielk

partial fix

comment:3 Changed 19 years ago by danielk

Milestone: 0.190.20

I'm punting this to 0.20.

I made some mistakes in the protocol changes in the autoexpire-do-not-expire-playing.patch, so you probably don't want to use that patch. I'm attaching it so I have something to start with when I look at this again.

The solution needs something a little more complicated:

  • When deleting a program we need to first mark it as a recording being deleted, so that it can not be played.
  • Then we need to check whether it is already being played.
  • If it is being played, we need to unmark it and try the next program. Or, if it is not being played we need to delete it as we currently do.

comment:4 Changed 19 years ago by Nick Rosier

Besides checking if it's being played, you'll also need to check if commercial-flagging, transcoding or any other job is running or scheduled on the recording (ticket #301)

comment:5 Changed 18 years ago by danielk

Milestone: 0.200.19
Priority: minormajor
Severity: lowmedium

I'm changing the milestone back to 0.19.

We need to fix this to avoid bad things happening with the new LiveTV stuff.

comment:6 Changed 18 years ago by Isaac Richards

I don't think that patch will work, really - we need this in the frontend.

I was thinking of small table in the db for the recorded program that has the chanid, starttime, 'last watched' time, hostname (so it can handle multiple frontends) or maybe just a semi-random 'playback key' for multiple things (commflag/playback) playing the same file from the same frontend.

So, when the frontend starts playback, it writes the current timestamp into that table, removes it when its done playing. Have to have the NVP class update the timestamp every hour or so, and make the autoexpirer consider a timestamp > 2 hours old to be expired.

Think that's workable?

comment:7 Changed 18 years ago by danielk

I think you are right about the need for a small table, we need a table keyed to the recorded program that tells us if a program is being deleted, or being watched, and by what host. Being watched would include being part of the livetvchain. When a program is being deleted you can't start watching it, and when it is being watched you can't start deleting it. When a frontend starts up it deletes any stale watching entries in the DB, and when the backend starts up it deletes any stale 'deleting' entries in the DB. There already is some support for marking a program as 'being deleted' but I don't think the backend takes multiple backends sharing a datastore into account when deciding what programs to delete next.

comment:8 Changed 18 years ago by Isaac Richards

Can't do this on startup - that might not happen often enough. The backend housekeeper thread could easily delete old entries (> 2 hours without update). 'Watching' needs to include commflagging + transcoding, too, so this needs to go in NVP.

comment:9 Changed 18 years ago by Isaac Richards

Owner: changed from danielk to Isaac Richards
Status: assignednew

I'll do this tonight/tomorrow.

comment:10 Changed 18 years ago by danielk

Great. :)

BTW We could make the player update the table every X minutes, and have the housekeeper thread check for table entries older than X+5 minutes old. This way, we won't delete a long movie being watched, or a recording paused for 2 hours...

"Watching" would include commflagging and transcoding, basically any use of a recording in the TV class.

comment:11 Changed 18 years ago by Isaac Richards

Resolution: fixed
Status: newclosed

(In [7787]) Should fix #190.

Added a table to keep track of when a program is being watched. The player adds/deletes from this table whenever it's watching something. The autoexpirer now should skip over in-use programs.

I couldn't test the actual don't auto-expire bit, no programs to delete on my dev box.

comment:12 Changed 18 years ago by cpinkham

I should have put this in the commit log, but changeset [7812] also references this entry.

Note: See TracTickets for help on using tickets.