[KPhotoAlbum] Thumbnails missing with latest git
rlk at alum.mit.edu
Thu Jan 15 17:42:45 GMT 2015
On Thu, 15 Jan 2015 18:18:34 +0100, Johannes Zarl wrote:
> On Thursday 15 January 2015 08:01:56 Robert Krawitz wrote:
>> On Thu, 15 Jan 2015 12:05:27 +0100, Tobias Leupold wrote:
>> >> What is the purpose behind the incremental thumbnails?
>> > I can at least answer this one: If the thumbnail size is changed, the
>> > default KPA behavior was that _all_ thumbnails were recalculated, which
>> > is painfully slow if the collection is on NFS. KPA even was e. g.
>> > unresponsive for about 15 minutes for "only" 8000 photos in my case.
>> > With the "on-demand" thumbnails, they are built as they are requested
>> > (viewed). So the lag distributes to many small operations instead of one
>> > big. This way, KPA keeps being responsive with only small lags, which is
>> > surely a more desirable behavior. For local collections the lag should be
>> > that short that the user won't really notice the thumbnail building. So
>> > in this case it doesn't hurt, and for NFS users, it's far better.
>> On the other hand, this likely means it will be slower if I read in
>> several thousand new photos and want to quickly scroll through the new
>> thumbnails. Is that correct? Normally I load the images and wait for
>> the thumbnails to build.
> No, having KPA build the thumbnails when new images are found should still work.
> You also write that your thumbnails stopped working between April and November, but the change w.r.t. on-demand building of thumbnails was last week or so...
No -- I said between Jan. 4 and Jan. 11. Sorry, I used US
Robert Krawitz <rlk at alum.mit.edu>
*** MIT Engineers Football -- Historic 10-1 2014 NEFC Champions ***
MIT VI-3 1987 - Congrats MIT Engineers 6 straight men's hoops tourney
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the Kphotoalbum