Michael Mayer

I found that the GORM v1 database library (we currently use) depends on `github.com/mattn/go-sqlite3` v1.14.22. So there is a small chance that this problem will improve (or even be fixed)...

Would require a two pass scan. Also processing RAWs for example takes much longer than indexing small JPEGs. Making a predicting here is more art than science, so we left...

You could use the average time per file for estimates. Just need to query the files table. Takes time until we can eventually implement this in the UI. Feature requests...

It would still be a two-pass scan, checking all folders. Depending on the file system and disk performance, this could cause unwanted side effects for some users, so it probably...

That would require a two pass scan, meaning it will be slower. Also it's possible that files or directories are added after indexing has started, meaning the number of files...

This would correspond to the `deleted_at` column in the database and seems to doable, however, this option must not be available in any other view...

Would also be interesting if there's a performance overhead and if picture quality is really the same by actually looking at (many different) results.

In that case, it should be optional (if we add / support it). We have many NAS & Raspberry Pi users that may prefer larger files vs higher CPU load....

There's also a FreeBSD port, which doesn't use Docker.

If you're using the default parameters, then the JPEG quality might be lower? In that case, you should compare the file size with the equivalent JPEG quality.