mighty anvil
My collection currently stands at 29k photos + 7k videos = ~36k assets. I've deleted all existing thumbnails and started a new job to recreate all of them, which has so far generated 13k and lists 76k as "waiting".
My interpretation of the thumbnail settings is that each asset gets a small and a large thumbnail, which leads me to expect ~72k thumbnails in total.
However, the waiting count keeps increasing even as more thumbnails are being generated. Is this working as intended?
daring dove
more thumbnails are generated due to album covers, face detection and that kind of stuff, the more faces it detects, the more thumbnails it will create for example. These jobs will get added to the queue once a face is detected which is why you don't see them immediately
mighty anvil
makes sense, thanks for the info
partially related: is there any strategy for optimizing the concurrency options? I'm currently adjusting the thumbnail parallelism based on a shell script which checks the growth rate of the thumbs/ dir
but it feels very hacky and not too accurate
daring dove
I personally did "number of CPUs - 1" for thumbnails and "1 instance" for the rest of the jobs, but this was more based on what I did see for AVG load 1m. I also use that same machine for other stuff so I needed at least some resources available at all times. I just let it run, once the initial scan was done, keeping up isn't a big resource hogger and is quite fast
bright furnace
There is a job to generate a thumbhash, which is stored in the database so asset count x 3 is expected.
That's the "blurry thumbnail" in the web
mighty anvil
thanks, that matches my current count after regenerating all thumbnails, approx 3.4x media count
probably that 0.4x is albums/faces/maybe some orphan thumbnails
uneven igloo
Does anyone know if similar behavior applies to the Encode Clip job? When importing a large library I see the number of queued jobs increase, over the total number of items in the library and well past the number of videos (10x)