[KPhotoAlbum] Thumbnails missing with latest git

[Robert Krawitz]

Sometime between 01/04 and 01/11, thumbnails stopped working -- the
thumbnail viewer has an empty grid. I had to back out to 01/04. This
happens whether I have incremental thumbnails enabled or not.

What is the purpose behind the incremental thumbnails?
--
Robert Krawitz <***@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."
--Eric Crampton

[Tobias Leupold]

Post by Robert Krawitz
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.

Cheers, Tobias

[Robert Krawitz]

Post by Robert Krawitz
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.
--
Robert Krawitz <***@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."
--Eric Crampton

[Johannes Zarl]

Post by Robert Krawitz

Post by Tobias Leupold

Post by Robert Krawitz
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...

Cheers,
Johannes

[Robert Krawitz]

Post by Robert Krawitz

Post by Tobias Leupold

Post by Robert Krawitz
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
nomenclature :-)
--
Robert Krawitz <***@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."
--Eric Crampton

[Johannes Zarl]

Post by Johannes Zarl
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...

I just realised you are talking about January 4 and January 11. That fits the
changes. (See commit c8689d311250f8a672f0b18fa98f3cdcbd665c87 )

Post by Johannes Zarl

Post by Robert Krawitz

Post by Tobias Leupold
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?

To clarify: even with incremental thumbnails, all thumbnails for newly found
images are built from the new image finder. The difference is when you change
the thumbnail size - in this case thumbnails are only built as needed if
incremental thumbnails are enabled (which is the default).

Post by Johannes Zarl

Post by Robert Krawitz
Normally I load the images and wait for
the thumbnails to build.

I know that this is the workflow for many people - if this is broken, it is a
definite bug.

Either way, you mentioned that the thumbnail view on your machine has a
totally empty grid - that means something else must be broken, not just
incremental thumbnailing. Since your thumbnail cache seems to be working again
when you go back to a previous version, I suspect that the issue lies with
thumbnail display rather than creation...

Can you check whether the bug was introduced before or after commit
640a1e51a149d46b1e20dc29dffc5a7ba4fbf881 ?

Thanks,
Johannes

[Robert Krawitz]

Post by Johannes Zarl
To clarify: even with incremental thumbnails, all thumbnails for
newly found images are built from the new image finder. The
difference is when you change the thumbnail size - in this case
thumbnails are only built as needed if incremental thumbnails are
enabled (which is the default).

OK.

Post by Johannes Zarl

Post by Robert Krawitz
Normally I load the images and wait for
the thumbnails to build.

I know that this is the workflow for many people - if this is
broken, it is a definite bug.
Either way, you mentioned that the thumbnail view on your machine
has a totally empty grid - that means something else must be broken,
not just incremental thumbnailing. Since your thumbnail cache seems
to be working again when you go back to a previous version, I
suspect that the issue lies with thumbnail display rather than
creation...
Can you check whether the bug was introduced before or after commit 640a1e51a149d46b1e20dc29dffc5a7ba4fbf881 ?

I'll take a look later.
--
Robert Krawitz <***@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."
--Eric Crampton

[Robert Krawitz]

Either way, you mentioned that the thumbnail view on your machine has a totally empty grid - that means something else must be broken, not just incremental thumbnailing. Since your thumbnail cache seems to be working again when you go back to a previous version, I suspect that the issue lies with thumbnail display rather than creation...
Can you check whether the bug was introduced before or after commit 640a1e51a149d46b1e20dc29dffc5a7ba4fbf881 ?

That's the commit that broke it.
--
Robert Krawitz <***@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."
--Eric Crampton