[mythtv-users] The PNG Thumbnail generated by Default: Is it used for anything?
Michael T. Dean
mtdean at thirdcontact.com
Fri May 18 07:24:08 UTC 2007
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
More information about the mythtv-users
mailing list