[mythtv] Recent BUG: deleting from Watch Recordings

[Chris Pinkham]

> > Just to be sure: will making the item _appear_ inactive also prevent
> > users from performing any action on it? (Like popping op its meny and
> > selecting play or whatever) Strange things might happen otherwise I
> > imagine :-)
> 
> The answer: no.

That would have been quite a few other changes and probably too much to
go in right before 0.17.

The font change is a quick workaround to the fact that the recording
doesn't disappear right away.  We know there's probably better ways
to handle this, but making the changes necessary to implement them
would probably be too invasive just a day or two before 0.17.

> I would have much rather seen the queries to find recorded programs just
> have a new check to see if the delete field was set. Instant response as
> before, no playing a program when you just deleted it (this does happen, it
> happened to my other user last night, I can reproduce it with CVS as of 15
> minutes ago).
>
> Then you just kickoff a thread in the backend to gather all deleted programs
> and delete them (ensuring that something will be deleted eventually). No
> fancy mutex to keep thing synchronous, the new threat is having a show that
> failed to delete not reappear which could be easily fixed by having the
> delete thread disable the delete field if deletion failed.

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

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????"

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.

I debated making the show disappear from the screen immediately when
you hit delete, but that would allow the potential issue you mention
of the recording reappearing if the delete failed.  It would have also
required more work than the simple way the font is changed currently.

I also thought about the idea of changing the subtitle display in the
recordings listbox on the right to add something like "[Deleting]" as
a visual indicator, but am not sure what people think about that.  This
along with preventing the user from taking any further action on a
recording after deleting it may be a better way to go than having them
disappear right away but not be deleted right away.  This would have
also required translation updates which is part of the reason why it
wasn't coded.

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.

-- 

Chris