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 4.3.52: kleinere Fixes

Ich musste nun doch zwei kleine nervige Fehler beheben:

  • Läuft mehr als eine Aufzeichnung (egal ob auf einer oder mehreren Karten) und man beendet eine manuell mit gleichzeitigem Unterdrücken des Übergangs in den Schlafzustand (was in diesem Fall eigentlich sinnlos ist, da ja noch mindestens eine weitere Aufzeichnung aktiv ist!), so geht der Dienst auch nach Beenden aller anderen Aufzeichnungen nicht in den Schlafzustand.
  • Hat man einen Suchfavoriten definiert, bei dem ein Filter auf Fernsehsendung oder Radioausstrahlung aktiv ist, so wird dieser Filter in der Favoritenansicht nicht berücksichtigt und die angezeigte Anzahl ist eventuell zu groß – richtig lästig, wenn die Anzahl eigentlich 0 sein sollte. Tatsächlich ist nur die angezeigte Anzahl falsch, der Aufruf des Favoriten meldet die korrekten Sendungen in der Programmzeitschrift.

Dann habe ich noch was ganz Dummes getan: ich habe auf die aktuelle Version von jQuery (3.1.1) und jQueryUI (1.12.1) umgestellt, was erst einmal einige Clitches in der Oberfläche nach sich zog. Einiges habe ich korrigiert, einiges ist anders aber in Ordnung und einiges nicht mehr so schön wie vorher aber erträglich. Im Moment fehlt mir die Zeit, die (CSS / LESS) Styles anzupassen, aber da ich den VCR.NET Recording Service ja auch selbst nutze werde ich nach und nach versuchen, die Ecken und Kanten zu glätten.

Wie dem auch sei: der aktuelle Stand kann direkt von mir (VCRNET.msi) oder auch von Heise bezogen werden.

Viel Spaß weiterhin

Jochen

VCR.NET 4.3.47: kleinere Fixes und eine Erweiterung

Im täglichen Betrieb habe ich doch einige kleinere Probleme festgestellt, die mich genervt haben und die hiermit behoben sind:

  • Wenn man während einer laufenden Aufgabe (Programmzeitschrift oder Sendersuchlauf) oder Aufzeichnung eine neue Aufzeichnung so anlegt, dass sie eigentlich direkt beginnen müsste, dann zeigte der Aufzeichnungsplan völlig wirres Zeug an: Aufzeichnungen Tage später können angeblich nicht mehr ausgeführt werden und ähnliches.
  • Zu einer Aufzeichnung wird immer auch ein Auftrag angelegt. Die Möglichkeit, weitere Aufzeichnungen zu einem Auftrag hinzuzufügen wird selten verwendet – außer wohl von mir selbst 🙂 Wie dem auch sei: wenn man bei einer weiteren Aufzeichnung eine andere Quelle (Sender) einträgt und dann die Quelle des Auftrags entfernt, so wurde der Aufzeichnungsplan nicht mehr angezeigt – im Prinzip weil der ersten Aufzeichnung nun gar keine Quelle mehr zugeordnet ist.
  • Einige Sender wie E4 (UK) senden von Zeit zu Zeit sehr viel seltener die Sendereckdaten (PAT) als andere. Unabhängig von der konkreten Einstellung des Schlechtwetterschutzes erwartete der VCR.NET Recording Service, dass ein Sender sich spätestens alle 5 Sekunden meldet – üblich sind 2 bis 3 Sekunden. Erfolgt diese Meldung nicht, so wird die Aufzeichnung automatisch unterbrochen und dann später neu gestartet – sehr nützlich etwa bei der Lokalzeit des WDR. Leider hat E4 Phasen mit 9 und mehr Sekunden, was zu unnötigen Unterbrechungen der Aufzeichnung führte. Ich habe daher diese Grundzeit auf 15 Sekunden erhöht, das wäre dann auch die Reaktionszeit des Schlechtwetterschutzes – i.e. Werte unter 15 sind ab sofort sinnlos.

Zumindest für mich viel wichtiger ist aber eine Erweiterung im EasyCut. Ich nehme sehr viel englische Sender auf und versuche auch immer die Untertitel einzumischen. Wenn man wie ich dazu GUI for DVDAuthor (GfD) verwendet, so kann man nun nach dem Erstellen der Untertitelschnittdatei im SUP (SUB geht leider nicht, das habe ich mir aber eh schon lange abgewöhnt) direkt die Werkzeuge von GfD nutzen um eine Videodatei mit Bild, Ton und Untertitel zu erstellen. Das ist in der späteren Handhabung sehr viel einfacher als SUP und SUP.ISO bis zum Erstellen einer DVD mitzuschleppen.

Allerdings gibt es auch einige Wermutstropfen, die ich noch beobachten muss. Für mich passt es im Moment, aber warten wir mal ab:

  • GfD selbst passt die Originalfarben im Allgemeinen noch so an, dass die YCbCr Repräsentation aus dem Originalmaterial auch sicher auf RGB abgebildet werden kann. Das macht EasyCut nicht, bisher habe ich keine Unterschiede festestellen können.
  • Beim Einmischen der SUP in den geschnittenen Film meldet GfD im Normalbetrieb ab und an mal Fehler – zu kurze Untertitel, zu schnell aufeinanderfolgende Untertitel, überlappende Untertitel und so weiter. Diese Meldungen sollte EasyCut ignorieren – ich habe zumindest keine mehr gesehen.
  • Die zusammengemischte Datei wird direkt neben die Schnittdatei gelegt, der Dateiname erhält den Zusatz _SUP. Hier empfiehlt es sich dringend, dies nur auf schnellen Platten durchzuführen, da bei dem Vorgang eine große Datenmenge von der Platte gelesen und direkt wieder geschrieben wird – nun, ich nutze dafür eine SSD.

Die Installationspakete wurden an gewohnter Stelle und bei Heise aktualisiert.

Viel Spaß

Jochen

DVB.NET und DirectShow – der ewige Kampf

Nachdem ich nun meinen ersten PC auf Windows 10 aktualisiert habe musste ich feststellen, dass die mit Windows 7 noch verfügbaren Microsoft Video Codecs für MPEG-2 und H.264 nicht mehr zur Verfügung stehen – genau genommen ist das schon seit Windows 8 so, aber diese Version habe ich stillschweigend übersprungen. Das ist für mich etwas schade, da der DVB.NET / VCR.NET Viewer sehr pingelig bezüglich der verwendeten Codecs ist und mit den Microsoft Codecs ausgesprochen gut zurecht kam.

Ich habe daher die LAV Codecs installiert und grundsätzlich funktionieren die auch, nur leider ist der Ton deutlich sichtbar versetzt. Ich habe hier zwar etwas drehen können, aber mein mangelndes Wissen im Bereich BDA und DirectShow macht sich mal wieder sehr schmerzlich bemerkbar. Da ich nicht die Absicht habe, dieses Wissen zukünftig zu vertiefen, kann es sein, dass mit Windows 10 das endgültige Ende des Viewers gekommen ist. Ein kleiner Tweak hilft aber zumindest mir ein bisschen, so dass ich demnächst ein Update für den Viewer bereit stellen werden – eine wirkliche Weiterentwicklung der Version 4.3 wird es wie angekündigt nicht geben.

Doch nun zu einigen Details. Im Kern setzt DVB.NET zur Anzeige von Bild und Ton zwar auf BDA und DirectShow, verwendet allerdings keine der angebotenen Splitter. Vielmehr wird im Eingang ein TS (Transport Stream) selbst analysiert, was Teile des Codes nicht nur flexibler macht (es ist egal, ob der Strom von einer TV Karte, einer Datei oder über das Netzwerk ankommt) sondern tatsächlich auch den Code vereinheitlicht und vereinfacht.

Der Preis ist allerdings, dass Bild und Ton manuell in den BDA Graphen injiziert werden müssen. Aus nicht mehr ganz nachvollziehbaren Gründen (ja, das ist teilweise schon sehr lange her – sorry) versetzt DVB.NET die so genannte Stream Time der Tonspur um eine halbe Sekunde nach hinten. Die Idee war damals bei langsameren Rechnern wohl, dass der Video-Codec Zeit erhalten sollte, das Bild vorzubereiten, bevor dies synchron mit dem Ton angezeigt wird. Irgendwie kommt LAV aber mit dieser Manipulation wohl nicht klar.

Da dieser Parameter (AVDelay im Code) sowieso schon konfigurierbar war, hat der Viewer nun die Möglichkeit erhalten, diese Einstellung in einem gewissen Rahmen (+/- 2 Sekunden) vorzugeben. Mit einem Wert von 0 scheint es im Moment einigermaßen ordentlich zu funktionieren – perfekt ist es aber nicht! Ich werde das weiter beobachten, eventuell wird dieser Work-Around aber als Patch veröffentlicht – schauen wir einmal.

Neue Einstellungen

Bis bald

Jochen

P.S.: Ein Wert von 100 hat sich zumindest bei mir hier ganz gut bewährt und ich habe die Version Online gestellt.

Support für Versionen vor 4.3 eingestellt

Mit der Freigabe der Version 4.3 vom VCR.NET Recording Service, DVB.NET und dem VCR.NET / DVB.NET Viewer wird der Support für alle älteren Versionen einschließlich der Version 4.2 eingestellt. Insbesondere wird nun Windows XP nicht mehr unterstützt – ich hoffe, dass ich damit keinen zu hart treffe, aber die 4.2 hat sich ja im letzten Jahr als ausreichend stabil erwiesen.

Jochen