Een opgehaalde afbeelding blijft liggen #67

Merged

roelof merged 1 commit from afbeeldingen-cachen into main

2026-08-06 12:13:26 +02:00

roelof commented

2026-08-06 12:12:17 +02:00

Owner

Closes #65

De Android-helft was al gedaan

Artwork en Backdrop staan allebei op cachePolicy="memory-disk", wat meekwam met de overstap naar expo-image; de derde <Image> in de app is het meegeleverde logo en haalt niets op. Alleen op code nagekeken, niet op een toestel.

De desktopspeler gooide de cachekoppen weg

De server stuurt op elke afbeelding een ETag en een dag cachelevensduur, en HttpClient cachet niets uit zichzelf. Dus: honderd rastertegels waren honderd verzoeken telkens als het volume geopend werd, en elke start begon bij nul.

ArtworkCache legt ze onder XDG_CACHE_HOME/rockheaven/artwork — waar iets hoort dat op elk moment weg mag zijn, anders dan player.json en session.json.

De levensduur wordt gehonoreerd, dus een afbeelding binnen haar dag kost géén verzoek, ook geen voorwaardelijk. Een retourtje per tegel is seconden wachten over het internet, terwijl de bytes op een lokaal netwerk juist het goedkope deel zijn.
Na die dag maakt de ETag het verzoek voorwaardelijk en is het antwoord 304: geen bytes, en de vermelding leeft weer een dag.
Een 404 wordt ook onthouden. Niet elke artiest heeft een portret, en een artiestenlijst van duizenden bevat er veel.
Wat dat betaalt is dat de twee dingen die een afbeelding kunnen veranderen het melden: SaveTrackAsync vergeet de vijf paden die de bewerking geraakt kan hebben — niet de hele cache, want dan kost één bewerking het volgende volume weer zijn honderd tegels — en RescanCommand leegt hem in het geheel, aan het begín van de ronde zodat halverwege stoppen niets ouds achterlaat.
Een mislukt verzoek antwoordt met wat er op schijf ligt, hoe oud ook. Wat dertig dagen niet opgevraagd is wordt bij het starten opgeruimd.

Nagemeten

Lokale server, zestien hoezen, verzoeken geteld in het serverlog:

	verzoeken	tijd
ronde 1, koude cache	16	46 ms
ronde 2, nieuw proces	0	7 ms
na het legen (zoals na een scan)	16	47 ms
drie keer een 404	1
vermeldingen op drie dagen gezet	16, alle 304	36 ms
daarna opnieuw	0	7 ms

En met de echte speler erbij: eerste start haalt artiestfoto's, portretten en albumhoezen op; tweede start doet nul afbeeldingsverzoeken.

Closes #65 ## De Android-helft was al gedaan `Artwork` en `Backdrop` staan allebei op `cachePolicy="memory-disk"`, wat meekwam met de overstap naar `expo-image`; de derde `<Image>` in de app is het meegeleverde logo en haalt niets op. Alleen op code nagekeken, niet op een toestel. ## De desktopspeler gooide de cachekoppen weg De server stuurt op elke afbeelding een **ETag en een dag cachelevensduur**, en `HttpClient` cachet niets uit zichzelf. Dus: honderd rastertegels waren honderd verzoeken telkens als het volume geopend werd, en elke start begon bij nul. `ArtworkCache` legt ze onder `XDG_CACHE_HOME/rockheaven/artwork` — waar iets hoort dat op elk moment weg mag zijn, anders dan `player.json` en `session.json`. - **De levensduur wordt gehonoreerd**, dus een afbeelding binnen haar dag kost géén verzoek, ook geen voorwaardelijk. Een retourtje per tegel is seconden wachten over het internet, terwijl de bytes op een lokaal netwerk juist het goedkope deel zijn. - **Na die dag** maakt de ETag het verzoek voorwaardelijk en is het antwoord 304: geen bytes, en de vermelding leeft weer een dag. - **Een 404 wordt ook onthouden.** Niet elke artiest heeft een portret, en een artiestenlijst van duizenden bevat er veel. - **Wat dat betaalt** is dat de twee dingen die een afbeelding kunnen veranderen het melden: `SaveTrackAsync` vergeet de vijf paden die de bewerking geraakt kan hebben — niet de hele cache, want dan kost één bewerking het volgende volume weer zijn honderd tegels — en `RescanCommand` leegt hem in het geheel, aan het begín van de ronde zodat halverwege stoppen niets ouds achterlaat. - Een **mislukt verzoek** antwoordt met wat er op schijf ligt, hoe oud ook. Wat dertig dagen niet opgevraagd is wordt bij het starten opgeruimd. ## Nagemeten Lokale server, zestien hoezen, verzoeken geteld in het serverlog: | | verzoeken | tijd | |---|---:|---:| | ronde 1, koude cache | 16 | 46 ms | | ronde 2, **nieuw proces** | **0** | 7 ms | | na het legen (zoals na een scan) | 16 | 47 ms | | drie keer een 404 | **1** | | | vermeldingen op drie dagen gezet | 16, **alle 304** | 36 ms | | daarna opnieuw | **0** | 7 ms | En met de echte speler erbij: eerste start haalt artiestfoto's, portretten en albumhoezen op; **tweede start doet nul afbeeldingsverzoeken**.

roelof added 1 commit

2026-08-06 12:12:17 +02:00

Een opgehaalde afbeelding blijft liggen 6a090da850

De server stuurt op elke afbeelding een ETag en een dag cachelevensduur, en de
desktopspeler gooide allebei weg: HttpClient cachet niets uit zichzelf, dus
honderd rastertegels waren honderd verzoeken telkens als het volume geopend
werd, en elke start begon bij nul. De telefoon heeft dit sinds de overstap naar
expo-image, waarvan memory-disk precies die koppen honoreert. Dit is dezelfde
afspraak, met de hand gemaakt.

ArtworkCache legt ze onder XDG_CACHE_HOME/rockheaven/artwork — waar iets hoort
dat op elk moment weg mag zijn, anders dan player.json en session.json.

De levensduur wordt gehonoreerd, dus een afbeelding binnen haar dag kost geen
enkel verzoek, ook geen voorwaardelijk. Dat is het hele punt: een retourtje per
tegel is seconden wachten over het internet, terwijl de bytes op een lokaal
netwerk juist het goedkope deel zijn. Na die dag maakt de ETag het verzoek
voorwaardelijk en is het antwoord 304 — geen bytes, en de vermelding leeft weer
een dag.

Een 404 wordt ook onthouden. Niet elke artiest heeft een portret, en een
artiestenlijst van duizenden bevat er veel; telkens opnieuw vragen is het
traagste niets dat er is.

Wat het honoreren van die levensduur betaalt, is dat de twee dingen die een
afbeelding kunnen veranderen dat melden. SaveTrackAsync vergeet de vijf paden
die de bewerking geraakt kan hebben — niet de hele cache, want dan kost één
bewerking het volgende volume weer zijn honderd tegels — en RescanCommand
leegt hem in het geheel, aan het begin van de ronde zodat halverwege stoppen
niets ouds achterlaat.

Een mislukt verzoek antwoordt met wat er op schijf ligt, hoe oud ook: een
bibliotheek die haar hoezen niet tekent omdat het netwerk hikte is erger dan
een die die van gisteren toont. Wat dertig dagen niet opgevraagd is wordt bij
het starten opgeruimd, op een achtergronddraad.

Nagemeten tegen een lokale server met zestien hoezen:

  ronde 1, koude cache          16 verzoeken   46 ms
  ronde 2, nieuw proces          0 verzoeken    7 ms
  na het legen (zoals na scan)  16 verzoeken   47 ms
  drie keer een 404              1 verzoek
  vermeldingen drie dagen oud   16 verzoeken, alle 304, geen bytes
  daarna opnieuw                 0 verzoeken

En met de echte speler: eerste start haalt artiestfoto's, portretten en
albumhoezen op, tweede start doet nul afbeeldingsverzoeken.

De Android-kant van dit issue was al gedaan: Artwork en Backdrop staan allebei
op cachePolicy="memory-disk", en de derde <Image> in de app is het meegeleverde
logo.

Closes #65

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

roelof merged commit b3138e6760 into main

2026-08-06 12:13:26 +02:00

roelof deleted branch afbeeldingen-cachen

2026-08-06 12:13:26 +02:00

roelof referenced this pull request from a commit

2026-08-06 12:13:27 +02:00

Merge pull request 'Een opgehaalde afbeelding blijft liggen' (#67) from afbeeldingen-cachen into main