Files
Sucukdeluxe 39fbc54818 Fix: Start-Konflikt-Waechter friert nach Update nicht mehr die ganze Liste ein
Nach einem Auto-Update-Neustart blieb die komplette Warteschlange stehen
(running=false, hunderte Items wartend), obwohl Auto-Resume aktiv war.
Ursache war der Start-Konflikt-Waechter:

- getStartConflicts() meldete jedes Paket als Konflikt, dessen
  paketspezifischer Entpack-Ordner bereits Dateien enthielt. Ein nur
  teilweise heruntergeladenes Paket hat dort aber seine EIGENEN fertigen
  Teile liegen (z.B. 15 von 26 fertig und entpackt) - das ist kein
  Konflikt, sondern Wiederaufnahme.
- Der Auto-Resume-Waechter war binaer: ein einziger gemeldeter Konflikt
  hat ALLE Pakete blockiert ("Auto-Resume uebersprungen: Start-Konflikte
  erkannt"). Zwei teilfertige Pakete haben so 30 Pakete eingefroren.

Fix:
- Diskriminator in getStartConflicts(): ein Paket mit eigenen fertigen
  ("completed") Items zaehlt nicht mehr als Konflikt - die Dateien im
  Entpack-Ordner sind seine eigene Ausgabe, kein Fremdbestand.
- Selektives Auto-Resume: start() akzeptiert excludePackageIds und laesst
  diese Pakete aus dem Lauf-Set (runPackageIds, auf das der Scheduler
  filtert). beginAutoResume() startet die sauberen Pakete und haelt nur
  echte Konflikte zurueck, statt alles zu blockieren; die zurueckgehaltenen
  Pakete werden im Log namentlich genannt.

Die beiden Aenderungen greifen ineinander: der Diskriminator garantiert,
dass ein als Konflikt gemeldetes Paket keine fertigen Teile hat, also auch
keine ausstehende Nachbearbeitung - das defensive runPackageIds.delete kann
daher keine Entpack-Arbeit haengen lassen.

Tests: Diskriminator (eigene Ausgabe nicht geflaggt / Fremdbestand
geflaggt) plus selektives Resume (ausgeschlossenes Paket bleibt aus dem
Lauf-Set, laeuft nicht an).
2026-06-21 23:17:56 +02:00
..
2026-03-04 17:31:20 +01:00
2026-03-09 04:59:00 +01:00