EPG-Datenbank-Forensik

Kurzfazit

EpgDatabase.db ist 1,62 GiB groß, weil Philips seit Februar 2023 nahezu alle Schedule-Ereignisse akkumuliert hat. Die Datei enthält 3.071.250 reale scheduletable-Zeilen. Zum Snapshotzeitpunkt waren 100 % abgelaufen; 97,81 % waren älter als 30 Tage und 79,03 % älter als ein Jahr. Es handelt sich nicht um eine große Freelist und nur zu 0,91 % um exakte Dubletten.

Das bestätigt die bereits statisch rekonstruierte Ursache: Der vorgesehene Philips-Stale-Cleanup wird gestartet und protokolliert einen Grenzwert, führt im Runnable aber keine SQLite-/Provider-Löschung aus. CONFIRMED / VALIDATED LIVE plus Offline-DB-Beweis.

Konsistenter Snapshot

Original: /data/user/0/org.droidtv.channels/databases/EpgDatabase.db

Prozess: org.droidtv.channels, PID 7267/31859 je Prozessneustart;
Connection-Pool: eine Primary-Connection, beim Precheck read-only und nicht acquired; Rollback-Journalmodus, kein WAL/SHM;
Journal vor und nach akzeptierter Kopie: 0 Byte;
Originalgröße/inode/mtime während Kopie und beider Hashläufe unverändert;
Original, adopted-USB-Kopie und PC-Kopie: 71403743206d5082aae56c4a947f3429f5c3d54b908c4abe2eb0ca66e06694ba.

Ein erster Versuch wurde wegen gleichzeitig geändertem Original und Hash-Mismatch verworfen. Der zweite Lauf erfüllte alle Gates. Die Original-DB wurde nie geschrieben.

SQLite-Metadaten

PRAGMA/Check	Ergebnis
`page_size`	4.096 B
`page_count`	425.306
Dateigröße	1.742.053.376 B = 1.661,35 MiB
`freelist_count`	0
`auto_vacuum`	1 / FULL
`journal_mode`	`delete`
`user_version`	6
`schema_version`	23
`quick_check`	`ok`
`integrity_check`	`ok`

Die frühere offene Freelist-/Auto-Vacuum-Frage ist damit geschlossen. Die Datei ist intakt und enthält keine freie Seitenreserve. FULL-Auto-Vacuum ist im persistenten DB-Header direkt bewiesen.

Zeilen und Seiten

Objekt	Typ	Seiten	MiB	Zeilen
`scheduletable`	Tabelle	367.868	1.436,98	3.071.250
`indexschedendtime`	Index	16.827	65,73	–
`indexschedstarttime`	Index	16.818	65,69	–
`indexschedeventid`	Index	13.183	51,50	–
`indexschedpresetid`	Index	10.019	39,14	–
alle übrigen Objekte zusammen	Tabelle/Index	ca. 76	<0,3	919 + Metadaten

Schedule-Tabelle plus vier Indizes belegen rund 1.659,04 MiB und damit praktisch die ganze 1.661,35-MiB-Datei. Die etwa 2,03-MiB-Differenz besteht vorwiegend aus FULL-Auto-Vacuum-Pointer-Map-/sonstigen Nicht-dbstat-Seiten.

Die Schedule-Tabellen-Payload beträgt 1.079,65 MiB. Allein shortinfo enthält 961.046.485 Zeichen (ca. 916,5 Mi-Zeichen), eventname 67.158.355. extendedinfo und guidanceinfo sind in diesem Bestand leer. Teilweise unbenutzter Platz innerhalb aktiver B-Tree-Seiten ist keine Freelist.

Altlasten

Cutoff war der Original-mtime-Zeitpunkt 1787680625 (2026-08-25).

Altersklasse nach `endtime`	Zeilen	Anteil
aktuell/zukünftig	0	0 %
abgelaufen 0–1 Tag	1	<0,001 %
1–7 Tage	8.887	0,289 %
7–30 Tage	58.280	1,898 %
30–365 Tage	576.718	18,778 %
älter als 365 Tage	2.427.353	79,035 %
Zeitwert 0	11	<0,001 %

Nichtnull-Daten reichen von 2023-02-08 bis 2026-08-24. Es gibt 196 Presets; die größten halten je 30.000–63.888 historische Events. Alle Schedule-Presets existieren in indextable: 0 orphan rows.

Logische Schlüssel-Dubletten (presetid,eventid,starttime,endtime) erklären 28.001 überzählige Zeilen; exakte Vollzeilen-Dubletten 27.974, jeweils nur 0,91 %. Der dominante Fehler ist daher fehlende Retention, nicht Duplikation.

Abgleich mit dem Cleanup-Code

Live um 19:57/19:59:

Posting stale data deletion after 2 mins in onCreate;
deleteStaleDataRunnable: Triggering stale data cleanup;
Deleting stale data for time 1787680743361.

Der geloggte Wert ist Millisekunden-nahe, während DB-Zeiten Sekunden sind. Entscheidender ist der statische Bytecodebeweis: Das Runnable enthält keinen SQLiteDatabase.delete/execSQL, ContentResolver.delete/applyBatch oder Aufruf einer echten Löschmethode. Zwei Minuten später war die 3,07-Mio.-Zeilen- Historie weiterhin vollständig vorhanden. Das ist die direkte Ursache des langjährigen Wachstums.

Was wäre rückgewinnbar?

Echte Live-Nutzlast in scheduletable: zum Cutoff 0 zukünftige/aktuelle Zeilen; Now/Next sind separat klein.
Historische Altlast: praktisch die gesamten 1.437 MiB Tabelle plus 222 MiB Schedule-Indizes.
Gelöscht, aber nicht ans Dateisystem zurückgegeben: 0 Freelist-Seiten.
Fragmentierung/unused auf aktiven Seiten: vorhanden, aber sekundär.

Eine tatsächliche Bereinigung wird hier bewusst nicht ausgeführt. Bei FULL-Auto-Vacuum kann ein millionenfaches DELETE erhebliche Page-Moves, Journaling und eMMC-Schreiblast auslösen. Ein app-kontrollierter Neuaufbau kann konzeptionell write-ärmer sein, muss aber Sender-/Favoriten-/Aufnahme-/Timer- Abhängigkeiten und den exakten Philips-Workflow berücksichtigen.

5.1 KiB Raw Blame History Unescape Escape