mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 05:26:47 +00:00
Maurice
2d7889c237
The picker got its photos back in whatever order the provider happened to return them. It groups by day and appends pages lazily, so an unordered page lands under the wrong heading and pushes photos out of the fold the reader is looking at. Immich now asks for order: desc on both the search and the album path. An older server that does not know the property drops it silently rather than failing, so each page is sorted again here; the album paths drain every page before sorting and are covered outright. getAssetInfo reports mediaType, the same mapping the listing already used, so the detail route and the picker agree on what an asset is. Synology gets no sort parameter upstream on either path. Search.Search documents none, and _fetchSynologyJson maps every app code except 106/107/119 onto a 400, so a parameter one DSM build rejects would take listing down entirely for that user. Both paths read every page anyway, so ordering the mapped result costs nothing and cannot fail. No media type for Synology yet, deliberately. streamSynologyAsset serves every asset as a JPEG out of SYNO.Foto.Thumbnail, original included; there is no video byte path. Labelling an asset a video would make the lightbox mount a player on a still image, which is worse than the missing badge. The badge, the byte path and the persisted media_type belong together in their own change. Five album cases in the Immich integration suite pinned the old arrival order. Where the position was incidental they now look the asset up by id; where the order is the point they state the chronological one.