Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 2 years ago

Last modified 21 months ago

#9536 closed Bug Report (fixed)

Delete recording request not honored if issued soon after watching.

Reported by: kenneth.emerson@… Owned by: stuartm
Priority: major Milestone: 0.25
Component: MythTV - General Version: 0.24-fixes
Severity: medium Keywords: recordings delete
Cc: Ticket locked: yes

Description

If I delete a recording directly after watching it, the delete request is not honored. If I wait until the preview image is regenerated, the delete request is honored.
This bug is minor but annoying and can be worked around by waiting 5-10 seconds after watching a recording before trying to delete it.

MythTV Version : v0.24-101-gc6c50df

Using Blue Abstract-Wide theme

Attachments (0)

Change History (12)

comment:1 Changed 3 years ago by robertm

  • Status changed from new to infoneeded_new

Delete "request" from where? If preview generation is going on, which will often be the case directly after watching something, then the item is in use and myth frontend will pop up a notification that the item is in use. Are you deleting from elsewhere? Regardless of where you are performing the delete from, the above is the desired behavior, and in mythfrontend the user is notified exactly why.

comment:2 Changed 3 years ago by stuartm

  • Status changed from infoneeded_new to new

I've been able to reproduce this one for some time, there is a window before the preview generation status being updated and exiting the recording that causes this issue. Really though the popup isn't a great solution to this problem, instead we should be acting on the delete request, removing it from the list then removing the actual file once the preview generation has been completed.

comment:3 Changed 3 years ago by stuartm

  • Milestone changed from unknown to 0.25
  • Owner set to stuartm
  • Status changed from new to accepted

comment:4 Changed 3 years ago by danielk

stuartm, or we could cancel the preview request by killing the preview process. Pre-0.24 we would do the delete and just lose track of the png generated. For most that is probably preferred over how this currently works since the leak of preview images would take decades to have a noticeable effect on the capacity of a recording drive and in 2040 will be trivially addressed by running "rm *.png" in the recording directories.

comment:5 Changed 2 years ago by stuartm

  • Priority changed from minor to major

comment:6 Changed 2 years ago by gigem

Guys, we just discussed this a couple of weeks ago. AS I recall, the preferred solution is to enable AutoExpireInsteadOfDelete? and set DeletedMaxAge? to 1. Then, in the future we add a new value for DeletedMaxAge? that means expire things from the Deleted group very quickly.

comment:7 Changed 2 years ago by stuartm

Maybe so, but I'm not sure that's a 'fix' we can introduce at this stage in the feature freeze for 0.25.

comment:8 Changed 2 years ago by Github

  • Resolution set to fixed
  • Status changed from accepted to closed

Change delete behaviour so that we always use the deleted recording group allowing all recordings to be undeleted. By default we will only keep recordings for a minimum of 5 minutes (max ~20m) after their deletion, enough time to recover from a mistake but still free up space quickly. As before the user can specify to keep deleted recordings for a fixed number of days or until the space is needed for a new recording instead. Post 0.25 this change will allow us to strip out the old deletion code and simplify configuration process, the functional change is being made now to fix a couple of bugs caused by external processes such as MythPreviewGen? blocking deletes from the UI. Fixes #9536

Branch: master
Changeset: f78f9992d754390fa42f109e5139b8eaf224d076

comment:9 Changed 2 years ago by xris

Mostly just adding for posterity (since users shouldn't have to read the code to learn about this). The 'DeletedMaxAge?' setting is currently not set by default, with an autoexpire of 5 minutes. If 'DeletedMaxAge?' is set, then recordings will be auto-deleted after that many days.

Now that 0.25 is out, should we reopen this issue (per stuartm's commit message)?

FWIW, my use case for undeleting recordings is "days" not "minutes". Usually it's my wife wanting to watch something that I thought she wouldn't mind me deleting. Or her wanting to recover something the kid deleted, but has to wait for me to get home from work.

comment:10 Changed 2 years ago by stuartm

Xris, sorry but I've no idea what you're trying to say there. Could you rephrase? Is something not working for you?

comment:11 Changed 21 months ago by anonymous@…

Just a comment about this change. If your disk is nearly full and you delete some recordings, then you have to wait 5-20 minutes before you can see how much space you've freed up. Annoying! The disk space statistics in mythfrontend and mythweb should have been changed to include deleted recordings as free space. Better yet, this whole thing should be optional. I've never had any issues with accidentally deleted recordings.

comment:12 Changed 21 months ago by beirdo

  • Ticket locked set

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.