[mythtv-users] Controlling how far into a recording the preview thumbnail snapshot is taken

[Michael T. Dean]

  On 10/06/2010 08:31 AM, Roy Lofthouse wrote:
> On 6 October 2010 13:04, George Poulson wrote:
>> On 6 October 2010 12:18, Jos Hoekstra wrote:
>>> According to:
>>>
>>> http://www.mythtv.org/wiki/User_Manual:Detailed_configuration_Frontend#View_Recordings_.284.2F8.29
>>> you can set it to a time. I'm on trunk now and don't have that setting
>>> exposed anymore.
>>> Quickscan of the db doesn't tell me where thumbnails or previews are
>>> made...

The only way to control the preview pixmap offset in trunk is to set a 
bookmark.  (And note that the bookmark is always used to create a 
preview pixmap in trunk, so you don't have to flip a (useless) switch to 
get that behavior.)

>> Thanks Jos, that will be where I've seen this before, but I too have now
>> moved to trunk so I can no see this setting!
>> A bit more 'digging' has revealed that in 0.24 the thumbnails are now
>> created by a separate application 'mythpreviewgen' which accepts a passed
>> parameter '-- seconds' for determining the offset into the recording.
>> My backend logs show that in my case it is being called with the default
>> time offset:
>> 2010-10-06 11:44:49.860 Launching: /usr/bin/mythpreviewgen --size 0x0
>> --chanid 57102 --starttime 20101005213000>  /dev/null
>> The release notes for 0.24 state:
>> Add "Smart Pixmap Preview Offset Creation" - dynamically creates thumbnail
>> preview location (and eliminates PreviewPixmapOffset setting) [23993]
>> But this doesn't seem to be working to well for me and a number of my
>> preview images are being created during what should be being flagged as
>> advertisements.

That's because the section where the preview is taken is /not/ marked as 
an advertisement--the commercial detection failed for you in that 
section.  Watch the show and you'll see that the commercial that was 
used for the preview is actually in a section that's not marked as a 
commercial.

Feel free to improve the commercial detection code.  Or, fix the broken 
flag list with a (user-edited) cut list if you like.  Or, just set a 
bookmark.

>> If this is working OK for everyone else then I guess I need to dig around in
>> the code some more to find out whether/where I can add an additional
>> parameter to control the offset
> does this offset take into account the start x mins early setting?

The smart preview pixmap offset takes into account:
     a) Start early (or start late)
     b) Time to record before start of show (secs)
     c) Program length (it uses a percentage of show length)
     d) Commercial flag list
     e) User-created cut list

The setting which allowed users to specify the offset to use for /every 
single program/ they record was a useless placebo.  There is /no/ 
possible way that a single offset will work properly for all recordings.

In order to allow the user to specify "the proper" offset to use, we'd 
have to provide an offset that's used such that it allows changing the 
value not only for which channel is used to record the show, but also 
which show is recorded (and whether it's a first-run, re-run, or 
syndicated episode).  There is /no/ way we're going to have all those 
settings.  In truth, even if we weren't opposed to the idea, it would be 
impossible to apply without serious guessing--which makes it no better 
than what we're doing now.

In other words, there's no possible way that any single value you choose 
will be more useful than any single value that's coded into the 
application.  However, the new mechanism is at least using a single 
value that takes into account program length, so

In the future, we will have support for multiple bookmarks, which will 
allow users to set a bookmark that's used specifically for the main 
preview (which can differ from the default bookmark used for playback).

The current approach in trunk is significantly better than the 
single-offset-for-all-recordings approach we previously had.  I did a 
very extensive test with >1300 recordings I have recorded over a period 
of years by backporting the smart preview pixmap offset to 0.23-fixes 
and running it on my production machine.  It was /significantly/ better 
than using /any/ single offset for all recordings.  However, (as before) 
it can fail when commercial flagging fails.

Also, since I backported/compiled/tested that patch, I have upgraded to 
more-current 0.23-fixes and did not re-add the patch to my production 
system.  And, now, I can't wait until 0.24 is released so that I get it 
back--my previews are terrible, now.  I want the better algorithm in trunk.

If you want proof that no single offset will work properly, enter every 
single recording you have and go to some offset from the recording 
start.  You'll find that in some (relatively large) percentage, you'll 
be in commercial breaks.  Which channel, which show, and which run of 
the episode will influence when you're in the commercial breaks.  So, it 
all comes down to a problem where if commercial detection fails, you may 
get a preview in the commercial break.

Mike