De scan vult de korte volumes zelf aan #50

Merged

roelof merged 1 commit from fill-inside-the-scan into main

2026-08-05 11:49:46 +02:00

roelof commented

2026-08-05 11:48:10 +02:00

Owner

Closes #41

De vulknop was een losse knop naast de scan, en daarmee was de verzameling alleen zo heel als iemand eraan dacht. De scan is juist wat de schijf en de database weer op één lijn brengt, en een volume met een gat erin is precies dat soort verschil.

Vullen is nu de tweede stap van de scanknop: scan → vullen → artiestfoto's. Eén knop, drie verzoeken achter elkaar, en stoppen stopt de rest — dezelfde regel die de scan al volgde. Vóór de foto's, want dit is de andere helft van de bibliotheek rechtzetten en de foto's zijn versiering over wat er uiteindelijk staat.

Het vraagt niets meer, waar de knop dat wel deed. Bestanden verplaatsen op schijf is nog steeds niet terug te draaien, maar als stap van een run die toch al de tags van tienduizend bestanden herschrijft zou een dialoog middenin een karwei van uren stilleggen tot iemand terugkomt. Zeg het als je dat anders wilt — dan vraagt hij het vooraf, één keer, voordat de scan begint.

GET /api/fill wordt nog wel eerst opgevraagd, zodat een bibliotheek zonder gaten dat zegt in plaats van een taak te starten die niets verplaatst.

Op de server is niets veranderd. FillService.Plan werkte al alleen binnen de RockHeaven-collectie, en de honderd-per-volume- en één-artiest-per-volume-regel zijn van hem. Dit is puur de bedrading in de desktopspeler.

De knoppen

Van 34x28 naar 40x32, lettergrootte 14 → 15. Op de oude maat lazen ze als opsmuk bij de kolomkop, terwijl het de knoppen zijn die iets met de bibliotheek doen. De transportbalk (42x34) blijft het grootste in het venster, wat klopt: dat is wat het meest gebruikt wordt. Het geldt voor de hele .header-klasse, dus ook de knoppen boven de tracks — die twee rijen horen één maat te hebben.

Nagemeten, draaiend

Lokale server tegen de echte bibliotheek. Er is niets verplaatst: alle drie de collecties zijn volledig gescand (10802 / 2000 / 28033, gelijk aan wat er op schijf staat) en het vulplan is leeg — 802 in de overloop, geen enkel volume te kort.

De keten liep in het serverlog achter elkaar door: POST /api/scan, GET /api/fill, POST /api/artwork/artists. Daarna de fotostap gestopt via POST /api/jobs/cancel — de run sloot netjes af.
De statusregel noemt door jou bevestigd alle drie de stukken achter elkaar: de scansamenvatting, het vulstuk en de fotosamenvatting.
POST /api/fill apart aangeroepen om te zien dat een vulopdracht als eigen taak wordt geaccepteerd en met een result terugkomt (moved: 0).
De vulknop is weg en de knoppenrij is merkbaar groter — door jou gezien.

Wat hier niet draaiend te zien was, is een echte verplaatsing: daar is een volume met een gat voor nodig en dat heeft de bibliotheek nu niet. Die code (FillService) is dan ook niet aangeraakt; wat nieuw is, is de aanroep eromheen.

Onderweg één fout in mijn eigen opzet gevonden en verholpen: de vulsamenvatting overschreef eerst de scansamenvatting in plaats van eraan toegevoegd te worden — LoadAsync schrijft midden in die stap zijn eigen telling naar Status, dus de samenvatting wordt nu doorgegeven in plaats van teruggelezen.

Je afspeelpositie is weer teruggezet op wat hij was (track 424, 92,6 s).

🤖 Generated with Claude Code

Closes #41 De vulknop was een losse knop naast de scan, en daarmee was de verzameling alleen zo heel als iemand eraan dacht. De scan is juist wat de schijf en de database weer op één lijn brengt, en een volume met een gat erin is precies dat soort verschil. Vullen is nu de **tweede stap van de scanknop**: scan → vullen → artiestfoto's. Eén knop, drie verzoeken achter elkaar, en stoppen stopt de rest — dezelfde regel die de scan al volgde. Vóór de foto's, want dit is de andere helft van de bibliotheek rechtzetten en de foto's zijn versiering over wat er uiteindelijk staat. **Het vraagt niets meer**, waar de knop dat wel deed. Bestanden verplaatsen op schijf is nog steeds niet terug te draaien, maar als stap van een run die toch al de tags van tienduizend bestanden herschrijft zou een dialoog middenin een karwei van uren stilleggen tot iemand terugkomt. Zeg het als je dat anders wilt — dan vraagt hij het vooraf, één keer, voordat de scan begint. `GET /api/fill` wordt nog wel eerst opgevraagd, zodat een bibliotheek zonder gaten dat zegt in plaats van een taak te starten die niets verplaatst. **Op de server is niets veranderd.** `FillService.Plan` werkte al alleen binnen de RockHeaven-collectie, en de honderd-per-volume- en één-artiest-per-volume-regel zijn van hem. Dit is puur de bedrading in de desktopspeler. ### De knoppen Van 34x28 naar 40x32, lettergrootte 14 → 15. Op de oude maat lazen ze als opsmuk bij de kolomkop, terwijl het de knoppen zijn die iets met de bibliotheek doen. De transportbalk (42x34) blijft het grootste in het venster, wat klopt: dat is wat het meest gebruikt wordt. Het geldt voor de hele `.header`-klasse, dus ook de knoppen boven de tracks — die twee rijen horen één maat te hebben. ### Nagemeten, draaiend Lokale server tegen de echte bibliotheek. **Er is niets verplaatst**: alle drie de collecties zijn volledig gescand (10802 / 2000 / 28033, gelijk aan wat er op schijf staat) en het vulplan is leeg — 802 in de overloop, geen enkel volume te kort. - De keten liep in het serverlog achter elkaar door: `POST /api/scan`, `GET /api/fill`, `POST /api/artwork/artists`. Daarna de fotostap gestopt via `POST /api/jobs/cancel` — de run sloot netjes af. - De statusregel noemt door jou bevestigd alle drie de stukken achter elkaar: de scansamenvatting, het vulstuk en de fotosamenvatting. - `POST /api/fill` apart aangeroepen om te zien dat een vulopdracht als eigen taak wordt geaccepteerd en met een `result` terugkomt (`moved: 0`). - De vulknop is weg en de knoppenrij is merkbaar groter — door jou gezien. Wat hier **niet** draaiend te zien was, is een echte verplaatsing: daar is een volume met een gat voor nodig en dat heeft de bibliotheek nu niet. Die code (`FillService`) is dan ook niet aangeraakt; wat nieuw is, is de aanroep eromheen. Onderweg één fout in mijn eigen opzet gevonden en verholpen: de vulsamenvatting overschreef eerst de scansamenvatting in plaats van eraan toegevoegd te worden — `LoadAsync` schrijft midden in die stap zijn eigen telling naar `Status`, dus de samenvatting wordt nu doorgegeven in plaats van teruggelezen. Je afspeelpositie is weer teruggezet op wat hij was (track 424, 92,6 s). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

roelof added 1 commit

2026-08-05 11:48:11 +02:00

De scan vult de korte volumes zelf aan fe0dd849a4

De vulknop was een losse knop naast de scan, en daarmee was de verzameling
alleen zo heel als iemand eraan dacht. De scan is juist wat de schijf en de
database weer op één lijn brengt, en een volume met een gat erin is precies dat
soort verschil. Vullen is nu de tweede stap van de scanknop: scan, vullen,
artiestfoto's — één knop, drie verzoeken achter elkaar, en stoppen stopt de rest.

Vóór de foto's, want dit is de andere helft van de bibliotheek rechtzetten en
de foto's zijn versiering over wat er uiteindelijk staat.

Het vraagt niets meer, waar de knop dat wel deed. Bestanden verplaatsen op
schijf is nog steeds niet terug te draaien, maar als stap van een run die toch
al de tags van tienduizend bestanden herschrijft zou een dialoog middenin een
karwei van uren stilleggen tot iemand terugkomt. Het plan wordt nog wel eerst
opgevraagd, zodat een bibliotheek zonder gaten dat zegt in plaats van een taak
te starten die niets verplaatst.

Op de server is niets veranderd: FillService werkte al alleen binnen de
RockHeaven-collectie, en de honderd-per-volume- en één-artiest-per-volume-regel
zijn van hem.

De knoppen boven de lijsten zijn van 34x28 naar 40x32 gegaan. Op de oude maat
lazen ze als opsmuk bij de kolomkop, terwijl het de knoppen zijn die iets met de
bibliotheek doen; de transportbalk blijft het grootste in het venster.

Draaiend nagemeten: de drie stappen lopen achter elkaar en de statusregel
noemt ze alle drie.

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

roelof merged commit 34d943cbd3 into main

2026-08-05 11:49:46 +02:00

roelof deleted branch fill-inside-the-scan

2026-08-05 11:49:47 +02:00

roelof referenced this pull request from a commit

2026-08-05 11:49:47 +02:00

Merge pull request 'De scan vult de korte volumes zelf aan' (#50) from fill-inside-the-scan into main