TVHeadend build auf ARM

vorhergehende Artikel in: Linux C und C++ Rants
26.12.2022

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.

Artikel, die hierher verlinken

Das Ende von TVHeadend auf ARM (bei mir)

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...

Beschleunigung von scp trotz verhältnismäßig schwacher Hardware

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.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • AtomicInteger vs. Integer

    24.03.2019

    Ich habe am Wochenende wieder einmal mit Java-Benchmarks experimentiert

    Weiterlesen...

Neueste Artikel

  • Konstruktive Geometrie mit dem Computer

    Ich habe in einem vorhergehenden Artikel beschrieben, dass ich eine weitere neue Graphik-Primitive erstellt habe. Dabei musste ich mir meine verschütteten Trigonometrie-Kenntnisse wieder vor Augen führen - mit Bleistift und Papier. Das müsste doch auch anders gehen dachte ich mir und begann...

    Weiterlesen...
  • GitHub-Projekte

    Mal abgesehen von den anderen Links, die ich in unregelmäßigen Intervallen hier poste kommt heute ein Schwung (aus meiner Sicht) interessanter/skurriler Projekte auf GitHub:

    Weiterlesen...
  • Mehrere Datenbanken und Postgis-Erweiterung in Docker

    Ich hatte ja schon beschrieben, dass ich mich in diesem Jahr wieder intensiver um mein Geoinformationssystem EBMap4D kümmern möchte. Dazu habe ich jetzt einige infrastrukturelle Vorbereitungen getroffen...

    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.