[enhancement] Counters for total pictures and subalbums

[norey]

It's good to have a couple more fields in the About view in an album that shows

• Total number of pictures in current album and all subalbums
• Total number of subalbums in current album

[kamil4]

I would actually argue for the total picture count to be displayed in the overlay on top of each album's thumb, like we already do with the title and date (we do display the count for smart albums but not for the regular ones).

The number of subalbums is easy, so long as we are talking about only the direct children of the current album, not recursive subalbums.

The total number of pictures, including in subalbums, strikes me as much harder to implement efficiently than it would seem, though. We currently don't keep track of the count, so either we would need to add such a field to the albums table (and keep it up to date whenever we add/delete/move anything in the album or any of its subalbums) or we would need to calculate it on-the-fly, which could get inefficient pretty quickly for large installations. @ildyria, what do you think?

[ildyria]

The total number of pictures, including in subalbums, strikes me as much harder to implement efficiently than it would seem, though. We currently don't keep track of the count, so either we would need to add such a field to the albums table (and keep it up to date whenever we add/delete/move anything in the album or any of its subalbums) or we would need to calculate it on-the-fly, which could get inefficient pretty quickly for large installations. @ildyria, what do you think?

As usual this is quite a tricky one because it varies in function of the person seing it. Also may "reveal" hidden albums etc.. This is pretty much tied to the sharing system and the thumbnail.

Adding a counter in the album part is not going to work due to the fluctuation (in contrary to last take date field which does not reveal as much info.

[kamil4]

Good point. Frankly, I'm breathing a sigh of relief that a counter in the albums table is not going to work. It struck me as something that would be a royal PITA to get to work reliably.

So the count will have to be generated at run time then. If this is implemented, a config setting may need to be provided to disable this feature for large installations where the overhead could be significant...

[norey]

What about an on demand button? e.g. "Get number of pictures" that will do the counting when executed by the user. That way, the user waits for it since they already know what they requested which could take some time.

[kamil4]

BTW, the easy part of this request (the count of subalbums) was implemented in LycheeOrg/Lychee-front#94. It is displayed in the info sidebar, along with image and video counts.

[pseudex]

today I updated from 4.1 to 4.2.2 and it looks like the counts are gone. Is there a new setting I miss?

[ildyria]

today I updated from 4.1 to 4.2.2 and it looks like the counts are gone. Is there a new setting I miss?

Most likely a bug. Can you open a new issue of that as this is unrelated to this one.

[kamil4]

Do you mean the counts for smart albums? That was removed as a speed optimization...

[pseudex]

I'm talking about the counts on the (Smart) Album covers. I use the tags for marking persons in them. Was interesting to see how many photos are tagged. If it was remove because of speed, why did you remove it also for the recent album? A Select just for a count on photos looked up by an indexed column should be fast enough?

Update: btw. I really love the speed of this program. One of the reason I'm importing my nextlcoud pictures in here and not use "slowcloud"!

[kamil4]

To tell you the truth, this was broken semi-accidentally. @ildyria did a huge refactoring of the server code between 4.1 and 4.2, in the process vastly reducing the number of SQL queries performed on the initial load of the albums list (which was a big performance issue for users with many nested albums; it could take 20 seconds or more for that list to be generated on slow servers).

With a refactoring this large, some things inevitably break in the process, and that was the case with the counts. Because we were still in the "must minimize the number of SQL queries" mindset, we figured that simply removing the counts from the few albums that had them was the easiest thing to do.