[Release] serviceapp / exteplayer3 181 / FFmpeg 6.1.1 - neu kompiliert für VTi

Hinweis: Ich habe diesen Thread bewusst in der Bastelstube gepostet. Alle drei Pakete wurden von mir ausgiebig getestet, trotzdem können noch Fehler enthalten sein. Ich würde mich freuen, wenn der ein oder andere seine Plugins damit updatet und hier kurz Rückmeldung gibt. Der Post ist entsprechend dem Bastelstube-Bereich bewusst technischer formuliert als meine sonstigen Posts im Plugin-Bereich.

Moin,

ich habe mir eine Cross-Compile-Umgebung für serviceapp, exteplayer3 und FFmpeg für VTi aufgesetzt und möchte die Ergebnisse teilen.

serviceapp (mx3L/serviceapp)

Die in VTi enthaltene serviceapp basiert auf dem mx3L-Quellcode, ist aber schon etwas in die Jahre gekommen und wurde nie mit neueren Upstream-Fixes aktualisiert. Ich habe sie neu gebaut und dabei folgende Dinge integriert:

Aus dem mx3L-Repo nachgezogen (waren im VTi-Stand noch nicht drin):

• suburi-Support: HLS-Streams mit getrenntem Audio-Track (&suburi=...) werden korrekt als separates Argument an exteplayer3 übergeben
• trackInfo.m_pid: Audio-Track-IDs werden jetzt korrekt weitergereicht
• tap()-Stub: Fehlender Pure-Virtual-Stub ergänzt (verhindert Absturz bei neueren enigma2-Versionen)

Eigene Fixes:

• VTi ABI-Fix (evEOF): Beim Cross-Build gegen OpenPLi-Header wird evNewProgramInfo an Index 6 definiert, was evEOF auf Index 8 verschiebt. VTi erwartet jedoch Index 7 (wie die originale VTi-serviceapp, die nativ gegen VTi-Header gebaut wurde). Ohne diesen Fix bekommt das Plugin, das den Stream gestartet hat, kein Signal wenn der Stream abbricht oder nicht erreichbar ist, und kann entsprechend nicht reagieren. Behoben durch Entfernen von evNewProgramInfo aus dem Sysroot-Header
• VTi ABI-Fix (getInfoObject): Die öffentlich verfügbaren VTi-SDK-Header deklarieren eine virtuelle Methode einer internen Service-Info-Klasse mit einem Parameter weniger, als der tatsächlich kompilierte VTi-Kernel sie implementiert. Dadurch lag die komplette VTable dieser Klasse an einer falschen Speicherstelle, was beim Öffnen der Filmliste zu einem Absturz von Enigma2 führen konnte (u.a. beobachtet in Kombination mit AEL). Behoben durch Korrektur der Methodensignatur im Sysroot-Header
• ARMv7 Alignment-Trap: GCC 14 erzeugte LDRD-Instruktionen auf nicht 8-Byte-ausgerichteten Strukturen, was zu Kernel-Abstürzen führte. Behoben mit -mno-unaligned-access
• HLS-Audio-Track-Filter: Filtert beim HLS-Abruf den Default-Audiotrack heraus und übergibt ihn als separaten Substream. Nützlich für Streams mit getrenntem Audio/Video. Der Filter lässt sich unter Einstellungen → System → Medienwiedergabe deaktivieren, falls er bei bestimmten Streams Probleme verursacht.
• HLS-Startqualität & Default-Audio-Filter für exteplayer3: Wenn exteplayer3 eine HLS-Master-Playlist selbst parst (z.B. bei Live-Streams über entsprechende Plugins), lässt sich unter Einstellungen → System → Medienwiedergabe → exteplayer3 jetzt die Startqualität (Auto/Niedrigste/Höchste Bandbreite) sowie ein Filter für nur die als Standard markierte Audiospur pro Sprachgruppe einstellen. Bei Neuinstallationen ist standardmäßig die höchste Qualität mit nur der Standard-Audiospur voreingestellt, der ältere HLS-Explorer-Mechanismus (siehe oben) bleibt für exteplayer3 dafür standardmäßig aus, da er beim Öffnen kurz die Oberfläche blockiert. Die Auswahl passiert direkt im FFmpeg-HLS-Demuxer selbst, bevor unnötige Sub-Playlists überhaupt heruntergeladen werden. Markiert kein Track einer Sprachgruppe DEFAULT=YES, wird ersatzweise die erste verfügbare Spur genommen, damit nie komplett stumm wiedergegeben wird.
• EPG bei Streaming-Bouquet-Einträgen: Manche Bouquet-Einträge übernehmen bewusst SID/TSID/ONID/Namespace eines real empfangenen Kanals, um dessen EPG-Daten mitzunutzen. Dieser Referenztyp wurde beim EPG-Abgleich bisher ignoriert und stattdessen fest auf einen anderen internen Typ verdrahtet, wodurch nie EPG gefunden wurde. Jetzt wird zuerst der aus dem Bouquet-Eintrag übernommene Typ geprüft, erst wenn das nichts findet wird auf den alten Mechanismus zurückgefallen.
• EPG-Code abgesichert: Der EPG-Abgleich aus dem letzten Punkt konnte in seltenen Fällen abstürzen und hatte ein kleines Speicherleck (zwei ungenutzte EPG-Objekte pro Minute je laufendem Stream). Beides behoben, dabei zusätzlich abgesichert dass sich das Service-Objekt nicht während eines eigenen Callback-Aufrufs selbst zerstört.
• RFC-3986-URL-Fix: Absolute Pfade in M3U8-Playlists (beginnend mit /) wurden falsch aufgelöst. Behoben durch korrekte Extraktion des Origins der Master-URL
• Leerzeichen in Proxy-URLs: Manche Plugins bauen ihre Service-URL aus mehreren Teilen zusammen, die im Klartext auch Leerzeichen enthalten können (gefunden z.B. bei Zattoo über streamlinksrv, wo Zugangsdaten als Kommandozeilen-Parameter mit in die Proxy-URL wandern). Ein unkodiertes Leerzeichen zerschnitt dabei die HTTP-Anfragezeile beim Ziel-Server, was zu einem sofortigen Verbindungsfehler führte. Leerzeichen werden jetzt automatisch zu %20 kodiert
• Stabilitätsfixes: Use-after-free in eConsoleContainer (readyWrite), Speicher-Korruptionen durch C++14 sized deallocation und eTimer-Destruktor-Probleme behoben
• Adaptives, sauberes Prozess-Beenden: Beim Stoppen wird exteplayer3 zunächst per eigenem Kommando zum sauberen Beenden aufgefordert, worauf bis zu 950 ms adaptiv gewartet wird (der Vorgang bricht sofort ab, sobald der Prozess sich beendet hat). Klappt das nicht, wird per SIGINT nachgefragt, damit der Hardware-Decoder sauber stoppt (kein Nachlaufen von Bild/Ton), der Prozess-Status wird dabei per /proc/<pid>/stat live überwacht. Reagiert der Prozess auch darauf nicht innerhalb von 100 ms, wird er per SIGKILL zwangsbeendet (inkl. waitpid(), um Zombie-Prozesse zu vermeiden). In der Praxis dauert das Beenden meist nur wenige Millisekunden.
• Absturz beim Zurückschalten von einem Stream auf einen linearen Sender behoben: Unter bestimmten Timing-Bedingungen (u.a. bei aktivem FCC) konnte der Aufräum-Code beim Beenden der Wiedergabe doppelt und ineinander verschachtelt aufgerufen werden, was zu doppeltem Freigeben desselben Speichers und einem kompletten Box-Absturz führen konnte. Jetzt durch eine Sperre gegen doppelte Aufrufe abgesichert.
• Automated Picon Sync (neu, optional): Sender vom Typ 5001/5002 zeigten bisher kein Picon in der Kanalliste, selbst wenn für den zugrundeliegenden echten Sender längst ein passendes Picon vorhanden war. Ein neuer, standardmäßig deaktivierter Schalter unter Einstellungen → System → Medienwiedergabe legt dafür automatisch passende Symlinks an, sofern ein Picon des zugehörigen DVB-Senders gefunden wird.

Hinweis: Debug-Logging lässt sich über einen eigenen Schalter unter Einstellungen → System → Medienwiedergabe ein-/ausschalten (Standard: aus). Nur bei aktivem Schalter wird nach /tmp/serviceapp.log geschrieben, hilfreich bei der Fehlerdiagnose. Im Normalbetrieb besser deaktiviert lassen, da /tmp auf den Boxen eine RAM-Disk ist.

Hinweis für Plugin-Entwickler: Die originale VTi-serviceapp hatte ein blockierendes stop() (100 bis 500 ms), das competing playService()-Aufrufe zufällig serialisiert hat. Die neue serviceapp beendet Prozesse deutlich schneller. Plugins, die auf evEOF mit einem sofortigen playService()-Aufruf reagieren (z.B. Fallback auf einen Ersatzstream), sollten dabei zwei Dinge beachten: erstens ein Guard-Flag setzen, das verhindert dass evEOF rekursiv erneut ausgelöst wird, und zweitens den playService()-Aufruf um mindestens 500 ms verzögern (z.B. per reactor.callLater). Ohne diese Absicherung kann ein Kanalwechsel durch den Nutzer, der zeitgleich mit dem Fallback-Aufruf eintrifft, zu einem Deadlock des Decoders führen.

Für die Feature-Erkennung aus eigenen Plugins gibt es jetzt zwei Wege: Das serviceapp-Python-Modul exportiert __version__ (aktuell "vti005-hls1") für allgemeine Versionsprüfungen, und zusätzlich ein eigenes, leichtgewichtiges Modul serviceapp_caps mit expliziten Capability-Flags, ohne dass man Versionsstrings interpretieren muss:

from Plugins.SystemPlugins.ServiceApp import serviceapp_caps
if getattr(serviceapp_caps, "HAS_NATIVE_REFERER", False):
   # eigenen Referer-Workaround (z.B. lokalen Proxy) nicht mehr nötig,
   # serviceapp unterstützt Referer-Header jetzt direkt (url|Referer=...)
   ...

Aktuell verfügbare Flags: HAS_NATIVE_REFERER, HAS_HLS_AUDIO_FILTER, HAS_HLS_QUALITY_SELECT. Bei älteren serviceapp-Installationen ohne dieses Modul schlägt der Import fehl, entsprechend mit try/except ImportError absichern.

exteplayer3 (skyjet18/exteplayer3)

Oberhesses 1:181-IPK basiert auf den von varga mit der OpenPLi OE Core 4 Toolchain erstellten Pre-Built-Binaries, die skyjet18 in seinem Repository bereitstellt. Auf skyjet18's Master-Branch sind seitdem noch 3 weitere Commits geflossen, die bislang nicht in ein neues Paket verpackt wurden und vermutlich auch nicht mehr werden, da das Repo schon länger nicht mehr aktiv gepflegt wird. Ich habe den Quelltext direkt kompiliert und diese 3 Commits sind dabei mit drin:

• add support for MOV_TEXT subtitle format (März 2025)
• add X-DRM-Api-Level header when using with archivczsk (Juni 2025)
• fixed handling of iptv:// prefix (Juli 2025)

Das exteplayer3-Paket enthält außerdem die selbst kompilierten FFmpeg-6.1.1-Shared-Libs, die zusammen mit exteplayer3 in /usr/lib/exteplayer3_deps/ installiert werden.

Außerdem musste ich für den Build mit modernem GCC folgendes hinzufügen:

• -mno-unaligned-access (ARMv7 Alignment-Trap, gleiche Ursache wie bei serviceapp. Oberhesses OE-Toolchain nutzte einen älteren GCC, der davon nicht betroffen war)
• glibc_compat.c mit Stubs für posix_spawn etc. (Kompatibilität mit der glibc der Box (2.21))

Zwei weitere Fixes, die eigentlich im HLS-Codepfad meines FFmpeg-Builds liegen, aber sich für den Nutzer als exteplayer3-Problem zeigten:

• Netzwerk-Timeout überarbeitet: Manche Live-Streams brachen nach einem kurzen Lesefehler sofort ab, weil die bisherige Unterscheidung zwischen Live-Stream und normalem Dateiende auf einer unzuverlässigen Zeitdauer-Schätzung beruhte. Jetzt wird direkt geprüft, ob wirklich das Ende der Datei erreicht ist. Alles andere, zum Beispiel ein kurzer Netzwerk-Hänger, bekommt jetzt einheitlich 10 Sekunden Zeit sich zu erholen, bevor der Stream tatsächlich beendet wird.
• Absturz beim Vorspringen behoben: Bei VOD-Streams mit mehreren Bitraten-Varianten (z.B. Mediatheken-Inhalten) konnte ein Sprung per Zahlentaste exteplayer3 zum Absturz bringen. Ursache war eine Lücke im eigenen HLS-Codepfad für die automatische Qualitätsauswahl, der beim Springen nicht alle internen Datenstrukturen korrekt zurücksetzte. Behoben.

FFmpeg 6.1.1

Oberhesses FFmpeg wurde von varga mit der OpenPLi OE Core 4 Toolchain gebaut. Ich habe FFmpeg 6.1.1 frisch vom offiziellen ffmpeg.org-Tarball kompiliert. Version 6.1.x ist erforderlich, da exteplayer3 fest gegen libavcodec.so.60 gelinkt ist. Die Versionsnummer 60 in der Library entspricht der FFmpeg-Hauptversion 6.x. FFmpeg 7.x würde libavcodec.so.61 mitbringen, was der dynamische Linker als eine komplett andere Library behandelt. Exteplayer3 würde in dem Fall schlicht nicht starten, weil libavcodec.so.60 nicht gefunden wird. Ohne Neukompilierung von exteplayer3 ist ein Wechsel auf FFmpeg 7.x also nicht möglich. Da ich exteplayer3 selbst kompiliere, wäre es grundsätzlich denkbar, auch eine neuere FFmpeg-Version einzubinden. Falls es konkrete Gründe dafür gibt, bin ich gerne bereit das zu prüfen.

Compile-Parameter: --enable-gpl, --enable-nonfree, --enable-openssl, ARM-Optimierungen (--enable-neon, --enable-vfp, --enable-armv6, --enable-armv6t2).

Das ffmpeg-Binary ersetzt wie bei Oberhesses Paket das System-ffmpeg unter /usr/bin/ffmpeg. Die FFmpeg-Shared-Libs werden nicht durch das ffmpeg-Paket installiert, sondern durch das exteplayer3-Paket isoliert in /usr/lib/exteplayer3_deps/. System-Bibliotheken werden dadurch nicht überschrieben.

Beim direkten Öffnen lokaler Dateien (nicht über exteplayer3, sondern z.B. für Thumbnails/Hilfswerkzeuge) stürzte FFmpeg zunächst durchgehend ab. Aufgefallen ist das z.B. bei Zattoo, wo der streamlinksrv-Proxy intern mein ffmpeg zum Zusammenmuxen zweier Named-Pipe-HLS-Substreams (getrennte Video-/Audiospur) aufruft. Grund war ein fehlendes glibc-Symbol (fstat/stat) im Kompatibilitäts-Layer für die 2.21er glibc der Box, mittlerweile behoben.

Mein Cross-Build wurde bisher ohne Zlib-Unterstützung gebaut (die Bibliothek fehlte im Cross-Sysroot, das ist beim Cross-Compile keine harte Voraussetzung und fiel deshalb erst spät auf). Manche Live-Streams brachen dadurch nach 16 bis 60 Sekunden ab, wenn der CDN eine Playlist gelegentlich gzip-komprimiert auslieferte. Jetzt behoben, betrifft ARM und mips32el gleichermaßen.

MIPS-Unterstützung (mips32el)

Alle drei Pakete gibt es jetzt auch für mips32el-Boxen. Getestet habe ich auf einer VU+ Solo2 (Broadcom BCM7356/BMIPS5000, MIPS32r1), da mips32el-Nutzer serviceapp bisher nicht im VTi-Feed haben. Der Cross-Build für mips32el brachte ein paar eigene, architekturspezifische Fallstricke mit sich, die es auf ARM nicht gibt:

• SIGILL-Crash bei HTTPS/HLS-Streams: Der Compiler linkte für bestimmte Operationen fest vorkompilierten MIPS32r2-Code, den die MIPS32r1-CPU der Solo2 nicht versteht, was bei HTTPS/HLS-Streams zum Absturz führte. Behoben durch eigene Ersatzfunktionen für die betroffenen Compiler-Hilfsroutinen.
• Sporadischer Absturz bei der ersten Settings-Änderung (serviceapp): Page-Fault durch verzögerte BSS-Speicherallokation auf MIPS. Behoben durch Vorab-Initialisierung der globalen Options-Structs beim Laden des Moduls.
• Keine laufende Zeitanzeige bei VOD-Wiedergabe: Ein für ARM ermittelter Speicher-Offset für die Timer-Mutex-Initialisierung passte nicht zu MIPS und legte den internen Update-Timer lahm. Behoben durch Verzicht auf die manuelle Mutex-Initialisierung auf MIPS.

Getestet auf VU+ Solo2 mit VTi 15.0.04.

Installation

Wichtig: Bitte unbedingt per SSH installieren, nicht über die GUI! Eine Installation über den Plugin-Browser/Paketmanager in der Box-Oberfläche kann bei diesen Paketen unvollständig durchlaufen (z.B. weil die zyklische Abhängigkeit zwischen den drei Paketen dort nicht sauber aufgelöst wird) und dann zu Problemen führen, etwa dass in serviceapp gar keine Player zur Auswahl stehen. Die Installation per SSH/Telnet mit den unten stehenden Befehlen ist der einzig zuverlässige Weg.

Zunächst das passende ZIP herunterladen (ARM: serviceapp_exteplayer3_ffmpeg_armv7ahf_<datum>.zip, mips32el: serviceapp_exteplayer3_ffmpeg_mips32el_<datum>.zip), lokal entpacken und die enthaltenen IPK-Dateien per FTP in den Ordner /tmp auf der Box übertragen. Der Dateiname enthält das Build-Datum, daran erkennt ihr, ob es eine neuere Version gibt.

Install-Skript (empfohlen)

Im ZIP liegt zusätzlich install.sh. Einfach mit in denselben /tmp-Ordner legen und dort ausführen:

cd /tmp
sh install.sh

Das Skript übernimmt Deinstallation der alten Version (falls vorhanden), Speicherplatz-Check, Installation und Verifikation automatisch, egal ob es sich um ein Update, einen Wechsel von der Feed-Version, oder eine komplette Erstinstallation handelt. Wer lieber die Befehle selbst eintippt, kann das natürlich weiterhin manuell machen, siehe unten.

ARM

Die Pakete lassen sich sowohl über die originalen VTi-Feed-Pakete als auch über Oberhesses 1:181-Pakete problemlos installieren, ohne dass der VTi-Feed sie später wieder überschreibt. Auch eine Erstinstallation auf einer Box, auf der serviceapp noch nie installiert war, funktioniert damit.

Da mein ffmpeg-Paket eine strikte Abhängigkeit auf exteplayer3 (= 1:181+git3) hat und Oberhesses ffmpeg umgekehrt auf exteplayer3 (= 1:181) verweist, müssen exteplayer3 und ffmpeg immer gemeinsam in einem Befehl installiert werden. Per SSH oder Telnet dann alle drei auf einmal (Pfad /tmp passend zum obigen FTP-Ziel):

opkg install /tmp/exteplayer3_vti_1_181+git3_armv7ahf.ipk /tmp/ffmpeg_vti_1_181_armv7ahf.ipk /tmp/enigma2-plugin-systemplugins-serviceapp_*.ipk

mips32el

Auch hier exteplayer3 und ffmpeg immer gemeinsam installieren:

opkg install /tmp/exteplayer3_vti_1_181+git3_mips32el.ipk /tmp/ffmpeg_vti_1_181_mips32el.ipk /tmp/enigma2-plugin-systemplugins-serviceapp_*.ipk

serviceapp separat

Auf beiden Architekturen kann die serviceapp auch unabhängig installiert oder aktualisiert werden:

opkg install /tmp/enigma2-plugin-systemplugins-serviceapp_*.ipk

Danach Enigma2 neu starten.

Update auf einen neueren Build

Da sich die Versionsnummern zwischen meinen eigenen Builds nicht ändern, erkennt opkg install ein reines Überinstallieren nicht immer zuverlässig als Update. Am sichersten ist es daher, vor einem Update auf einen neueren Build (erkennbar am Datum im ZIP-Namen) zunächst die alten Pakete zu entfernen:

opkg remove enigma2-plugin-systemplugins-serviceapp exteplayer3 ffmpeg --force-depends

Enigma2 neu starten, dann die neuen IPKs wie oben installieren und Enigma2 nochmal neu starten.

Deinstallation

Zum vollständigen Entfernen aller drei Pakete (z.B. um zu den Feed-Versionen zurückzukehren):

opkg remove enigma2-plugin-systemplugins-serviceapp exteplayer3 ffmpeg --force-depends

Anschließend Enigma2 neu starten. Die Feed-Versionen lassen sich danach wie gewohnt über den Paketmanager neu installieren.

Versionierung

Die Versionsnummern sind so gewählt, dass opkg meine Pakete immer als neuer einstuft als die Feed-Versionen. Ein automatischer Downgrade durch opkg upgrade ist damit ausgeschlossen.

• serviceapp (gitAUTOINC+da9deae56b-r0.vti005+hls1 vs. Feed git95+da9deae-r0.vti005): opkg nutzt den dpkg-Versionsvergleich. Nach dem gemeinsamen Präfix git folgt bei mir A, im Feed endet das Segment dort bereits. Da Buchstaben höher gewichtet werden als ein Segment-Ende, gewinnt meine Version. Das Suffix +hls1 sichert zusätzlich ab.
• exteplayer3 (1:181+git3 vs. Feed 49+vti002-20171130-r00): Die führende Epoche 1: schlägt jede Version ohne Epoche (die implizit Epoche 0: hat), unabhängig vom Rest der Versionsnummer.
• ffmpeg (1:181 vs. Feed VTi001.3.4.1-r14): Gleiches Prinzip, Epoche 1: gewinnt immer.

Quellcode & Lizenz

Die verwendeten Quellen (mx3L/serviceapp, skyjet18/exteplayer3, FFmpeg) stehen größtenteils unter der GPL-2.0-Lizenz. Die eigenen Änderungen stehen entsprechend unter derselben Lizenz auf GitHub: https://github.com/boingbasti/e2-serviceapp-vti

Getestet auf VU+ Uno 4K SE und VU+ Solo2 mit VTi 15.0.04. Feedback willkommen.

Da ich eine eigene Cross-Compile-Umgebung für alle drei Pakete habe, können gerne Feature-Wünsche für serviceapp, exteplayer3 oder FFmpeg geäußert werden. Ich prüfe dann ob und wie sich das umsetzen lässt.

Die Anleitung ist korrekt, wenn entweder das ffmpeg vom Feed oder das ffmpeg-Paket von Oberhesse auf der Box installiert ist. Der Grund warum keine vorherige Deinstallation nötig ist: Meine Pakete haben eine höhere Versionsnummer als die Feed- und Oberhesse-Versionen, daher erkennt opkg sie als Upgrade und installiert sie direkt drüber. Bei eigenen Paketen kann ich das, ohne das Paket zu kennen, nicht pauschal beantworten.

Was hast du denn eigentlich an exteplayer geändert und warum hast du ffmpeg aktualisiert? Klingt auf jeden Fall interessant, ich bin bewusst bei 6.1.1 geblieben, weil ich selbst keine Gründe dafür gesehen habe.

Leider nein, die Pakete sind für ARMv7 kompiliert und laufen nicht auf einer mipsel-Box. Eine MIPS-Variante würde eine komplett neue Cross-Compile-Umgebung erfordern. Das ist im Moment nicht geplant, aber ich schließe es für die Zukunft nicht aus.

Moin!

Ich habe mich doch dazu entschieden eine mips32el-Version zu bauen, da ich festgestellt habe, dass die Build-Umgebung von ARM auch für mips32el schon fast funktionierte. Dabei sind auch ein paar Änderungen in die ARM-Version eingeflossen:

• Beim Stoppen wird jetzt zuerst per SIGINT zum Beenden aufgefordert (sauberer Stopp ohne Nachlaufen von Bild/Ton), erst wenn das nicht klappt, folgt SIGKILL.
• serviceapp exportiert jetzt __version__ sowie ein kleines serviceapp_caps-Modul mit Feature-Flags (aktuell HAS_NATIVE_REFERER, HAS_HLS_AUDIO_FILTER), damit andere Plugins zur Laufzeit erkennen können, was die installierte serviceapp-Version kann.

Die MIPS-Version lässt sich genauso installieren wie die ARM-Version. Ich habe den ersten Post entsprechend angepasst.

Ich konnte übrigens nirgends eine serviceapp für mips32el finden, weder im VTi-Feed noch hier im Forum. Gab es die überhaupt schon mal? Falls ich da was übersehen habe, sagt gerne Bescheid, aber spätestens ab jetzt gibt es sie auf jeden Fall.

Wichtig für alle, die die Pakete schon vorher installiert hatten

Die Versionsnummern bleiben unverändert, ein einfaches Überinstallieren reicht daher nicht zuverlässig aus. Wer die Pakete aus dem ersten Post schon installiert hatte, sollte sie erst komplett entfernen, bevor die aktuellen installiert werden:

opkg remove enigma2-plugin-systemplugins-serviceapp exteplayer3 ffmpeg --force-depends

Enigma2 neu starten, dann die aktuellen IPKs installieren (siehe erster Post) und Enigma2 nochmal neu starten.

Da wir hier weiterhin in der Bastelstube sind, bleibt das Debug-Logging vorerst aktiv (Logs unter /tmp/serviceapp.log, hilfreich falls doch mal was klemmt). Sobald das echte Release ansteht, deaktiviere ich das Logging und veröffentliche alles im Plugin-Bereich.