Sendersuchlauf auf Astra 1 geht nicht mehr

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.


Viel Erfolg

Jochen

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

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

Quo Vadis Window 10 – oder R.I.P. S2-4600

Wie ja bekannt ist eines meiner Hobbyprojekte der VCR.NET Recording Service unter Windows. Die Tatsache der intensiven Eigennutzung führt nun dazu, dass ich immer noch auf Windows 10 1803 bin. Warum das? Nun ich habe hier mehrere DVB-S2 Geräte (Technotrend S2-4600) via USB im Einsatz und alle Windows Versionen ab 1809 führen zu einem BSOD, wenn dieses Gerät im Einsatz ist. Leider bin ich da wohl nicht der Einzige und bis heute gibt es dafür keine akzeptable Lösung.

Neue USB Karten kommen erst mal nicht in Frage – wer weiß, welche überhaupt noch gehen und wann es diese auch trifft. Da ich schon seit längerem auf Ubuntu (Linux) als primäre Entwicklungsumgebung umgeschwenkt bin habe ich mir mal angeschaut, wie es da aussieht. Tatsächlich läuft die Karte dort unter gleichen Bedingungen, ich würde sogar sagen etwas besser als unter Windows.

Nun kam mir die Idee, eine an ein Ubuntu angeschlossene Karte in VCR.NET zu nutzen. Es gäbe hier viel zu erzählen ich fasse mich aber mal so kurz wie möglich und erläutere nur den aktuellen Stand.

Die erste Idee war die Anbindung war die Ansteuerung über SAT/IP – etwas was in VCR.NET / DVB.NET schon lange aussteht. Allerdings wäre die Implementierung in DVB.NET doch etwas aufwändiger und der Ubuntu Proxy den ich mir angeschaut habe (tvheadend) hat mich nicht gerade begeistert – der könnte lokale DVB Karten via SAT/IP im Netz anbieten. Ich habe mich daher für eine Minimallösung mit Lerneffekt entschieden – sprich proprietär aber mit etwas API Spielereien.

Für Ubuntu gibt es dazu ein kleines Tool (GIT) auf Basis der DVBv3 API – die alte Version der Linux DVB API passt sehr schön zu meinem DVB Einstiegsprojekt vor vielen Jahren: der TechnoTrend API für die Premium Line (Hauppauge Nexus). Das Tool stellt einen TCP Kanal zur Verfügung, über den man Remote eine Karte reservieren und steuern kann. Die angeforderten Nutzdaten (Streams) werden dann über diesen Kanal an den Aufrufer ermittelt. Zurzeit weil es einfacher war über ein proprietäres Protokoll, was ich aber aufgrund von potentiellen Datenübertragungsfehlern auf TS umstellen sollte – im Moment tut es als PoC aber erst mal.

Auf der anderen (DVB.NET / Windows) Seite gibt es dann einen neuen Provider, der bis auf die Art der Kommunikation quasi dem der Nexus entspricht – und der ist nicht einmal besonders umfangreich (GIT).

Ich gehe mit der Version jetzt erst mal in den privaten Test. Tatsächlich gibt es durchaus noch diverse Probleme esp. mit der Stabilität nach Sendersuchlauf und Programmzeitschrift, aber dazu ist ja so eine Testphase da. Immerhin funktionierte ein sauberes Aufzeichnen aller (12 glaube ich) Sender eines Transponders (VOX) parallel – etwa 32 MBit/s im Netzwerk, was aber bei 1 GBit/s Problem ist. Die CPU Last auf Ubuntu war mit unter 5% überschaubar – allerdings auf meinem kräftigeren Entwicklungssystem mit einem i7-8700, i.e. ca. 60% eines Kerns ausgelastet. Wenn das alles klappt sollen alle aktuellen Karten im Haus (5 an 4 Windows Rechnern – nur einer ist der meine) an einen einzigen Linux Rechner angeschlossen werden.

Immerhin: mal wieder C/C++ unter Linux gemacht (wirklich hässlich, ist ja auch schon weit über 20 Jahre her gewesen) und noch mal C# aufgefrischt (ja, da muss ich mich wirklich wieder einarbeiten) und dabei auch richtig über die Performance Visual Studio Pro geärgert – VSCode ist schon cool…

Soweit dazu, schauen wir mal

Jochen

VCR.NET Recording Service 4.5

Wie angedroht habe ich die Version nach einigen privaten Tests freigegeben. Wie üblich kann man diese direkt bei mir oder bei Heise herunterladen. Geändert hat sich allerdings bis auf die Oberflächentechnologie des Web Clients nicht viel.

Nochmal der Hinweis: es gibt KEINE neue Version von DVB.NET (i.e. 4.3 ist die aktuellste) und auch die Systemvoraussetzungen (e.g. bezüglich Microsoft.NET) haben sich NICHT verändert.

Viel Spaß

Jochen

Über den VCR.NET 4.5 Web Client

Der erste HTML5 / JavaScript Web Client des VCR.NET Recording Service setzte zur Oberflächenanbindung auf jQuery(UI) ohne ein explizites Binding Framework wie etwa AngularJS. Ich habe an dieser Stelle einiges an Erfahrung sammeln müssen – nicht zuletzt auch was JavaScript Anwendungen und deren DOM Anbindung an sich angeht. So aus einiger (zeitlicher) Entfernung betrachtet ist die Vernetzung von Anwendungs- und Präsentationslogik doch sehr viel enger, als ich mir das eigentlich gewünscht hätte.

Ziel des neuen Web Clients ist es, diese Trennung sehr viel strenger vorzunehmen. Tatsächlich glaube ich, dass der Kern der Anwendung eigentlich ohne Präsentation lauffähig ist – das wäre für einen normalen MVC* Ansatz sicher genau so. Allerdings sind sich die Präsentationsmodelle durchaus bewußt, dass hier nicht irgendeine Anwendung implementiert wird, sondern dass konkret HTML5 angezeigt werden soll. So gibt es etwa zur Anzeige einer Zeitschiene oder der Pflege einer Zahl in einem festen Bereich über einen Slider konkrete Anwendungslogik, die indirekt mit dem DOM interagiert (Positionsangaben in %, Drag&Drop Benachrichtigungen usw.), ohne allerdings zu wissen, wie das DOM dann tatsächlich erstellt und nachgeführt wird – mein schon vor längere Zeit im Kopf entstandene Arbeitstitel dafür sind NoUi (eine Logik zur Anzeige einer HTML5 Anwendung ohne an irgendeiner Stelle irgendwas mit dem DOM zu tun zu haben) und Ui View Model (ein Präsentationsmodell, das nicht nur Modelldaten à la DTO unterstützt, sondern halt auch DOM relevante Fähigkeiten besitzt). Ok, hier im ersten Anlauf sicher noch zu grob in der Umsetzung, aber schauen wir mal, ob es eine nächste Version gibt.

Tatsächlich kann man so etwas natürlich auch mit AngularJS und den verschiendensten Konzepten darin umsetzen. Mein (subjektives!) Gefühl ist aber, dass ich mich dann tatsächlich auf Angular-For-Everything-And-Everytime festlege. Daher habe ich hier mit React.Js und (mal wieder: aber nur so lernt man wirklich etwas über die Anforderungen von Abläufen) eigener Anwendungslogik inklusive einer kleinen NoUi Bibliothek angefangen. Erst hatte ich ein bißchen schlechtes Gewissen, dass Zuckerberg schimpfen kommt, weil ich (bis auf eine Ausnahme) an keiner Stelle den State der React.Js Komponenten verwende. Aber die Redux Dokumentation belehrte mich dann eines Besseren: auch deren React.Js Integration verzichtet (im Allgemeinen) auf den React.Js State und bildet diesen auf den eigenen ab und das ist wohl auch gut so – wobei es durchaus nicht wirklich immer klar ist, wo man diesen Schnitt setzen sollte (nicht bezogen auf Redux sonder ganz allgemein betrachtet)!

Vielleicht stelle ich ja in Zukunft den Web Client noch weiter auf Bibliotheken wie Redux um (nicht zuletzt weil ich mich voraussichtlich in naher Zukunft auch beruflich damit intensiver auseinandersetzen werde), aber im Moment scheint mir der aktuelle Versuch im VCR.NET 4.5 Web Client auch nicht so falsch zu sein. Ja, ich nutze letztlich zwei Frameworks: eines für die DOM Manipulation und eines für die Anwendungslogik respektive des für die Anzeige relevanten Zustands. Im Hinblick auf die Programmierung in anderen Welten (Web Dienste / Middleware / Backend / Desktop Anwendungen e.g. mit C# und .NET) fühlt sich die aktuelle Implementierung mit einer echten Objektstruktur und daraus gezielt zur Anzeige gespiegelten Teilzustände richtig an. Redux scheint da zwar viel pragmatischer und mit seinem Plain-Object-State sehr viel einfacher zu sein, aber ohne Redux praktisch eingesetzt zu haben scheinen mir die wesentlichen Kernanforderungen eines realen Web Clients nicht verschwunden, sondern einfach nur in viele AddOns / PlugIns / Extensions ausgelagert zu sein. Darüber kann und will ich mir heute kein Urteil erlauben – schauen wir mal, was die nächsten Monate bringen.

Falls jemand sich die Quellen des Web Clients mal anschauen möchte, hier nur kurz ein kleiner Stadtplan: es gibt präsentationsfreie Anwendungslogik in einer kleinen Bibiothek und den VCR.NET Teil selbst. Dazu einen auf React.Js basierenden Satz von übergreifenden Komponenten sowie auch hier separat der VCR.NET Teil, diesmal weiter aufgeteilt in spezialisierte und gemeinsame React.Js Komponenten. Dazu kommen noch Typdefinitionen und Proxies für die REST Web Dienste des VCR.NET Recording Service und der Rahmen der SPA.

Viel Spaß und hoffentlich irgendwann einmal mehr zu dieser Baustelle

Jochen