Dr. Jochen Manns » Allgemein

Archiv der Kategorie: Software

Hauppauge PCTV 461e unter Fedora 43

Von | | , , ,
Einen Kommentar hinterlassen

Da ich immer ab und an noch ein bisschen mit TV Karten herumspiele und meine beiden TechnoTrend Geräte inzwischen aus Altersschwäche den Geist aufgegeben haben, habe ich mit den im Titel bezeichnete Stick besorgt. Laut allen Informationen auch unter Fedora nutzbar – soweit zur Theorie.

Ich habe dann wohl ein neueres Modell bekommen, das sich mit der USB Kennung 2013:0462 meldet und für das es noch keine Unterstützung im Linux Kernel (6.18) gibt – tatsächlich auch nicht in den neueren. Hauppauge selbst verweist auf ein Open Source Paket, das es aber nur für das aktuelle Ubuntu LTS und den Kernel 6.8 gibt – dazu auch eine entsprechende Firmware.

Da es mich schon etwas Nerven gekostet hat das unter Fedora zumindest in einem Entwicklungsstand ans Laufen zu bekommen will ich hier kurz meine Erfahrungen vorstellen – auch eine längere hitzige Diskussion mit ChatGPT hat zwar ein paar mal in die richtige Richtung gezeigt mich aber auch des öfteren mal gegen die Wand laufen lassen. Basis ist der Patch für 6.8, wobei ich allerdings nur die für die 461e relevanten Teile (30.Montage.3103c.demod) extrahiert habe – mit ein paar kleinen Tweaks und einem zusätzlichen Fix für das DVB-S Tuning. Ein bisschen Code von einer Dual-Tuner Karte ist noch drin, aber das war mir egal, zumindest läuft die Karte nun erst einmal. Meinen Patch habe ich mal hier in den Blog geladen – natürlich zusammen mit dem was jetzt kommt ganz ohne Gewähr.

Ich habe das nur für mein aktuelles Fedora gemacht, wohl wissend, dass man die Module neu erstellen muss, wenn es ein Update gibt – vielleicht landet der Hauppauge Patch ja irgendwann mal im Mainstream Kernel, wer weiß. Mein uname -r meldet 6.18.3-200.fc43.x86_64 und das wird auch im folgenden Beispiel so verwendet.

Wichtig ist vor allem, dass man die richtigen Quellen verwendet – auf den ganzen Entwicklerkram, den man installieren muss, gehe ich hier nicht ein, vieles war auf meiner Entwicklermaschine eh schon drauf. Nach einigen Sackgassen fängt das so an:

Als Arbeitsverzeichnis verwende ich den Vorschlag vom rpmdev:

  • rpmdev-setuptree (einmalig beim ersten Mal)
  • cd ~/rpmbuild/SRPMS

Die passenden Quellen werden heruntergeladen und entpackt:

  • dnf download –source kernel-6.18.3-200.fc43.x86_64
  • rpm -Uvh kernel-6.18.3-200.fc43.src.rpm

Die Quellen werden passend zu meinem System konfiguriert:

  • cd ../SPECS
  • rpmbuild -bp kernel.spec

Der Rest findet nun in dem Verzeichnis statt in das die Quellen entpackt wurden:

  • cd ../BUILD/kernel-6.18.3-build/kernel-6.18.3/linux-6.18.3-200.fc43.x86_64

Darin wird die Konfiguration des laufenden Kernels abgelegt:

  • cp /boot/config-$(uname -r) .config
  • make olddefconfig

fedora ist etwas pingelig was die Versionskennzeichung der Module angeht. Sollte wie im Beispiel ein Zusatz an der Version (6.18.3) vorhanden sein, so muss dieser in die Datei .config eingetragen werden. Dazu wird CONFIG_LOCALVERSION auf „-200.fc43.x86_64“ gesetzt.

Danach kann man meinen minimalisierten Patch anwenden (es gibt sechs Warnungen, da war ich wohl bezüglich Leerzeichen etwas schlampig) und bauen:

  • git apply fedora43_6.17.12-300.patch
  • make prepare -j$(nproc)
  • make -C /lib/modules/$(uname -r)/build M=$PWD/drivers/media/usb/em28xx modules srctree=$PWD -j$(nproc)
  • make -C /lib/modules/$(uname -r)/build M=$PWD/drivers/media/dvb-frontends modules srctree=$PWD -j$(nproc)

Relevant für den Zugriff auf das Gerät sind nur die folgenden drei Module:

  • drivers/media/dvb-frontends/m88ds3103.ko
  • drivers/media/usb/em28xx/em28xx.ko
  • drivers/media/usb/em28xx/em28xx-dvb.ko

Beispiel mit VLC – Kaffeine und meine eigene Software tun es aber auch.

vlc dvb-s2://frequency=11494000:polarization=H:srate=22000000:modulation=8PSK:fec=2/3

Mit dem gegenüber der ursprünglichen Version zusätzlichen Fix gehen das dann auch für DVB-S Transponder.

vlc dvb-s://frequency=12188000:polarization=H:srate=27500000:fec=3/4

Viel Glück beim Selbstversuch und im Sinne des letzten Bildes schon mal ein frohes Weihnachtsfest

Jochen

Kleiner Zusatz: tatsächlich funktioniert die DiSEqC 1.0 Ansteuerung nicht, ich vermute aber, dass ich da irgendwas übersehen habe – bezüglich des DVB-S Fixes berichtet ein Benutzer, dass er 3 DiSEqC Positionen erfolgreich angesteuert hat. Was allerdings geht ist DiSEqC Burst zum Umschalten zwischen zwei Positionen und mehr habe ich eh nicht – also für mich ist der Stick nun voll nutzbar.

Weitere Information: mit Kernel 6.18 musste ich die Anleitung noch mal überarbeiten, ich habe keinen Retest der veränderten Beschreibung für 6.17 gemacht – viel Glück für den, der es versucht. Den Patch selbst konnte ich unverändert übernehmen.

C# „switch expression“ – manchmal muss man aufpassen

Von | | ,
Einen Kommentar hinterlassen

Wie bei vielen Dingen ist es im Nachhinein klar warum etwas Komisches passiert aber im ersten Moment überrascht es dann doch. Hier ein kleiner Aufreger bei der eigentlich sehr praktischen „switch expression“ von C#.

Angefangen hat es mit einer Extension Methode auf JsonNode, die im direkten Spielen mit der JSON Deserialisierung für einfache Datentypen direkt die nativen Werte liefern soll.

public static object? ToJsonScalar(this JsonNode node)
{
    switch (node.GetValueKind())
    {
        case JsonValueKind.True: return true;
        case JsonValueKind.False: return false;
        case JsonValueKind.Null: return null;
        case JsonValueKind.String: return node.GetValue<string>();
        case JsonValueKind.Number: return node.GetValue<double>();
        default: return node;
    }
}

Benutzt wird das dann wie folgt und das liefert auch die richtige Ausgabe (System.Double):

var num = JsonNode.Parse("3.14")!;

Console.WriteLine(num.ToJsonScalar()?.GetType());

Die Überraschung gab es dann bei der manuellen Umstellung auf eine „switch expression“ – die automatische Konvertierung macht es besser, aber hier geht es ja ums Prinzip:

public static object? ToJsonScalar(this JsonNode node)
    => node.GetValueKind() switch
    {
        JsonValueKind.True => true,
        JsonValueKind.False => false,
        JsonValueKind.Null => null,
        JsonValueKind.String => node.GetValue<string>(),
        JsonValueKind.Number => node.GetValue<double>(),
        _ => node,
    };

Sieht gleich aus? Ist es aber nicht, die Ausgabe lautet nun:

System.Text.Json.Nodes.JsonValuePrimitive`1[System.Double]

Was ist passiert? Ähnlich wie ein ternärer Ausdruck (?:) muss die „switch expression“ einen einzigen Datentyp melden. Der Compiler entscheidet sich hier für den Default (_) und das ist ein JsonNode. Da alle anderen Datentypen einen impliziten Casting Operator haben, wird im Beispiel aus der Zahl direkt wieder ein JsonNode – genauer halt ein JsonValuePrimitive<double>.

Die automatische Konvertierung des switch Statements erzeugt einen (object) Cast bei JsonValueKind.Number, ich habe die Variante auf dem Default bevorzugt:

public static object? ToJsonScalar(this JsonNode node)
    => node.GetValueKind() switch
    {
        JsonValueKind.True => true,
        JsonValueKind.False => false,
        JsonValueKind.Null => null,
        JsonValueKind.String => node.GetValue<string>(),
        JsonValueKind.Number => node.GetValue<double>(),
        _ => (object?)node,
    };

Happy Coding

Jochen



VCR.NET 4 – alles geht einmal zu Ende…

Von | | , ,
Einen Kommentar hinterlassen

Ich weiß zwar nicht, ob es überhaupt noch Anwender vom VCR.NET Recording Service gibt, aber für alle Fälle hier ein kleiner Nachruf.

Geboren wurde VCR.NET als Version 1 vor ziemlich genau 21 Jahren – zum 10ten Geburtstag hatte ich noch einen kleinen Glückwunsch geschrieben. Zwischenzeitlich hatte ich VCR.NET 4 auf drei Rechnern hier im Hausnetz installiert und auch noch regelmäßig genutzt. Gerade eben habe ich die Installation vom letzten der drei Rechner entfernt.

Insbesondere kann ich daher VCR.NET 4 nun auch nicht mehr weiter pflegen – na gut, die letzte Korrektur ist nun auch schon über ein Jahr her. Also heißt das denn, VCR.NET ist eingestellt, weil ich es nicht mehr brauche? Weit gefehlt! Ich nutze VCR.NET weiterhin in der Version 5.

Also warum all das hier? Nun VCR.NET 5 ist nicht wirklich ein Nachfolger von VCR.NET 4 und insbesondere nicht mehr unter Windows lauffähig – was mir sogar zugute kommt, so komisch es auch klingen mag. Der Unterschiehabed liegt auch nicht wirklich im VCR.NET Recording Service, der sich immer noch genau so präsentiert wie bisher.

VCR.NET besteht zum einen aus der Planung und Ausführung von Aufzeichnungen – da hat sich nicht wirklich etwas getan, alles bis auf die umfangreiche Modernisierung der Code Basis von .NET 4 auf .NET Code 8 wie gehabt. Der andere Teil ist aber leider der Zugriff auf lokale DVB-Geräte über mein DVB.NET 4 Paket. Hier wird es keine Erneuerung mehr geben, im Gegenteil: DVB.NET 5 bietet nun keinen Zugriff auf die Windows spezifische BDA Schnittstelle zum Zugriff auf DVB-Geräte mehr.

Aber hallo: was soll denn ein Aufzeichnungssystem, dass gar nicht auf irgendwelche DVB Quellen zugreifen kann. Wird nun IPTV verwendet? Nein, dem ist nicht so.

Angefangen hat es eigentlich damit, dass ich unseren privaten Rechnerpark aus verschieden Gründen auf Barebones (Shuttle) umgestellt habe. Damit war der Einsatz von PCI basierten DVB-Karten beendet – adieu Nexus, Nova et al. In diesem Schritt habe ich auf USB Geräte umgestellt – aktuell habe ich 5 Technotrend S2-4600 und eine S2-3600. Und dann kam der Windows 10 Update GAU – ich meine es war der Update 1809 also Ende 2018: der Treiber der S2-4600 produzierte einen BSOD und ich meine sogar dass das Problem nie gelöst worden ist. Ich habe dann zwar eine Weile auf den Update verzichtet, mir war aber klar, dass das keine Lösung auf Dauer sein konnte.

Da ich zu diesem Zeitpunkt beruflich schon viel mit Linux zu tun hatte habe ich mir einen kleinen DVB Proxy für Linux geschrieben, der über TCP/IP gesteuert auf DVB Geräte unter Linux zugreift und das Ergebnis als DVB Transport Stream an einen Client senden kann. Dafür ist dann in DVB.NET 4 ein Gerätetreiber entstanden, so dass ich meine fünf S2-4600 an einen kleinen Barebone angeschlossen und in VCR.NET 4 konfiguriert habe.

Das funktionierte eigentlich über Jahre ganz gut aber ich habe mich nun entschlossen, den nächsten Schritt zu gehen und vor allem die Code Basis wie erwähnt zu modernisieren. DVB.NET 5 kann aktuell nur noch diesen Linux Zugriff auf DVB Geräte nutzen – der meiste Windows spezifische Code wurde entfernt, tatsächlich auch mit einem weinenden Auge, da eine Menge cooler Code zum Zugriff auf die COM Schnittstellen von BDA enthalten war. VCR.NET 5 kann daher auch genau nur das: über TCP/IP auf das proprietäre TCP/IP Protokoll zugreifen – gut, da wäre Luft nach oben, aber so ist es Stand heute. Aktuell gibt es noch stärkere Einschränkungen, die für mich aber irrelevant sind: es wird nur der Empfang über Satellit (DVB-S und DVB-S2) unterstützt und eine Entschlüsselung ist nicht möglich.

Eigentlich gibt es nun auch keinen Grund mehr, VCR.NET 5 auf einem Windows Rechner laufen zu lassen. Ich werde dazu je nach Zeit bei Gelegenheit mal mehr dazu schreiben, hier nur in Kürze: VCR.NET 5 wird nicht mehr als Installationsprogramm für Windows sondern als docker Image bereit gestellt. Die Installation erfordert etwas Vorbereitung, da werde ich für (vermutlich äußerst wenige) Interessierte noch eine Beschreibung zur Verfügung stellen. Bei mir läuft VCR.NET 5 aber nun seit einigen Tage produktiv auf meinem DVB Barebone – Performance scheint kein großes Problem zu sein, auch wenn alle 5 Karten gleichzeitig im Betrieb sind.

Es gibt nun keine lokale Windows Installation mehr – kein VCR.NET Kontrollzentrum, kein Aufwecken für die Programmzeitschrift, … Der Zugriff erfolgt einfach über einen Web Browser, die Dateien werden über ein SMB Share für Windows bereit gestellt. Ein Demux mit ProjectX kann nach etwas Vorbereitung direkt aus der Browser Anwendung gestartet werden. Da nun alles über den Browser geht ist auch die Nutzung von Smartphone, Tablet oder SmartTV möglich – letzteres scheiterte bisher auf die notwendige Windows NTLM Autorisierung, auf die ich bei VCR.NET 5 erst einmal verzichtet habe.

Fazit: VCR.NET (4) ist tot, es lebe VCR.NET (5).

Sorry, falls es doch noch VCR.NET Windows Fans da draußen gibt, aber das Leben geht halt weiter. Aktuell gehe ich davon aus, dass mich VCR.NET 5ff noch eine Weile privat begleiten wird, aber wer weiß was die Zeit bringt!

Have Fun

Jochen

Sendersuchlauf auf Astra 1 geht nicht mehr

Von | | ,
Einen Kommentar hinterlassen

Ich habe gerade per Zufall festgestellt, dass die Netzwerksuche auf Astra 1 nicht mehr funktioniert. Ich habe eine Korrektur in der Datei …\JMS\DVB.NET 4.3\Scan Locations\BuiltIn.dss erstellt und getestet. Eine neue Version von DVB.NET möchte ich nur deswegen aber nicht machen. Ich denke mal so viele Benutzer gibt es nicht mehr – vor allem keine, die ständig eine existierende Version neu installieren. Der Austausch muss nach einer Neuinstallation daher viederholt werden.

Die Netzwerksuche erfordert allerdings ein DVB-S2 fähiges Gerät – ich glaube, nur mit DVB-S steht man heute eh fast blind da. Sollte das ein wirklich ein Problem sein, kann ich gerne noch einmal weiter suchen.

Also: einfach die angehängte Datei herunterladen, entpacken, austauschen und nach dem nächsten Suchlauf sollte alles wieder gut sein – bei mir von 0 auf 1120 Quellen.

BuiltInHerunterladen


Viel Erfolg

Jochen

VCR.NET / DVB.NET und die Radiosender der ARD

Von | | ,
Einen Kommentar hinterlassen

Seit Mitte Dezember 2021 hat zumindest die ARD die Ausstrahlung ihrer Radioprogramme auf den AAC Codec umgestellt. Dieser wird von der DVB.NET Bibliothek bis einschließlich zur Version 4.3.17 nicht unterstützt und kann auch nicht mit Tricks aufgezeichnet werden – konkret: der Sendersuchlauf identifiziert Sender wie HR1 nicht als Radiosender und selbst wenn man DVB.NET sagt, dass es sich um einen Radiosender handelt ist die Aufzeichnungsdatei dann leer.

Ich habe das in DVB.NET 4.3.19 gefixt, diese Version wird nun auch im Downloadverzeichnis als Standard angeboten. Wenn man VCR.NET in der neuesten Version verwendet, dann kann man die DVB.NET Bibliothek auch leicht einzeln tauschen – die Prüfung auf die VCR.NET Version kann direkt auf der Startseite erfolgen:

Zum Austausch geht man wie folgt vor:

  • In der Liste der Windows Dienste den VCR.NET Recording Service stoppen (nicht pausieren / anhalten).
  • Mit den Einstellungen von Windows aus den Apps die alte DVB.NET Library Version entfernen.
  • Die neue DVB.NET Version installieren – im Allgemeinen mit den Standardeinstellungen.
  • Den VCR.NET Recording Service wieder starten.

Nach einem Sendersuchlauf sollten alle ARD Radiosender dann auch als solche erkannt werden und können aufgezeichnet werden.

Für die Nachbearbeitung ist dann nur noch zu beachten, dass als Codec halt AAC und nicht mehr MP2 verwendet wird. Ich selbst nutze das eigentlich fast nie und habe daher auch keine direkten Werkzeuge zur Weiterverarbeitung – auch das uralte ProjectX streikt hier völlig. In der Testphase habe ich eine solche Aufzeichnung aus VLC heraus nach WAV oder MP3 konvertiert und dann mit Audacity bearbeitet – das geht aber sicher eleganter.

Viel Spaß

Jochen