[rpcameron]

When a recording is selected for deletion, a confirmation prompt is presented to the user with No/Cancel as the default option; additional action on the part of the user to select Yes and then press Enter/Select ought to be enough on the part of the addon.

So you think it makes sense to have the same prompt when deleting 1 recording vs deleting all recordings. Even when probably 99.99% of users would never want to delete ALL of their recordings. Also you realize the GNU devs made a similar change to rm so you can't run "rm -rf /*"

So you want the addon to give you a second confirmation prompt when you are deleting a group/folder? Something like "Are you really, really, really certain you want to delete these files?" That's a bit excessive, redundant and unnecessary. And while your reference to GNU's `rm` providing a prompt for disastrous deletions is valid, other implementations of `rm` do not. GNU adds too many unneeded features and bloat to their utilities, and in general I try to use better alternatives when I can.

Furthermore, if a deletion did accidentally happen you can change the view options in the addon to display deleted recordings and then restore them. If this happens frequently enough, a user can change how long the backend waits before purging deleted recordings from disk in the backend's settings.

First, if you don't have the backend setup right, the recordings will be wiped the first time you make this mistake and any changes to the backend after that are pretty pointless. So you're still putting all the expectations on the user. Some of my recordings are pretty old and could not be replaced if I lost them. It seems like you don't think this is the case unfortunately.

So you are conceding that the problem is with your backend configuration then? If you haven't properly set up your backend, then there really isn't any need to complain. The problem is not the addon, but it is with your configuration; you cannot expect the addon to query the backend when a user does a delete, and notify the user that their backend is not set to retain deleted recordings. At some point you have to accept responsibility that the problem is user error, and not the software.

Personally I find it onerous that changes a user has made in their own personal setup in the way the application/addon responds to remote commands is a problem/bug in the addon rather than in the modified workflow. If a user made modifications to the default workflow, and that is the source of the frequent deletions, then perhaps the problems are with the modifications made, and not the addon.

I'm not sure I know what you're describing here. What are the "changes a users has made", "modified workflow", "default workflow", and "modifcations made". As far as I know am deleting files the normal way.

Part of the problem is also the setup on my remote. I have a DVR button, and depending on certain events it will go to either the current recording or the DEFAULT recording group. About 95% of the time it goes back to the current recording. The 5% of the time it returns to the DEFAULT recording group is when I delete everything. So part of the issue is figuring out why my DVR button the remote does this, but I think its a secondary issue. Even if my remote was working the way it should, I still don't want to have the chance of deleting all my recordings.

As you previously posted, you claim your problem stems from the way your remote is configured. It appears from your comments that your problem is that you don't understand your configuration.

Also, in this thread there are two posts of yours that have been edited/removed. One of those posts indicated that this situation often happens when you are tired and not fully awake/aware; removing the post showing the level of user error that is behind this situation is a bit disingenuous, wouldn't you say?

[pcmcg]

Yes, I think I was clear that either a "delete ALL" feature should be remove or there should be a second prompt.

All the blame shifting to the user isn't going to help the next person that hits this issue. I don't think it really matters what the sequence of events were or what the backend config was. And I also pointed out that even with the backend correct, it is still a pain to recover 100's of recordings accidentally sent to the deleted queue. Software that is running in your living room should be more forgiving than UNIX "rm" and maybe that means giving the user a little less rope. I'm sorry you don't agree, but I realize you have made your mind up at this point.

I think I was pretty transparent how the issue came up. I never said that it wasn't my own dumb luck that activated the "delete ALL" feature. From your post I gather you are looking for some insignificant reason to write of the categorize this as "not my problem". I don't know why you are acting like this is a personal attack, but I'd rather focus on trying to help out the next guy than worry about who to point fingers at for what has already transpired.

The thread was to report my experience and to try and improve the UI. If you think changing something is too hard or unnecessary on your end then that’s ultimately your call.

I'll leave it at that. I think we've exhaust the topic at this point. Maybe someone will see this thread and double check their backend settings. If that is the best outcome, then my time was not wasted.

[MicWit]

+1 for removing the ability to delete all recordings. Did it by accident last night and they didn't even show in mythweb as deleted items. The files were still there so moved them out of the folder so myth could not delete them, but now have heaps of files with no details for them.
As far as saying it's user error, that may be true, but as a developer, if I gave users the ability to just wipe all customer records I would be fired! Because users DO make errors and it's not very often someone wants to get rid of all recordings! So there is a 99.9% chance it was a mistake. Plus I live in a share house with devices all through the house, the others could easily make this mistake and they wouldn't know what to do to recover the files.

This is a massive problem and the ability to delete all recordings in a profile has to be removed.

[nickr]

As a developer, submit a patch!

[MicWit]

As a website developer I will have to adapt, but as soon as I get some spare time I intend to look into the plug in source code and how it works. Will see what I can work out. What language is it in?

[rpcameron]

C/C++. All of the PVR add-ons are C/C++

[rdoac]

I have a good solution to undo a mass deletion using a script I wrote. This works if the backend is configured to not immediately purge deleted recordings.

The PVR plugin should still be fixed if possible.

Can you share this? Family members keep doing this to me, we have 2TB of recordings and it takes ages to do this via mythweb.

[mitchd123]

Happened to me tonight. Working via android remote, the kodi system was laggy. I went to delete a show, and a bunch of escapes were pending execution. It seemed like slow motion, it popped me out to my default folder and then I watched the default folder be deleted rather than the one show. I lost about 6 years of mythtv shows. I'm running extundelete to attempt to recover them. I couldn't agree more a feature request particularly on the top folder. I don't see any need to even have the default folder, it's just an extra step clicking.

The commands I used were as follows:

unmounted the drive (dev/md0) which held my recordings mounted in a folder /mnt/raid/media/mythtv
the directory /mnt/raid is on my root hard drive, and the /media/mythtv is on the raid drive

umount /dev/md0 (this is my raid array)

Switched to another folder with ample free space to hold all the recordings

cd /mnt/scratch


extundelete --restore-directory media/mythv /dev/md0

This found the deleted files and put them in a directory /mnt/scratch/RECOVERED_FILES/media/mythtv/