[mythtv] Recent BUG: deleting from Watch Recordings

[Anduin Withers]

> "fancy" mutex? :)  I think I used the regular plain version, just a
> deletelock.lock() and deletelock.unlock.

Yeah, just a stab at what seemed like an unintuitive way to fix it.

> The issue with this is that then you'll have users saying things like,
> "I deleted this program, it disappeared from my screen, but Myth tells me
> I don't have any more space free.  I checked the recordings directory and
> the file is still there.   Wait...  OK, this is really weird, now
> it's gone????"

The current behavior is far more confusing, my suggestion doesn't preclude
you from sending an event to the backend to force it to run the delete task,
making the user apparent delete time identical to what is there now. In most
cases I'd doubt that a user would make it to the point where they could
check before the file was deleted (unlike now where accidentally playing
what you just deleted is relatively easy).

> I don't think adding another thread just to delete files is the answer,
> it would be better to use one of the existing threads like the housekeeper
> or the jobqueue even.  Either way, you'd still want to serialize the
> deletes so the mutex would be needed.  The delayed-delete (even longer
> than the current delay) could cause more user questions like the one
> above.

Sure, a new thread wouldn't need to be created, but if the purpose of the
task was to gather all deleted shows and delete them then serialization is
solved (you have a single thread deleting all requested deletes rather than
a new job per delete). Again there is no reason the delete would need to be
longer than it currently is.

If the item in the list were deactivated so you couldn't perform any action
on it the current way would be a lot better, it isn't that way though. To me
this looks like a minor bug fix cascading into a whole new bug but instead
of it only hitting those who have remote data stores that aren't mounted, it
affects every single user (well ok, only those who delete items).

> Anyway, the inactive font change is the way it will be in 0.17,
> suggestions/patches for enhancements after 0.17 are welcome, but
> if someone wants to make a patch, I suggest they post a message on
> here saying what you're implementing before coding anything just
> to make sure they're not the only one who would prefer it the way
> they are going to implement it.

If it remains this way post .17 I'll be sending a patch that implements it
the way described in my previous message (and clarified in this one). The
only functional difference that I can see between what I propose and what we
have now is a bug fix in my mind.

-- 
Anduin Withers