philips-tv-speicher-voll/diagnostics/phase5/epg-repair-options.md

Phase 5B – Vergleich der EPG-Reparaturstrategien

Methode	eMMC-Schreiblast / Peak-Space	Datenrisiko	Rollback	Gewinn / EPG-Neuladen	Urteil
A: DELETE von 3.071.250 Zeilen	sehr hoch: Indexupdates, FULL-AutoVacuum-Page-Moves und DELETE-Journal; Peak potenziell hunderte MiB bis problematisch nahe aktuellem Freiraum	geringe semantische Selektivität bei korrektem Cutoff, aber lange Transaktion/Lock/Stromausfallrisiko	Originalsnapshot vorhanden, Live-Rollback teuer	etwa 1,6 GiB; App behält Schema	nicht empfohlen
B: DROP/CREATE scheduletable + Indizes	deutlich weniger SQL-Operationen als A, aber DDL/Journaling und FULL-AutoVacuum auf der 1,6-GiB-Datei; App besitzt keinen validierten Live-DDL-Endpunkt	nur Schedule, aber Schema-/Connectioncache- und offener-DB-Risiko	Snapshot; eigenes DDL fehleranfällig	etwa 1,6 GiB; Nachladen wahrscheinlich	möglich, unnötig komplex
C: kompakte Ersatz-DB	intern nur ca. 160 KiB neue Datei plus atomarer Rename; kein zweiter 1,6-GiB-Stand auf /data	behält Senderindex/Mapping exakt, leert nur EPG-Payload; Owner/Label/Open-Connection müssen stimmen	hashgeprüfter PC- und USB-Snapshot; atomarer Rücktausch möglich	erwartet 1.701.068 KiB; leerer Now/Next/Schedule erzwingt frische Befüllung	eindeutige Empfehlung
D: Philips rebuilddbonnewchannellist	sehr hoch: intern mehrere SQLiteDatabase.delete über Millionen Zeilen plus FULL-AutoVacuum	kanonische Sender/Favoriten nicht direkt gelöscht, aber Mapping komplett rekonstruiert; Eventverknüpfungsrisiko	Snapshot, aber laufender Appworkflow schwerer zu kontrollieren	wahrscheinlich ähnlich, jedoch unnötige Writes	offiziell app-kontrolliert, aber für verschlissene eMMC nicht optimal

Empfehlung

Methode C ist bei diesem konkreten Datenbestand schreibärmster, rückrollbarster und semantisch konservativster. Die Kandidaten-DB wird aus dem Originalschema erstellt, übernimmt ausschließlich:

• android_metadata;
• channelmapversiontable;
• indextable inklusive Sender-/Favoritenspiegel;
• mappingtable.

Now/Next/Schedule/FVP/FastIP bleiben leer. Das ist konservativer als ein vollständiger Philips-Rebuild, weil die bestehenden Sender- und Preset-Spiegelzeilen unverändert bleiben.

Lokal validierter Kandidat

• Größe: 159.744 B / 39 Seiten;
• SHA-256: 1ae978c7ca9333c6a0528ad535a732f116deb7213321e9d0bd9c0d377a25aa5b;
• exakt gleiche sqlite_master-Objekte und SQL-Definitionen;
• page_size=4096, auto_vacuum=FULL, journal_mode=delete, user_version=6;
• alle vier übernommenen Tabellen besitzen identische kanonische Zeilenhashes;
• quick_check=ok, integrity_check=ok, foreign_key_check=[];
• alle Foreign-Key-Listen leer; keine Trigger/Views.

Erwarteter unmittelbarer Dateigewinn: 1.741.893.632 B = 1.701.068 KiB = 1.661,20 MiB = 1,6223 GiB.