Fix gallery photo prev/next for photos with time zone
When jumping between photos in the gallery with the prev/next button, the buttons were incorrectly enabled/disabled/wouldn't work even if enabled for me. This was caused by the photos having a time zone UTC+1 (time_offset = 3600). The js frontend uses formatted timestamps including the time zone (peekFromItem.timestamp in galleryFilterParams). These are converted to a unix timestamp via UTC().UnixMilli(), so the time zone is already taken care for and adding time_offset is not necessary. For the filtering in the gallery grid itself, a unix timestamp is generated client-side (something like &start=1762124400&end=1762210800) taking the system time zone into account, so this is correct without any extra logic as well.
This is supposedly a smarter way to do ANALYZE, as it only analyzes what sqlite thinks is needful. Should hopefully address some reports of too-frequent, long-running analyze queries.
There was one time I noticed that the pragma didn't improve query plans, until I ran analyze specifically which did improve it, but that was using the old DB connection model where I had a single pool of mixed readers/writers, so maybe it's possible that the new pooling style (separate r/w pools) also addresses that, I dunno.
- New config parameter "resume_jobs" which can disable auto-resuming jobs at timeline open. (closes#159)
- Renamed "a" to "app" in one method using "Rename symbol" (not "Change all occurrences"), which surprisingly updated the identifier in ALL methods. That must be new. Anyway, that's the huge diff.
- Minor fix to metadata merge that does a more proper nil check to avoid a panic.
- Changed some omitempty to omitzero
Things would be so much easier if ubuntu just updated their packages
* ci: Attempt to fix Linux workflows
See if Copilot is worth its snuff
* Revert
* Try downgrading vipsgen instead
* Try again
* Try to install vips from source
* Sigh, ok try building from source
* Sigh
* sighhhh
* Sighhhhhhhhhhhhhhhhhhhh
* Try without cache for a moment
* Try caching again
* Try composite action
* Try again?
* Set shell on composite action steps...
* Update a couple other workflows
* Try to fix test job
* Some cleanup
* Add heif
* Oops
* Pointless comment but let's see if the cache worked
* Fix go builds
* Try installing pkg-config I guess?
* Try more pkg config paths?
* Tweak
* Are we there yet
* One more tweak
* Rename some things
The crashes on ExFAT are caused by a bug in the MacOS ExFAT driver. It is unclear whether other OSes are affected too.
https://github.com/mattn/go-sqlite3/issues/1355
We now utilize sqlite's concurrency features by creating a write pool (size 1) and a read pool, and can eliminate our own RWMutex, which prevents reads at the same time as writes. Sqlite's WAL mode allows reads concurrent with writes, and our code is much cleaner.
Still need to do similar for the thumbnail DB.
Also could look into using prepared statements for more efficiency gains.
Some certain rare edge cases were problematic, like when importing a contact list / vcard dataset after importing multiple messaging data sets, and there are entities with multiple phone numbers...
That, and a few other things are handled better. The loadEntities query has been cleaned up and corrected.
I got rid of autolink stuff with entity_attributes in the DB because it was not useful or really correct either. Added complexity causing bugs.
Imports are sometimes about 20-50% faster now.
The refactored processor had a bug where small, binary data files like images < 100 KB would be buffered entirely while peeking, and wouldn't end up being saved as a file. Fixed the logic around that and simplified a bit too.
The rendering seems inconsistent. If I refresh the page or load the results again, it fixes the color mismatches. I can't explain why they vary like this, other than potential mapbox bugs??
This does away with the experimental generation of thumbhashes during import. It's easier to generate the thumbnails and thumbhashes at the same time.
Does add a DB lock to phase1, but at this point the DB isn't the bottleneck in that phase.
