Files
philips-tv-speicher-voll/diagnostics/vendor-bugs/PHILIPS-TECHNICAL-REPORT-DE.md

3.9 KiB
Raw Blame History

Technischer Bericht – Speichererschöpfung auf Philips TPM191E

Kurzfassung

Gerät: Philips 43PUS7394/12, Firmware TPM191E_R.211.000.103.000, Android TV 12/API 31. Drei reproduzierbare Funktionsfehler und eine problematische Warnpolicy wurden bis zu den konkreten Binärmethoden isoliert. Der dominante EPG-Fehler ist durch eine kontrollierte Live-Reparatur und einen vollständigen Offline-Patchtest besonders stark belegt. Ein separater vertraulicher Security-Befund ist auf Anfrage verfügbar und nicht Bestandteil dieses Pakets.

Wirkung und erfolgreicher Live-Nachweis

Vor der Reparatur war EpgDatabase.db 1.742.053.376 Byte groß und enthielt 3.071.250 abgelaufene Schedule-Einträge. /data war zu 73 % belegt und Philips zeigte die Warnung „interner Speicher fast voll“.

Nach dem schema-identischen kompakten Replacement war die DB zunächst 159.744 Byte und nach echter EPG-Neuerfassung etwa 806.912 Byte groß. Sie enthielt 59 Now-, 48 Next- und 1.041 Schedule-Einträge vom 25.08.2026 19:00 bis 01.09.2026 02:50; integrity_check=ok. Freier /data-Platz stieg um 1.701.400 KiB (1,62258 GiB), Belegung sank auf 39 %. Live TV, Bild/Ton, Senderwechsel, Senderliste, Favoriten, Guide/Now-Next, Aufnahmen, Timer und Reminder wurden visuell bestätigt; die Warnung verschwand.

Befunde und dauerhafte Fixes

  1. BUG-001, EPG stale cleanup (High, CONFIRMED). EpgProvider$deleteStaleDataRunnable.run() in channels.apk!/classes4.dex (code_off=0xe298c) berechnet/loggt eine Grenze, führt aber keine Mutation aus. Der Phase-6-Fix konvertiert die Millisekunden-Clock einmal in die real gespeicherten Epoch-Sekunden und löscht scheduletable mit sieben Tagen Retention in indexgestützten 2.000er-Transaktionen. Auf einer Kopie der 1,62-GiB-DB wurden 3.063.863 Zeilen gelöscht, 7.387 erhalten, die DB auf 4.059.136 Byte reduziert und ein identischer zweiter Lauf bestätigt.
  2. BUG-002, GEL WorkManager (Medium, CONFIRMED). GatheringService.onStartCommand (code_off=0x50bf0) hängt jeden Intent unter GEL_WORK mit Policy 4 APPEND_OR_REPLACE an den bestehenden Blattgraphen. Das erklärt 229.453.824 Byte WorkDB und lange Enqueue-Latenz. KEEP allein würde unterschiedliche Intents verlieren. Empfohlen ist eine begrenzte persistente FIFO/Outbox, gezielte Koaleszierung, ein KEEP- Drain-Worker und Watchdog. Das Modell bestand 10.000+10.000 Ereignisse.
  3. BUG-003, USB free size zero (Medium, CONFIRMED). UsbVolumeListerImpl.getVolumes(String) in tvfw.jar (code_off=0x17b5e0) setzt Größen nur bei sys.mtk.dmremoteservice.ready=1 und publiziert sonst den Default Null. Der Fix validiert den KiB-DeviceManager-Wert und verwendet sonst StatFs am echten Mountpfad, um MiB zu liefern; Messfehler bleiben UNKNOWN. Die Offline-Matrix einschließlich >2 TiB bestand.
  4. DESIGN-001, Speicherwarnpolicy (Medium). TVStorageMonitorService$2.run() (code_off=0x2ad380) verwendet feste 500-MB/1-GiB-Grenzen und vermischt freien Platz mit eMMC-Lifetime. Der Ersatz nutzt Androids Volume-Schwellen, Debounce/Hysterese/Cooldown und komponentennahe Bereinigung; Flash-Health bekommt eine separate Meldung.

Auslieferungsgrenze

Channels, GEL und TPTvService verwenden android.uid.system und denselben Philips-Plattform-Signer. Ein /data/app-Update benötigt dessen privaten Schlüssel/akzeptierte Signierlinie. tvfw.jar ist eine registrierte Shared- Library und benötigt kohärenten DEX-/ART-/Client- und AVB-Systemimage-Build. Das Gerät ist locked/green. Deshalb liegen validierte Patchspezifikationen und Tests, aber bewusst keine zufällig signierten APKs oder unsicheren Images bei. Empfohlen wird zunächst ein Philips-signiertes Channels-Update, danach USB, GEL und Warnpolicy jeweils einzeln mit geprüftem Rollback.

Datenschutzbereinigte Einzelberichte und Hashes stehen in diesem Verzeichnis; Implementierung und Tests unter patches/.