On Wed, Mar 09, 2005 at 06:48:56PM -0500, andrew burke wrote: > > Undelete offers the ability to fix that, even if you didn't know > > in advance, the other person didn't know they had to "register" as > > a planned watcher etc. > > > > In general, I don't see any reason why you don't want undo anywhere > > you can get it easily. > > I think these arguments are good, but they are not related to the watcher > list. > > Reversible deletion is a separate issue. It doesn't solve the 'should I > delete this?' problem, which a watchers list does. A watchers list > doesn't solve the 'oh shit, I shouldn't have deleted that.' problem, which > this would.
Actually, I believe it does deal with both problems to a degree. A watcher's list is a useful feature, but complex. You now have users having to go to recordings and entering their names (ideally only once) And when they have watched to go to a menu and pick off their name, and anybody else in the room with them etc. Certainly doable but a touch ugly and possibly only minimally used. Undo allows you to delete a program with impugnity. If somebody else wanted to watch it, they can get it back (within a given amount of time.) Of course, don't delete it if you know they want to watch it but now it's not a nasty sin. A watch count has the nice advantage of requiring no user action. It simply counts the number of times the program has been watched. It is displayed in the delete/end-of-program menu. In a typical household, most people are going to know what shows are the favourite of whom, the human brain being reasonably decent about this. Not that it wouldn't be better to be fully accurate, but the question is, would people really use it. However, I have no problem with folks coding the watch lists and ability to claim watching. I just am advising that features which require no special user behaviour get used a lot more and more effectively. As for undo on delete, I believe I have a workable solution. Namely, I would consider modifying autoexpire so it has 2 space numbers. One is how much space to keep free (which it already has), and the other is how much space to allocate for undo of delete. If this 2nd number is set to zero, no space is set for that, and delete will be near-hard delete. (What I would actually recommend is that delete is acted on on the 2nd pass of autoexpire after the user requests delete, which is usually in about 20 minutes. If you need to reclaim the space now-now-now, I would recommend going to the actual delete screen which could offer hard delete etc.) If the second number is set to a value, like 10gb, then up to 10gb of deleted programs could be kept to allow undo. Even if you allowed a large buffer for undo, I don't think it would interfere with dvd-rips and cd-rips because they are not that fast, and autoexpire runs moderately frequently in any event. The only thing that would hit you up would be raw file copies of very large piles of disk. If that's in your plan, you would be advised not to leave a large undo buffer, or to manually run autoexpire. This should address most of the concerns I have seen. On the other hand no point in us coding it if Isaac remains uninterested in having the function. Mainly I suggested it because with the current autoexpire it was very easy to code, literally just a few lines in a few places. It's getting more complex. :-)
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
