EPG stale-data cleanup logs deletion but performs none

Klassifikation

CONFIRMED BUG – High. Betroffen: Philips 43PUS7394/12, TPM191E_R.211.000.103.000, Android TV 12/API 31; Komponente /system/priv-app/channels/channels.apk, Klasse org.droidtv.channels.epg.bcepg.EpgProvider, Methode/Runnable EpgProvider$deleteStaleDataRunnable.run().

Benutzerwirkung

Die EPG-DB wuchs auf 1.742.053.376 Byte und verdrängte auf der nur rund 4,85-GiB-großen /data-Partition andere Appdaten. Philips warnte deshalb vor fast vollem Speicher. Der kontrollierte Neuaufbau gewann 1.701.400 KiB auf /data; die Belegung sank von 73 % auf 39 %. Nach realem Betrieb war die DB ~806.912 Byte groß und enthielt 1.041 aktuelle Schedule-Einträge. Guide, Now/Next, Sender, Favoriten, Aufnahmen, Timer und Reminder funktionierten; die Speicherwarnung war verschwunden.

Erwartetes und tatsächliches Verhalten

Erwartet: der nach Providerstart angekündigte Cleanup entfernt Schedule-Daten außerhalb eines definierten Retentionsfensters. Tatsächlich berechnet das Runnable lediglich now-1800 und optional einen weiteren Grenzwert, schreibt Logs und kehrt ohne delete, execSQL, ContentResolver.delete, applyBatch oder Aufruf der vorhandenen Zeit-Löschmethoden zurück.

Reproduktion

Provider starten und zwei Minuten warten.
Logs Posting stale data deletion..., Triggering stale data cleanup und Deleting stale data for time ... beobachten.
DB-Zeilenzahl und Größe davor/danach vergleichen.

Live am 25.08.2026 wiederholt: Logs um 21:09/21:11; keine DB-Änderung.

Technischer Beweis

Snapshot: 3.071.250 scheduletable-Zeilen, 100 % abgelaufen, 97,81 % älter als 30 Tage, 79,03 % älter als ein Jahr.
Tabelle ca. 1.436,98 MiB, vier Indizes ca. 222,06 MiB; freelist_count=0, auto_vacuum=FULL, integrity_check=ok.
Bytecode: epg-analysis.md und epg-reverse-agent.md.
Aggregat-/Reparaturbeleg: epg-repair.md.

Root Cause

Das Runnable ist unvollständig verdrahtet. Funktionsfähige Methoden EpgProgramPump.deleteChannelProgrambytime(long) und deleteScheduleProgramsByTime(long) existieren, werden von ihm aber nicht aufgerufen. Zusätzlich fehlt eine robuste periodische Retention. Phase 6 hat die exakte Methode in classes4.dex bei code_off=0xe298c bestätigt.

Workaround und dauerhafter Fix

Workaround: kontrollierter kompakter DB-Neuaufbau mit Erhalt von Index/Mapping. Dauerhaft: Clock in Millisekunden lesen, einmal in die tatsächlich gespeicherten Epoch-Sekunden konvertieren und scheduletable indexgestützt in höchstens 2.000-Zeilen-Transaktionen mit sieben Tagen Retention bereinigen. Der Offline- Test auf einer Kopie des großen Snapshots löschte 3.063.863 Zeilen, erhielt 7.387, bestand integrity_check und schrumpfte die FULL-auto-vacuum DB auf 4.059.136 Byte; der zweite Lauf änderte nichts. Details: IMPLEMENTATION.md und TEST-RESULTS.md.

Regression Tests / Kompatibilität

0/7/30-Tage-Daten, Lock, Stromausfall, Doppellauf, Senderwechsel und EPG-Refresh testen. Sender-, Favoriten- und Recording-Provider dürfen nicht mutiert werden.

Evidenz-Hashes

channels.apk SHA-256: 3A44BC648624F0CC9CD9FEB4CFC3FD33F41323597718E4FCCFC25FE35504D34F.

3.4 KiB Raw Blame History Unescape Escape