Hervatten wacht niet meer op de tags #59

Merged

roelof merged 1 commit from hervatten-wacht-niet-op-tags into main

2026-08-06 09:16:48 +02:00

roelof commented

2026-08-06 09:15:44 +02:00

Owner

Closes #58

Het lag niet aan de lijst maar aan wat erachteraan kwam.

De tags — speelduur, jaar en commentaar — staan niet in de database, dus de server beantwoordt /tags door elk bestand van de lijst te openen. Dat is een kost per regel, waar de lijst zelf één query is. ResumeAsync wachtte LoadTracksAsync in zijn geheel af voordat er iets klonk.

Gemeten tegen de live bibliotheek, alleen lezend:

	tijd
TOP 2000 — `collections/3/tracks` (2000 regels)	0,09 s
TOP 2000 — `collections/3/tags` (2000 bestanden)	33,6 s
RockHeaven — `volumes/9/tags` (100 bestanden)	0,82 s

Vandaar precies wat je beschrijft: een halve minuut stilte in de Top 2000, en meteen geluid in de andere. In een albumcollectie gaat het om de tien bestanden van één plaat, dus daar viel het al helemaal niet op.

Wat er verandert

LoadTracksAsync laat de tags los in plaats van erop te wachten (FillDetailsAsync), bewaakt door dezelfde generatieteller die er al stond voor het doorklikken. Er wacht niets op: de regels staan al op het scherm en de tijden vullen zichzelf in als ze binnenkomen. De covers van de rasterweergave gaan mee, om dezelfde reden.

Omdat de aanroep nu losgelaten wordt, worden zijn uitzonderingen daar gevangen en gelogd; ze halen de statusregel niet meer. De lijst staat er en is bruikbaar, en dat alleen de speelduur ontbreekt is iets voor het log en niet voor de ene regel die het venster heeft.

Nagemeten

Wegwerp-PostgreSQL, lokale server, een platte collectie van duizend bestanden, en de speler die zichzelf hervat — gemeten van procesbegin tot MPRIS Playing meldt, drie keer elk:

zonder de wijziging   2,49 s   2,61 s   2,60 s
met de wijziging      1,04 s   1,25 s   1,25 s

Dat is de beste-gevalversie: die duizend bestanden zijn hardlinks van zes stuks in een warme cache, dus de tags-aanroep kostte daar maar 1,1 s. Op de echte Top 2000 gaat het om de 33,6 s hierboven.

Closes #58 Het lag niet aan de lijst maar aan wat erachteraan kwam. De tags — speelduur, jaar en commentaar — staan niet in de database, dus de server beantwoordt `/tags` door **elk bestand van de lijst te openen**. Dat is een kost per regel, waar de lijst zelf één query is. `ResumeAsync` wachtte `LoadTracksAsync` in zijn geheel af voordat er iets klonk. Gemeten tegen de **live** bibliotheek, alleen lezend: | | tijd | |---|---:| | TOP 2000 — `collections/3/tracks` (2000 regels) | 0,09 s | | TOP 2000 — `collections/3/tags` (2000 bestanden) | **33,6 s** | | RockHeaven — `volumes/9/tags` (100 bestanden) | 0,82 s | Vandaar precies wat je beschrijft: een halve minuut stilte in de Top 2000, en meteen geluid in de andere. In een albumcollectie gaat het om de tien bestanden van één plaat, dus daar viel het al helemaal niet op. ## Wat er verandert `LoadTracksAsync` **laat de tags los** in plaats van erop te wachten (`FillDetailsAsync`), bewaakt door dezelfde generatieteller die er al stond voor het doorklikken. Er wacht niets op: de regels staan al op het scherm en de tijden vullen zichzelf in als ze binnenkomen. De covers van de rasterweergave gaan mee, om dezelfde reden. Omdat de aanroep nu losgelaten wordt, worden zijn uitzonderingen daar gevangen en gelogd; ze halen de statusregel niet meer. De lijst staat er en is bruikbaar, en dat alleen de speelduur ontbreekt is iets voor het log en niet voor de ene regel die het venster heeft. ## Nagemeten Wegwerp-PostgreSQL, lokale server, een platte collectie van duizend bestanden, en de speler die zichzelf hervat — gemeten van procesbegin tot MPRIS `Playing` meldt, drie keer elk: ``` zonder de wijziging 2,49 s 2,61 s 2,60 s met de wijziging 1,04 s 1,25 s 1,25 s ``` Dat is de **beste-gevalversie**: die duizend bestanden zijn hardlinks van zes stuks in een warme cache, dus de tags-aanroep kostte daar maar 1,1 s. Op de echte Top 2000 gaat het om de 33,6 s hierboven.

roelof added 1 commit

2026-08-06 09:15:44 +02:00

Hervatten wacht niet meer op de tags 1b1d9cfc69

Bij het opstarten bleef de speler stil als de laatst gespeelde track in de Top
2000 zat; in de andere collecties begon hij meteen. Het lag niet aan de lijst
maar aan wat erachteraan kwam.

De tags — speelduur, jaar en commentaar — staan niet in de database, dus de
server beantwoordt /tags door elk bestand van de lijst te openen. Dat is een
kost per regel waar de lijst zelf één query is. Gemeten tegen de live
bibliotheek: de tweeduizend regels van de Top 2000 komen in 0,09 s terug en hun
tags in 33,6 s, tegen 0,82 s voor de honderd van een volume. ResumeAsync wachtte
LoadTracksAsync in zijn geheel af voordat er iets afgespeeld werd, dus dat was
een halve minuut stilte — en in een albumcollectie, met tien bestanden per
plaat, viel het niet op.

LoadTracksAsync laat de tags nu los in plaats van erop te wachten
(FillDetailsAsync), bewaakt door dezelfde generatieteller die er al stond voor
het doorklikken. Er wacht niets op: de regels staan al op het scherm en de
tijden vullen zichzelf in als ze binnenkomen. De covers in de rasterweergave
gaan mee, om dezelfde reden.

Omdat de aanroep nu losgelaten wordt, worden zijn uitzonderingen daar gevangen
en gelogd; ze halen de statusregel niet meer. De lijst staat er en is bruikbaar,
en dat alleen de speelduur ontbreekt is iets voor het log en niet voor de ene
regel die het venster heeft.

Nagemeten met duizend bestanden tegen een wegwerpserver, drie keer elk: van
2,49/2,61/2,60 s naar 1,04/1,25/1,25 s. Dat is de beste-gevalversie — die
duizend zijn hardlinks van zes bestanden in een warme cache; op de echte Top
2000 gaat het om de 33,6 s hierboven.

Closes #58

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

roelof merged commit 0296452816 into main

2026-08-06 09:16:48 +02:00

roelof deleted branch hervatten-wacht-niet-op-tags

2026-08-06 09:16:48 +02:00

roelof referenced this pull request from a commit

2026-08-06 09:16:50 +02:00

Merge pull request 'Hervatten wacht niet meer op de tags' (#59) from hervatten-wacht-niet-op-tags into main