[mythtv] Exclusive access to the cutlist editor

[Jim Stichnoth]

On Wed, Sep 15, 2010 at 12:26 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
>  On 09/15/2010 01:03 AM, Jim Stichnoth wrote:
>>
>> I noticed a problem in the cutlist editor.  When you start editing, it
>> first checks whether the editing column of the recorded table is set
>> (ProgramInfo::QueryIsEditing()).  If so, it is supposed to bring up a
>> dialog prompting you whether to continue editing or not.  The problem
>> is that this dialog is not coming up for some reason.  Instead,
>> playback is simply paused.  This is easily reproduced by entering the
>> editor, forcibly restarting the frontend, and then reentering the
>> editor on the same recording.
>>
>> I wanted to ask whether anyone else is seeing this before filing a bug
>> or digging into it.  More importantly, though, I also want to ask
>> whether people think this "editing" column really has value.  My
>> opinion is that it should be removed.  It feels like there were good
>> intentions when it was introduced, but today it strikes me as an
>> incomplete solution to a not very important problem.
>
> It's going to be removed and replaced in the recordedfile schema change.  I
> just added back the code to actually set the recorded.editing field in the
> DB in [26215] (which also mentions the planned changes).  It seems we had
> lost the code in one of the rather major changes of late.  It's too late to
> make any more major changes for 0.24, so this approach should work fine for
> it, and we can modify the approach when we modify the DB schema (where we'll
> actually need to modify the approach to handle multiple files per recording
> properly)
>
> All that said, the dialog is actually working properly for me (though you
> /must/ have r26215 or higher for it to work).  If you're using a
> sufficiently new revision and still not seeing it, please try setting your
> video renderer to Xv, since the behavior you describe seems to indicate it's
> pausing and putting up a dialog, but you're just not seeing it.  If it is a
> rendering problem, I won't be of any help solving it.  :(
>
> There is one thing that seems weird, though, about the dialog.  It gives you
> 2 options, "Continue Editing," (which seems to mean, "My frontend crashed
> while I was in the middle of editing, and I want to resume editing.") and,
> "Do not edit" (yes, they do have different capitalization styles, but I only
> just noticed that because I'm looking much more closely because of your
> message).  I had assumed, "Do not edit," means "Oh, someone else is already
> editing it on another frontend system," but TV::HandleOSDAlreadyEditing()
> sets recorded.editing to false in either case, meaning if you hit EDIT (E)
> again, it will just go directly into editing mode.  I left it that way
> because I assumed it was that way for a reason, but if others agree "Do not
> edit" should mean, "Leave the state as is," I can change it.

After reading your message, I found that pressing EDIT (E) during
playback (or to be precise, typing "key e" in the telnet interface)
correctly brings up the "Continue Editing" dialog, whereas going
through the menu (Menu > Jobs > Edit Recording) fails to bring up the
"Continue Editing" dialog and leaves playback in a paused state.  This
is with r26315, and either VDPAU Normal or Slim playback profile.

But the real reason I'm posting here instead of just trying to track
down the problem is to ask whether the "Continue Editing" check is
really necessary and adding value.  Are we really so concerned about
two users actively editing the same recording at the same time?  And
we're not concerned that someone might run "mythcommflag
--clearcutlist" or "mythcommflag --gencutlist" or "mythcommflag
--setcutlist", none of which access the recorded.editing field?
Mythtranscode checks the flag once at the beginning but does nothing
to lock editing access for the remainder.  There is no code to guard
against two frontends manipulating the same program's bookmark,
watched flag, or any other property of a recording besides the
cutlist.  In short, I think recorded.editing and associated code
should be removed, and I'd like to hear other people's opinions on it.

Jim