Ich habe mir ein Wochenende Zeit genommen, um einem Problem mit meiner Kodi-TVHeadend-Installation auf die Schliche zu kommen, das mich schon eine Weile beschäftigt. &tldr; Ich bin noch nicht am Ende meiner Reise angekommen...
Ich nutze Kodi bereits seit einigen Jahren als Media-Center für zu Hause. Etwas später schaffte ich mir einen FRITZ!WLAN Repeater DVB-C an, um die im Wohnzimmer empfangenen Fernsehprogramme im ganzen Haus an entsprechenden IT-Endgeräten (Tablet, Laptop,...) verfolgen zu können. Dazu nutzte ich eines der Features des Fritz-Gerätes: Es kann zwei per DVB-C empfangene Transportströme als IPTV-Ströme weiterleiten. Diese kann man dann zum Beispiel mittels VLC ansehen.
Kurz danach kam mir der Gedanke, TVHeadend in dieses Setup zu integrieren. Damit hätte ich dann die Gelegenheit, über die Oberfläche von Kodi einen komfortablen digitalen Videorekorder zum Gesamtsystem hinzuzufügen. Dieses Setup funktioniert im Großen und Ganzen befriedigend, allerdings nervt mich seit langer Zeit schon die Tatsache, dass das EPG nicht zuverlässig aus den einzelnen IP-Strömen ausgelesen wird. Ich schob das auf die Version von TVHeadend, die bei mir im Einsatz ist und fasste den Entschluss, nicht nur eine neue Version auszuprobieren, sondern auch zu versuchen, den digitalen Videorekorder auf weniger stromhungrige Hardware umzuziehen - ich wählte dabei das, was im inneren, inneren Kreis bei uns das Trump-Board genannt wird: ein ARM-Board mit A53 64-Bit Prozessor, 1 GB 1866 MHz LPDDR3 RAM und zum RasPi identischer Bauform.
Da zeigte sich dann, dass es gut war, sich an diesem besagten Wochenende nicht noch etwas anderes vorzunehmen: Keine der Anleitungen im Netz zum Installieren der Anwendung aus den Quellen funktionierte sofort und ohne Änderungen. Installierbare Pakete gab (und gibt) es nicht.
Letztlich kam ich mit den folgenden Anweisungen zu einem selbstgebauten Debian-Installationspaket, das sich mittels dpkg auch installieren ließ - damit konnten meine Tests beginnen:
apt install libavahi-client-dev zlib1g-dev libavcodec-dev libavutil-dev \
libavformat-dev libswscale-dev libavresample-dev python3 python gettext \
cmake libiconv-hook-dev dvb-apps liburiparser-dev debhelper \
libcurl4-gnutls-dev libdvbcsa-dev python-requests python3-requests \
libpcre2-dev libpcre3-dev libavahi-client3 libavahi-common3 libdvbcsa1 \
libssl1.0.0 liburiparser1
git clone https://github.com/tvheadend/tvheadend.git
cd tvheadend/
./configure --build=aarch64-unknown-linux-gnu
./Autobuild.sh
dpkg -i ../tvheadend_4.3-2050~g52c3ed3ef_arm64.deb
Die Angabe der Architektur beim Aufruf von ./configure war wegen veralteter Versionen von config.guess und config.sub notwendig geworden - dazu später mehr...
Diese Version ließ sich wie bereits gesagt starten und nutzen - allerdings stellte sich ein interessantes Phänomen ein, das ich so noch nie beobachtet hatte: Wenn - gleich wie - Aufnahmen gestartet wurden, wurden nur ungefähr eine Minute Material aufgezeichnet. Es kam weder zu Fehlermeldungen im Log, noch in der Weboberfläche oder in Kodi: Überall sah man, dass die Aufnahme wie gewünscht arbeitete, allerdings hörte das System einfach auf, in die Datei zu schreiben. Interessanterweise lag das nicht an der Bitreate des jeweiligen Streams: SD- wie auch HD-Kanalaufnahmen waren samt und sonders etwas über eine Minute lang und endeten dort.
Ich schom das zunächst erst einmal auf die ARM-Hardware und setzte eine neue QEMU-VM mit Ubuntu 22.04 LTS auf um das System dort zu übersetzen und zu testen und war überrascht, festzustellen, dass es sich dort exakt so verhielt. Meine Schlussfolgerung: irgendein Commit in das Projekt hat die Aufnahme von IPTV-Streams kaputt gemacht.
Ich versuchte, die letzte offizielle Version auszuchecken und zu übersetzen. Diese ist drei Jahre alt und ich wurde - auf beiden Architekturen - mit so vielen Fehlern überschüttet, dass ich den Versuch schnell aufgab, diese zum Laufen bringen zu wollen. Stattdessen wählte ich eine anstrengendere Variante: Ich durchsuchte das Commit-Log des Projektes daraufhin, ob ich darin einen Hinweis finden könnte, wann das Aufnehmen von IPTV-Strömen kaputtgemacht worden sein könnte. Als ich dabei nichts fand, biss ich in den sauren Apfel und arbeitete mich in groben Halb-Jahres-Schritten durch die Versionen in der Zeit rückwärts, baute die jeweilige Version und testete.
Durch dieses Vorgehen fand ich tatsächlich einen Commit, bei dem Die aufnahme funktionierte: Diesen Commit kann man mittels
git checkout f77c77d11
holen.
Anschließend versuchte ich, diesen Commit auch auf dem eigentlichen Zielsystem zu bauen. Das schlug zunächst wieder fehl, weil das System nicht nur die eigenen Sourcen übersetzt, sondern diverse andere Projekte im Quelltext herunterlädt und selbst übersetzt - darunter ffmpeg und libtheora (unter anderen). Da steckte auch das Problem: Das Bauen der Version von libtheora schlug fehl, da das Projekt eine hoffnungslos veraltete Version von config.guess und config.sub mitbrachte, das die Architektur des ARM-Boards nicht erkannte. Daher ersetzte ich beide Dateien durch http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD bzw. http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD - damit funktionierte die Erstellung des Debian-Installationspakets dann auch und ich konnte voller Freude und Stolz einen stromsparenden (5 Watt) ARM-basierten digitalen Videorekorder in Betrieb nehmen.
Das eingangs genannte eigentliche Problem ist leider immer noch nicht gelöst: Es erfolgt keine zuverlässige Aktualisierung des EPG aus den jeweiligen Transportströmen. Dieses Problem werde ich weiter untersuchen und falls ich da zu einer Lösung komme, den exakten Commit suchen, der die Aufnahme kaputtmacht und dann auch ein entsprechendes Ticket und einen zugehörigen Pull-Request erstellen.
11.02.2023
Ich hatte vor kurzem über meine Versuche berichtet, TVHeadend auf einem (stromsparenderern) ARM-Board zum Laufen zu bringen. Das habe ich aus diversen Gründen aufgegeben, die ich hier darlegen möchte...
19.01.2023
Im Zuge meiner neuerlichen Experimente mit dem von mir liebevoll so genannten Trump-Board wurde ich mir wieder eines schmerzlichen Defizits dieser (und ähnlicher) Hardware bewusst: der mangelnden Geschwindigkeit beim Kopieren großer Dateien über das Netzwerk.
Testdatengeneratoren als Microservices mit Docker
02.11.2019
Ich habe die verschiedenen Testdatengeneratoren mittels Microservices über HTTP zugänglich gemacht, um sie unabhängig von der verwendeten Programmiersprache und/ oder Version (Java 11) verwenden zu können.
Weiterlesen...Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Git(lab|hub) Go GUI Gui Hardware Java Jupyter Komponenten Links Linux Markdown Markup Music Numerik PKI-X.509-CA Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Nachdem ich neulich auf einen sehr interessanten Link gestoßen war, habe ich mich dafür interessiert, ob es möglich wäre - und falls ja: wie einfach - GIF-Animationen aus Java heraus zu erzeugen - und zwar mit Bordmitelln und ohne Zuhilfenahme externer Biblioheken
Weiterlesen...Nach der letzten losen Zusammenstellung (für mich) interessanter Links aus den Tiefen des Internet von 2024 folgt hier gleich die nächste:
Weiterlesen...Nachdem es nun bereits seit einiger Zeit ein wenig stiller um meine diversen Generatoren für Testdaten geworden ist, habe ich über den Feiertag in Thüringen einen neuen begonnen.
Weiterlesen...Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.