Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] Ticket #7731: Delay file deletion in mythtranscode

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


mtdean at thirdcontact

Dec 9, 2009, 4:46 PM

Post #1 of 4 (1020 views)
Permalink
Re: [mythtv-commits] Ticket #7731: Delay file deletion in mythtranscode

On 12/09/2009 07:25 PM, MythTV wrote:
> #7731: Delay file deletion in mythtranscode
>
> Note that this patch does not change the preexisting odd behavior of
> resetting the recording's bookmark and watched flags when a cutlist is
> present.

The bookmark has to be reset after a transcode as the offset will be
completely wrong when transcoding is complete (whether the cutlist was
applied or not).

Resetting the watched flag is a judgment call, but I think the flag is
reset because otherwise, the recording is high-priority for auto-expiry
and if the user just went to the trouble of transcoding the recording,
she probably wants it to stick around at least for a little while. And,
if the user enables:

Automatically mark a recording as watched
If set, when you exit near the end of a recording it will be marked as
watched. The automatic detection is not foolproof, so do not enable this
setting if you don't want an unwatched recording marked as watched.

and then enters the recording, edits it, creates a cutlist, and exits
from near the end, the show is automatically marked as watched even
though the user didn't watch anything.*** So, in that case, it makes
sense to reset it, anyway.

Ever since the watched flag was added to MythTV, mythtranscode's
handling of it has been the same (
http://svn.mythtv.org/trac/changeset/11138 ). Also, Stuart M. mentioned
that this is the behavior of the initial patch over 2 years ago at
http://www.gossamer-threads.com/lists/mythtv/dev/222276#222276 .

Someone else (Chris Pinkham? or possibly Stuart Morgan) is likely to
know for sure why the decision was made. If someone gives an official
position on it, we can easily close
http://svn.mythtv.org/trac/ticket/7718 (with a simple patch or as invalid).

Mike

*** Before people start saying that it doesn't because they used to do
that all the time in 0.21-fixes, "Automatically mark a recording as
watched," now actually works in 0.22 and above. It did not work
properly in some circumstances if prompts were enabled, so you may never
have seen the proper behavior on older versions. So for "Automatically
mark..." users who edit cutlists but don't transcode, they'll need to
either exit from some point > 12min from the end of the recording or
reset the watched flag through the menu after exiting if they want it unset.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stichnot at gmail

Dec 9, 2009, 8:39 PM

Post #2 of 4 (929 views)
Permalink
Re: [mythtv-commits] Ticket #7731: Delay file deletion in mythtranscode [In reply to]

On Wed, Dec 9, 2009 at 4:46 PM, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 12/09/2009 07:25 PM, MythTV wrote:
>>
>> #7731: Delay file deletion in mythtranscode
>>
>> Note that this patch does not change the preexisting odd behavior of
>> resetting the recording's bookmark and watched flags when a cutlist is
>> present.
>
> The bookmark has to be reset after a transcode as the offset will be
> completely wrong when transcoding is complete (whether the cutlist was
> applied or not).

From reading the code, if there is no cutlist, then the bookmark and
watched flags are left unchanged, as are the commflag and custlist
entries in the recordedmarkup table. So it seems there is a basic
assumption that frame numbering remains consistent before and after
transcoding. (This assumption would surely be invalid if the
transcoder did something like change the frame rate.) Given that
assumption, it should be pretty simple to use the cutlist to
accurately calculate the new bookmark. Of course, if what you say is
true and the bookmark is in general invalid even when no cutlist is
applied, then the no-cutlist branch of the code must be wrong.

Now, even if the bookmark could be properly translated, there's still
a problem in that you have to somehow figure out whether the bookmark
corresponds to the original file or the transcoded file. I think you
could make a solid guess by looking for a "player" record in the
inuseprograms table and comparing its lastupdatetime field against the
time that the new filename was set in the database.

> Resetting the watched flag is a judgment call [...]

Thanks for the explanation. Personally, I'm less concerned with the
watched flag, which has only two possible values and is easy to
manually set right, and more concerned with the bookmark, which is far
more exasperating when it goes away.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Dec 9, 2009, 9:01 PM

Post #3 of 4 (942 views)
Permalink
Re: [mythtv-commits] Ticket #7731: Delay file deletion in mythtranscode [In reply to]

On 12/09/2009 11:39 PM, Jim Stichnoth wrote:
> On Wed, Dec 9, 2009 at 4:46 PM, Michael T. Dean wrote:
>
>> On 12/09/2009 07:25 PM, MythTV wrote:
>>
>>> #7731: Delay file deletion in mythtranscode
>>>
>>> Note that this patch does not change the preexisting odd behavior of
>>> resetting the recording's bookmark and watched flags when a cutlist is
>>> present.
>>>
>> The bookmark has to be reset after a transcode as the offset will be
>> completely wrong when transcoding is complete (whether the cutlist was
>> applied or not).
>>
> From reading the code, if there is no cutlist, then the bookmark and
> watched flags are left unchanged, as are the commflag and custlist
> entries in the recordedmarkup table.

Ah, yeah, it's a mark on frame number, not an offset. Too many programs
that specify it different ways, so I misremembered--I should have looked
before adding that parenthetical.

But if you do apply a cutlist, it can change, so translating it becomes
a feature request without a patch rather than not doing so being an "odd
behavior". :)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stichnot at gmail

Dec 9, 2009, 9:25 PM

Post #4 of 4 (942 views)
Permalink
Re: [mythtv-commits] Ticket #7731: Delay file deletion in mythtranscode [In reply to]

On Wed, Dec 9, 2009 at 9:01 PM, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 12/09/2009 11:39 PM, Jim Stichnoth wrote:
>>
>> On Wed, Dec 9, 2009 at 4:46 PM, Michael T. Dean wrote:
>>
>>>
>>> On 12/09/2009 07:25 PM, MythTV wrote:
>>>
>>>>
>>>> #7731: Delay file deletion in mythtranscode
>>>>
>>>>  Note that this patch does not change the preexisting odd behavior of
>>>>  resetting the recording's bookmark and watched flags when a cutlist is
>>>>  present.
>>>>
>>>
>>> The bookmark has to be reset after a transcode as the offset will be
>>> completely wrong when transcoding is complete (whether the cutlist was
>>> applied or not).
>>>
>>
>> From reading the code, if there is no cutlist, then the bookmark and
>> watched flags are left unchanged, as are the commflag and custlist
>> entries in the recordedmarkup table.
>
> Ah, yeah, it's a mark on frame number, not an offset.  Too many programs
> that specify it different ways, so I misremembered--I should have looked
> before adding that parenthetical.
>
> But if you do apply a cutlist, it can change, so translating it becomes a
> feature request without a patch rather than not doing so being an "odd
> behavior".  :)

OK, as penance for poor choice of language, I will go ahead and make a
patch. :)

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.