[mythtv-users] The PNG Thumbnail generated by Default: Is it used for anything?

[Michael T. Dean]

On 05/14/2007 06:09 PM, Bruce Markey wrote:
> Michael T. Dean wrote:
>   
>> On 05/14/2007 01:20 PM, Mike Perkins wrote:
>>     
>>> Michael T. Dean wrote:
>>> <snip>
>>>> and has nothing to do with whether they're created--only whether they're 
>>>> displayed.  Short of hacking the code, you cannot stop the creation of 
>>>> these thumbnails.  We create them so that they're available /if/ they're 
>>>> ever needed because doing so doesn't hurt anything.
>>>>         
>>> It would be useful if one could get rid of them.
>>>       
>> Because you're saying that the 14MiB would be useful...how?  Compared to
>>     
> Mike, you've focused on disk space as the focal issue which,
> of course should not be an issue. What bugs me is the latency
> as the thumbnails are generated. It has to seek, decode, convert,
> and send data over the network.

There's an option:

Display thumbnail preview images of recordings
If enabled, a static image of the recording will be displayed on the 
"Watch a Recording" menu.

in the TV Playback settings that allows you to specify that Myth 
should/should not display thumbnail preview images of recordings.  If 
this is turned off, the frontend will /never/ generate a preview 
pixmap.  Therefore, you can scroll through the Watch Recordings list 
with no latency--but only if you also disable:

Display live preview of recordings
When enabled, a preview of the recording will play in a small window on 
the "Watch a Recording" menu.

Because, of course, there's no way to play back the video without 
seek/decode/convert/send...  ;)

>  The extra files in the dir can
> be annoying and a slip up in "rm *.png" could be disastrous.
>   

But, why would someone be doing an "rm *.png" in that directory.  IMHO, 
that's Myth's directory and he who messes with that directory must pay 
the price for his mistakes.  After all, do you go into FireFox's/Bon 
Echo's/Mozilla Application Suite's ~/.mozilla/firefox/*.default/Cache 
directory to delete things?  No, you let the app take care of it.  
(However, in the case of a browser cache, there are privacy issue 
involved, so the browser allows you to clear the cache--with Tools|Clear 
Private Data.  The same privacy issue does not exist in Myth because as 
long as the recording video exists on the system, it's as easy to see 
you're recording pr0n as it is through the PNG's; and Myth deletes the 
PNG's when it deletes the recordings.  Oh, and I'm pretty certain that 
"security by filesize" is not a recommended approach, so saying it takes 
longer to download a video doesn't apply.)

> It used to be that if the option was turned off, the thumbnails
> would not be created but that changed.

Right.  As a matter of fact, the setting is called 
GeneratePreviewPixmaps, even though the description (now) clearly states 
that it disables display of the thumbnails.  When I submitted the patch 
that changed the description, I didn't feel it was worth a DB update to 
change the setting name--even though it's now misleading.

So, how did it change?  Well, because of the latency involved in 
scrolling through the Watch Recordings list, Daniel worked hard to make 
a couple of changes--the first to separate preview generation into its 
own thread and the second to "pre-generate" previews at recording 
completion so they're there if they're needed.  This was in response to 
the plethora of complaints on the list about how long it took to scroll 
through the Watch Recordings list.

> Now they are created
> automatically to get a head start and this can cause latency
> on the playbackbox even if you've specifically asked not to
> show the previews.
>   

So, right now, if you disable display of preview pixmaps, the part of 
Myth that generates them is the backend.  Specifically, there's code to 
generate previews in TVRec (after a recording completes) and in the 
commercial flagging part of the JobQueue (to update the preview after 
flagging so it's not a shot from a commercial break).  Also, there are a 
couple of ways to generate previews through the network.  Oh, and TV 
allows you to generate a "screenshot" using the PreviewGenerator, but I 
know you'll agree that we should generate those even if 
GeneratePreviewPixmaps is disabled.  :)

The backend always generates the thumbnails just in case they're needed 
at some point in the future.  They may be needed when the user enables 
GeneratePreviewPixmaps at some future date or if the user adds a new 
frontend and enables GeneratePreviewPixmaps on it.  To me, it seems that 
since this all occurs in the background on the backend, it makes sense 
to create the thumbnails as long as doing so doesn't expend significant 
resources.  It's kind of like keeping up my hurricane supplies--sure, I 
may never use them, but if I do a bit at a time all the time, it makes 
things easier if I do need to use them.  :)

Of course, we've also been ignoring MythWeb's creation of preview 
thumbnails, which is now occurring through the UPnP code and creating a 
second set of thumbnails that are cached on the backend in the 
recordings directory.  So, even if we were to check the value of 
GeneratePreviewPixmaps for all hosts and generate "frontend" thumbnails 
only if one or more hosts display the pixmaps, MythWeb would still 
create PNG's--unless the user also disables MythWeb's preview thumbnails.

>> Having code to turn off preview thumbnail creation is a waste of code.
>>     
> Um, a one liner? (I won't bother with the ratio of bytes of
> code vs terabytes of recordings ;-).
>   

:)

>> Having a setting to turn off preview thumbnail creation is annoying (we 
>> have too many settings already).  And, explaining to all the users (who 
>>     
> If the preview option is turned off for all frontends then
> there should never be any pixmaps created.
>   
>> The point isn't that the thumbnail images are useful or not useful, the 
>> point is that they don't use enough resources to even allow a person 
>> <quietly>with control issues</quietly> to disable them.  ;)  If you can 
> ...interesting...
>   
>> convince me of a reason why that 14MiB of space on your recordings 
>> directory is important,
>>     
> Goody, I love a challenge! The Watch Recordings is slow to respond
> at the beginning of new recordings while the data for those 14MiB
> is being generated and written even when the preview option is
> turned off.
>   

But, if the option is truly turned off, it will have no impact on the 
Watch Recordings screen (or the rest of the frontend, as a matter of 
fact).  Back when preview generation happened only in the frontend, 
preview generation always meant a latency issue, but now that it's part 
of the backend...

Also, if you do want to enable display of preview pixmaps, I think many 
of your concerns over latency will be addressed by 
http://svn.mythtv.org/trac/ticket/3361 .  It will also address another 
concern--stability--by preventing a segfault (which--though rare--would 
have drastic consequences) from taking down the backend.

>>  I will personally write a patch to allow 
>> disabling the creation of preview thumbnail images.
>>     
> Make sure that all frontends have the preview option turned off
> so that none of the frontends (for now) need the pixmaps. If even
> one host has the option set, then enable the automatic pixmap
> generation. Use four spaces for indentation and no tabs (I'll
> test it and catch any badness before commit anyway).
>   

I'm still unconvinced of the need.  The only remaining concern I see is 
the "ugly" directory list, but IMHO, this is fixed with "mythrename.pl 
--link" and the user's staying out of Myth's recording directory.  :)

If anything were to change, I think it might be nice to move the code 
for preview "pre-generation" from the recorder and commflagging code to 
its own selectable job.  (But I'm not sure how Chris Pinkham would feel 
about that change.)  This job should default to running after 
mythcommflag (seems prettier than running preview generation at the end 
of the recording and at the end of flagging) and should be enabled by 
default.  It /could/ be made to check the value of 
GeneratePreviewPixmaps for all hosts.

Sure, by waiting until commflagging completes, there's a period of time 
between recording finish and commflag finish during which the preview 
doesn't exist, but the same is true today from recording start until 
recording end.  If a preview is needed the frontend will request it, so 
it's not an issue--this just enlarges the window during which it's not 
already available.  If that's a concern, perhaps we should generate the 
preview after PreviewPixmapOffset (plus a few) seconds.

But, checking the value of GeneratePreviewPixmaps before running a 
"Generate Preview Thumbnails" job does mean that if a user has 
GeneratePreviewPixmaps disabled on all hosts, records hundreds of shows, 
then enables GeneratePreviewPixmaps, there will be no way for her to 
generate them all in one fell swoop.  Previously--with MythWeb using the 
same thumbnails as the frontend--this could be done; now MythWeb creates 
its own set of thumbnails that get different names.  That means with 
this change, she'll have to scroll over the recording in the Watch 
Recordings list or manually kick off the "Generate Preview Thumbnails" 
job for each recording (which--if it becomes a separate job--is doable 
with playlists, but whether the user would know that is another 
question).  So, someone who starts using Myth with preview generation 
disabled will pay a huge price at the point of enabling it (possibly 
large enough that she will give up on the idea of preview thumbnails).

There's also the possibility of users wanting the PNG's--but not wanting 
them displayed by the frontend--and enabling the job but getting no 
PNG's, but that's probably enough of a corner case to ignore and explain 
on the list.

I plan to do some work that will affect the job queue, so I'll put this 
on my list of things to do at that time.  However, I'm not necessarily 
going to make it the highest-priority change on my list--you'll see it 
come in along with the other changes, and it will probably be a part of 
#3361.  (I'll probably do the separate process changes at the same time 
if it hasn't been done already, since that's something I do care about :)

> You've given your word so don't go "Dreamz" on us now (oh, yeah,
> you don't watch reality TV ;-). Good luck! It should actually
> be pretty easy and would be much appreciated.

Gotta admit I don't get the reference.  :)

Mike