On Sat, 12 Mar 2005 11:58:58 -0800, Brad Templeton <[EMAIL PROTECTED]> wrote: > > I think this may be too roundabout a way to attain your real goal. > > While myth has a variety of modes to give a show permanence (no autoexpire, > no episode limit) due to bugs, you have lost shows you hoped were permanent > which is very bad.
Those are actually not permanence modes, those are "don't delete by mechanism x", but don't even try to prevent a delete by mechanism y modes. > What might be a lot simpler is for you to code a "permanence" flag (possibly > simply setting autoexpire to -1), and, in all the relevant places, working > to make those recordings permanent. Sounds great, except autoexpire wasn't responsible for deleting those shows (max_episodes was), so any solution to make autoexpire smarter-than-a-human so that it magically can replace the manual delete functionality, or any solution that involves using autoexpire to implement undelete is useless to prevent disasters like mine. This reminds me: I built a mythbox for my aunt, and one day EVERY SINGLE RECORDING (400 GBs worth) got deleted (from database and filesystem), when nobody was around. We never figured out what happened, thank god she is acustomed to windows, and expect disaters, so she didn't flip out. Responding to your suggestion: What I like BEST from the ideas I sent before is that mythtv could suggest shows to be deleted, but not do so until the user confirms. Way back before autoexpire and max_episodes the only way to delete was manually. When the auto_delete methods came along we were supposed to just trust them, with no oversight. Well I want oversight. Putting things into a delete_candidate pool would sav lots of user time searching for individual recordings to delete, even if they are not actually deleted right away. Advocates of "hard delete cuz I said so" should favor this kind of feature for the non-manual deletes, because then the computer is only doing what you say, not going behind your back. Anyway, to stay relevant, my point is this: if you are going to have an undelete mechanism, it should work for every delete method, present and future. So I think max_episodes should be an autodelete method, parallel with autoexpire_oldest, as should all future delete methods. That way a single undelete mechanism works for everything, and it makes it possible to put in a panic stop in a single place and be sure that it will prevent disasters in any autodelete code path. If this is done autoexpire really needs a new name, since it will not be based on just age anymore. > Permanent recordings, in fact, should have a link to their .nuv file put > in a second directory, so even rm can't get rid of them unless you know > what you are doing. I am using chattr +i myself. If I want to manually delete a recording today I have to tell myth to delete it, wait for the backend to say there was an error in deleting and print the actual file name, and then chattr -i manually, and delete it again. Why? because myth has proven itself to have occasional bugs or db problems that cause disasters. It would be nice if this style of supervision was integrated into myth. > The proposed plans for undo on delete would not have helped you in a bug > that was trying to purge your files. Only a deliberate robustness could > help there. Which is exactly why I stuck my nose in here. There are 3 ways that recordings can get deleted nowadays: User manually deletes them, max_episodes deletes oldest, autoexpire frees up space on-demand. I don't see any difference between them. I don't see any reason why you would want to be able to undelete programs that were nixed by one mechanism but not another. Currently I am behind on my watching of "charmed" and the backend keeps deleting the oldest episodes that i have not watched, even though there is 100GB of space laying around. Sure I could manually extend the episode_limit temporarily, but with 100GBs of free space I shouldn't have to. Here's my POV: there are only 2 reasons for ever deleting a recording, by any method: A) To free up space to be USED, not just for the sake of it being free. B) To reduce clutter in the UI. If a undelete method is written, it should not interfere with A or B, and the best method will play nice with A and B. 18 months ago myth didn't have autoexpire, or max_episodes, who knows what will be there in 18 months? Program suggestions, that get deleted first? Stuff like the sports_preemption_paranoia, or bad_reception that I described before? Trying to map every possible delete scenario into a linear range of autoexpire levels, judged by a single autoexpire_method is crazy. What will happen when a new autodelete method comes along? I'll tell you: somebody will re-adjust the coefficients that map things into that simple linear range, and a bunch of recordings will be deleted unexpectedly on user's machines. Wash, rinse, repeat every few months. I am asking for a behaviour from max_episodes that seems contrary to the name, but the desired behaviour is really specified by A and B above, guided by whatever auto_delete method is in use, not robotic deterministic adherence to the name of the auto delete method, there is no virtue in freeing up space that is not going to be used. Anyway, I am not married to any of the details in my last few messages, I am just interested in opening eyes to the fact that the way deletes work is sub-optimal, and undeletes are not going to fix all the problems. Adding things up My aunt and I have lost 600GBs worth of recordings to non-manual deletes, and maybe 1 or 2 shows to mistaken manual deletes . Thus I am more worried about max_episodes, and other auto delete methods than I am about undelete, and wanted to bring up a unifying theory of how to solve everything. A better theory is welcome, if anybody has one. I can't type much more, and I have not done a good job of explaining how I see some of these ideas working. If anybody wants to talk things out I can give you a call if you send me a number. Thanks for putting up wth me, Dan Manjarres
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev