SharedLinkRepository.get (shared link page load, /shared-links/me, and the
OpenGraph tags rendered for /share/:key) json_agg'd every asset of the
album, with its full exif row, ordered by fileCreatedAt. The only things
used from it are the asset count and the first/last localDateTime.
Load the album without assets and fill assetCount/startDate/endDate from
getMetadataForIds, which is what GET /albums/:id already uses. The counts
now also respect the default visibility filter, and the dates are
formatted the same as on /albums/:id.
150k-asset album link, PG 14:
| | before | after |
|------------------------|-----------------|--------|
| query | 4.2-6.5 s | ~0.26 s (metadata aggregate) |
| JSON built by postgres | 261 MB | - |
| GET /shared-links/me | - | 0.28 s, 961 B |
* perf(server): stop loading every album asset to build album responses
Album create, update (rename, description, cover, sort order, activity
toggle) and add-users json_agg'd every asset of the album with its exif
row, only for mapAlbum to read the count and the first/last
localDateTime. Use getMetadataForIds for those fields, as GET /albums/:id
already does, and drop the now unused withAssets option from getById.
The responses now carry the same date format and lastModifiedAssetTimestamp
as GET /albums/:id.
PATCH /albums/:id on a 150k-asset album, PG 14 (response is ~900 B either
way): 3.4-3.6 s -> 0.13-0.16 s.
* refactor(server): share album metadata mapping
* perf(server): check shared link asset access without scanning the album
checkSharedLinkAccess runs on every thumbnail, preview, playback and asset
info request made through a shared link. It joined every asset of the
link's album and only then filtered on an array overlap across four
outer-joined columns, so each request cost O(album size).
Split it into two branches (link assets, album assets) that find the
requested ids through the asset pkey / livePhotoVideoId index and then
probe the album_asset pkey.
Median per request, PG 14, 1.36M-asset instance:
| album behind the link | before | after |
|-----------------------|--------|---------|
| 290 assets | 2.1 ms | 0.17 ms |
| 150k assets | 296 ms | 0.19 ms |
* chore: clean up
---------
Co-authored-by: Jason Rasmussen <jason@rasm.me>
When logging feature flags at startup, avoid stringifying the features
in pretty format. Multiline log messages clutter logs and make it harder
to ingest and parse in log aggregation systems like loki, graylog or
logz.io.
iPhone videos recorded with Apple Spatial Audio carry two audio tracks: an
AAC track and an APAC track that ffmpeg has no decoder for. Both are marked
default, so `compareStreams` ties on disposition and falls through to
bitrate, where the APAC track wins because spatial audio is encoded at a
higher rate. `audioStreams[0]` is then persisted and mapped into the
transcode command, and ffmpeg fails before it starts encoding:
[aist#0:2/none] Decoding requested, but no decoder found for: none
Error opening output file .../out.mp4
Error opening output files: Invalid argument
Drop audio streams ffprobe reported as `unknown` before the existing
disposition/bitrate ordering runs. A stream with no codec to decode is not a
usable audio stream, so an asset whose every audio track is unidentified is
treated as having no audio at all. The video pipeline is unchanged, since the
evidence here covers audio selection only.
Co-authored-by: Mert <101130780+mertalev@users.noreply.github.com>