Demand-filled thumbnail cache #759
Unanswered
williewillus
asked this question in
Q&A and Troubleshooting
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey all. I'm evaluating photoview as a self-hosted photo gallery for my NAS. It seems like every photo gallery app sucks but this one seems to suck the least (so far).
One concern I had when reviewing the documentation is it seems like photoview, like most other photo gallery programs, wants to eagerly scan and compute thumbnails for every single photo/video found in the paths. This is fine for smaller deployments, but the dataset I want to host is massive (approaching 1T of JPEG/HEIC photos). I don't want to spend the time or disk space on eagerly generating thumbnails for everything, when it's likely that only a small subset of that collection is going to be actively viewed at any point in time (there will be around ~7 low-traffic users of this deployment).
Is there a way to have thumbnails be lazily computed and stored in a cache, and have that cache be bounded in size? I'm fine with slower initial access times to generate thumbnails and have fast operation afterward until those thumbnails drop out of the cache. The cache would use LFU/LRU/ARC or similar for eviction.
If the answer to the previous question is no, how hard would it be to allow for this model in photoview? Is it a straightforward patch or would it invalidate core assumptions in how the backend is built? If it's straightforward, I can tentatively volunteer my time to implement it.
Beta Was this translation helpful? Give feedback.
All reactions