Liebe Anwender,

nach einer langen Durststrecke (und dem mühsamen Rückbau des SqlCe Experimentes) habe ich für mich nun einen Kompromiss gefunden, den es in absehbarer Zeit als VCR.NET Version 4.0 geben wird. Von vielen (hier diskutierten aber auch nur im Kämmerlein geplanten) Zielen werden nur einige umgesetzt und diese auch nicht in vollem Umfang. Aber ich glaube, in einigen wesentlichen Aspekten, die ich gleich aufführe, wird es zumindest für Euch merkliche und für mich (i.e. im Programmcode) nützliche Änderungen geben.

Zu den einzelnen Punkten werde ich in nächster Zeit (Tage? Wochen?) bei Gelegenheit hier im Forum Informationen ergänzen. Trotzdem hier einmal die wesentlichen Änderungen gegenüber der Vorversion 3.9:

• VCR.NET 4.0 basiert natürlich auf DVB.NET 4.0 und profitiert damit von den bereits vorgestellten Änderungen. Scheinbar (allerdings für mich unerklärlich) haben insbesondere die Umstrukturierungen bei der BDA Ansteuerung einen positiven Effekt auf einige BDA Treiber - letztens im DVB.NET Forum im Rahmen des Sendersuchlaufs diskutiert. VCR.NET 4.0 wird auch die Möglichkeit nutzen, im Administrations- & Konfigurationswerkzeug von DVB.NET Einstellungen speziell für Aufzeichnungsprogramme auf Basis von DVB.NET zu verwalten. Die Umstellung auf DVB.NET 4.0 ist abgeschlossen.


• Ich habe gerade eine erste VCR.NET 4.0 Version mit verändertem Zeitplaner in Betrieb genommen - und in den ersten zwei Tagen so viele Kinderkrankheiten beseitigt, dass ich noch keinen Download anbieten möchte. Hier wird es gegenüber der schon vorgestellten Planung doch einige Abstriche geben: die Planung erfolgt in 4.0 noch nicht über mehrere Profile hinweg, sondern immer nur für ein Profil. Trotzdem ergibt sich schon jetzt ein verändertes Verhalten, das vermutlich größtenteils von Vorteil ist - in Einzelfällen ist eine Rückschaltung auf so etwas Ähnliches wie den aktuellen Betrieb mit 3.9 möglich. Kritisch im Bereich der Zeitplanung ist noch das Testen im Zusammenspiel mit PayTV und CI/CAM basierter Entschlüsselung - vorweg sei schon gesagt, dass durch die Planung pro Gerät der Einsatz von einem gemeinsamen Entschlüsselungsmodul mehrerer DVB Geräte nur begrenzt in der Planung unterstützt werden kann.


• Ab Windows Vista ist es nicht mehr möglich durch einen Dienst den Übergang in den Schlafzustand zu verhindern. Leider basiert die Implementierung des VCR.NET immer noch auf dieser Annahme und läuft nur unter Windows XP richtig. Hier werde ich noch ein wenig forschen müssen, vermutlich wird aber eine relativ einfache Lösung herauskommen, die dem Anwender etwas mehr an Verantwortung in die Hände drückt - wenn ich unter Windows 7 das Energie Sparen anfordere, dann wird das auch passieren und VCR.NET sollte alle laufenden Aufzeichnungen beenden [oder den Away Modus benutzen, aber da bin ich noch unschlüssig]. In Zusammenhang mit diesen Entwicklungen, die ich noch nicht begonnen habe, will ich auch einige bekannte Fehler im Zusammenhang mit dem Schlafzustand und dem VCR.NET Kontrollzentrum beheben.

Ein erklecklicher Teil an Zeit wird auch in Testen und Erneuerung der Hilfe / HomePage zu investieren sein. Die Erfahrungen mit den letzten Versionen lassen vermuten, dass sich gerade letzteres doch in Tagen rechnet. Und das obwohl bisher neue Versionen oft viele kleine Änderungen enthielten aber insgesamt wenig an Erläuterungen erforderten, wie nun im Bereich der Zeitplanung erforderlich. Vermutlich werde ich dabei versuchen, jeden ausführlicheren Punkt an nur einer Stelle aufzuführen - das werden voraussichtlich primär die lokalen Hilfeseiten des Dienstes sein, i.e. leider erst nach Installation zur Verfügung stehen.

Puh, das muss erst einmal reichen

Bis bald

Jochen

Ich habe die aktuelle Testversion bereitgestellt, der Dateiname mit dem RC hintendran deutet darauf hin, dass ich eigentlich nicht mehr viel ändern möchte. Aber Achtung: ich kann hier nur einen begrenzten Teil der Funktionalität testen, e.g. Betriebssystem (XP und Win7, jeweils 32Bit) oder Hardware (nur TechnoTrend / Hauppauge DVB-S(2), ohne CI/CAM Entschlüsselung). Daher kann es durchaus sein, dass noch dicke Klöpse vorhanden sind.

Die Backupstrategie zum Testen sollte sein: 3.9 komplett (immer mit VCR.NET beginnen!) deinstallieren, dann das verbleibende VCR.NET Installationsverzeichnis sichern (sonst nichts daran ändern) und zusätzlich die Geräteprofile (%AllUsersProfile%\DVBNETProfiles) wegkopieren (natürlich nicht löschen). Ich empfehle nämlich, die verwendeten Geräteprofile auf 4.0 zu migrieren (je nach Gusto auch nach der Installation von DVB.NET 4.0, aber vor der vom VCR.NET). Das gibt dann kein einfaches Zurück mehr, ohne die alten Profile wieder herzustellen. 

Ansonsten wie gehabt: nach der Deinstallation DVB.NET 4.0 installieren (Bibliothek, Server, optional Tools), nach Wunsch den Viewer und dann VCR.NET 4.0.

Ich werde nun versuchen, nach und nach (nach == nach Lust, Laune und Zeit - sorry!) die Dokumentationen parallel zu 3.9 online zu stellen. Bisher hat es leider nur für DVB.NET 4.0 gereicht. Das nächste wird vermutlich der Viewer sein, da sich da fast nichts getan hat. VCR.NET kommt am Ende, da muss ich aufräumen, neue Bilder machen und die Historie einpflegen.

Viel Glück und hoffentlich auch Spaß mit VCR.NET 4.0

Jochen

Zusatz 1: Die RC Home Page des Viewers ist nun auch verfügbar.

Hinweis: Die Links in den RC Home Pages verweisen auf die alten Setups, zum Mittesten bitte das Verzeichnis am Anfang dieses Posts verwenden.

Zusatz 2: Die RC Home Page vom VCR.NET ist nun doch schon da - puh! Hier auch die Liste mit den wichtigsten Änderungen, das meiste steht aber schon im Forum.

Hallo Jochen,

ich habe heute die RC installiert und gleich mal das neue Aufzeichnungssystem mit mehreren Dateien bei parallelen Aufzeichnungen eines verschlüsselten Senders getestet.

Bei überlappenden Aufnahmen werden wie beschrieben 2 Dateien erzeugt. Leider produziert das Unicam beim Start der zweiten Aufnahme eine Störung in der ersten Aufnahme. Das ist ein bekannter Bug des Unicam, der sich besonders in der Kombination mit Digital Devices Karten bemerkbar macht.

Im Tuner Log sehe ich folgendes:

01.09.2012 11:36:09 DDCommonInterface Device 300:30000: Set Program 61301 CI 2

01.09.2012 11:38:06 DDCommonInterface Device 300:30000: Set Program 61301 CI 2

Ist der zweite CI Befehl zwingend nötig ?

Wenn ich den Kompatibilitätsmodus aktiviere, sind die beiden CI Befehle ganz am Anfang und ich habe zwei identische Dateien. Bei HD Aufzeichnungen kann hier einiges zusammenkommen. Wäre es nicht möglich die redundanten Dateien wegzulassen ?

Helmuth

Ok, habe etwas gebraucht, das zu verstehen. Du hast eine überlappende Aufzeichnung auf der selben Quelle. Da habe ich offenbar nicht lange genug nachgedacht!

Die eine Datei weglassen ist im neuen Code etwas kniffeliger. Früher war es so, dass VCR.NET sich eine Überdatei mit allen Eigenschaften zusammen gebastelt hat, e.g. einmal ZDF mit nur Stereo und Videotext, ein zweites überlappendes mit Stereo und nur AC3 und DVB Untertitel gab eine Datei mit Stereo, Videotext, AC3 und DVB Untertitel. Das will ich eigentlich nicht mehr. Auch das mit der einen großen Datei, die dann den falschen Namen hat, ist nicht wirklich prickelnd.

Was ich aber versuchen könnte wäre zu schauen, ob die DVB.NET Treiber nicht erkennen könnten, dass der zweite CI Befehl überflüssig ist. Das ist evtl. einfacher.

Ich bin aber gleich länger vom PC weg, denke aber, dass ich Morgen mal recherchieren kann.

Sorry für die Mühen

Jochen

Ok, Schnellschuss: probiere die hier mal (DVB.NET RunTime, Sicherheitskopie da völlig ohne Garantie!). Das sollte das zusätzliche Entschlüsseln vermeiden.

Bin weg

Jochen

Vielen Dank. Jetzt wird nur noch einmal das CI Kommando gesendet und die Störungen sind weg. Ich hoffe sehr das es mal irgendwann eine Unicam/Maxcam Software ohne diese saudoofe Einschränkung bei Mehrfachentschlüsselungen gibt.

Helmuth

Naja, das war eher mein Bug, da nur eine Quelle angesprochen wurde und wie Du richtig geschrieben hast der zweite Entschlüsselungsbefehl völlig unnötig ist! Aber grundsätzlich hast Du natürlich Recht, da es ja auch andere Situationen betrifft.

Sehr nett übrigens, dass Du mich beim Testen unterstützt!

Ein schönes Wochenende noch

Jochen

Zusatz: habe die Downloads aktualisiert, betraf aber VCR.NET selbst nicht, nur DVB.NET Bibliothek (Core) und Server.

Die Downloads vom RC wurden erneutert.

• Fix (DVB.NET): wird eine verschlüsselte Quelle aufgezeichnet und während der noch laufenden Aufzeichnung eine zweite auf der selben Quelle gestartet, so versucht DVB.NET nun nicht mehr, die bereits aktive Entschlüsselung noch einmal zu aktivieren. Dies konnte zu Störungen in der ersten Aufzeichnung führen. [mrth]


• Fix (VCR.NET): über eine Ausnahmeregel wird eine sich wiederholende Aufzeichnung vorverlegt und dann während dieses Ausnahmezeitraums vorzeitig beendet. Dies geschieht vor dem Zeitpunkt, an dem die Aufzeichnung ohne Wiederholung starten würde. Ohne die Korrektur in diesem Fix würde VCR.NET die Aufzeichnung dann sofort wieder starten und bis zum Ende der Ausnahmeregel laufen lassen. Der Fix ist leider nicht ganz konsequent und wirkt nur, wenn die Verschiebung (plus Laufzeit) weniger als 12 Stunden beträgt - ich denke aber mal, das sollte produktiv kein Problem darstellen. [JMS]

Sorry

Jochen

Eine Frage zum EPG:

Ich habe folgende Einstellungen:

Wartezeit: 12h

Aktualisierungen: 6:00

Latenzzeit: 8h

 

Letzte Aktualisierung: gestern um 6:00

nächste geplante Aufzeichnung: 20:00

letzte Aufzeichnung: bis 13:00

 

Um 18:30 habe ich den Rechner aus dem Schlafzustand aufgeweckt und der EPG lief sofort los: korrekt da mehr als 12 und mehr als 8 Stunden seit der letzten Aktualisierung her sind. Nach der letzten Aufzeichnung waren die 8h noch nicht rum.

Nach dem EPG Lauf wurde der Rechner gleich wieder um 18:45 runtergefahren, weil die nächste Aufzeichnung ja erst um 20:00 ansteht. Ist das Verhalten richtig ? Oder wäre es besser bei vorgezogenem EPG das direkt nach dem manuellen Aufwachen kommt den Shutdown wegzulassen ? Kann aber auch sein, das solche Sonderregelungen viel zu kompliziert sind und der Aufwand viel zu groß wäre.

In der Online Hilfe steht nicht viel zur Latenzzeit. Ein paar Beispiele wären da hilfreich. Ist es sinnvoller die Latenzzeit größer oder kleiner als die Wartezeit zu machen ? Die Threads vom letzten Jahr zu dem Thema habe ich nicht mehr gefunden.

Helmuth

Um ganz ehrlich zu sein: nachdem ich das damals implementiert habe, habe ich da nichts mehr geändert und jetzt auch nicht neu darüber nachgedacht. Muss ich erst mal wieder herauskramen. Ich dachte, ich hätte das mit der Latenzzeit so beschrieben, wie ich es verstanden habe: wenn eine Aufzeichnung zu Ende ist und VCR.NET eigentlich in den Schlafzustand übergehen würde, die nächste Aktualisierung aber näher als die Latenzzeit ist, wird die eben noch durchgeführt.

Die Latenzzeit kommt hier aber gar nicht zum tragen, oder? Ich sehe hier eher das Problem mit dem sicheren Erkennen des manuellen Aufwachens. In der Tat KANN der VCR.NET das unterscheiden, reagiert aber nicht darauf. Der Erfahrung nach ist die Information von Windows fast immer richtig aber ab und an gibt es bei mir doch die Meldung, dass ein manuelles Aufwachen erfolgt ist (kann man im Ereignisprotokoll bei voller Protokollierung des VCR.NET sehen) - ich vermute, dass es bei mir Fehlimpulse der optischen Maus sind.

Ich könnte mir gut vorstellen, das konfigurierbar zu machen. Wäre für mich persönlich nicht die ideale Lösung: manchmal wecke ich den Rechner nur kurz auf, um Mails zu lesen. Wenn dann die Aktualisierung zuschlägt und der VCR.NET nicht automatisch herunterfährt, würde ich mich ärgern. Ok, man kann es nicht jedem Recht machen.

Ich muss aber mal das mit der Wartezeit nochmal nachschlagen. Ich wundere mich, dass die Programmzeitschrift nicht bereits vorher aktualisiert wurde. Ich schaue mal in den Code und melde mich dann.

Ach ja: ich habe versucht, die Dokumentation knapp zu halten und nur die wichtigsten Aspekte zu erwähnen. Ich dachte mir, wir könnten dann hier im Forum so eine Art FAQ für spezielle Themen machen.

Vielleich bis gleich

Jochen

Also so ist es für 4.0 implementiert (ich habe es für 4.1 mal ganz oben auf die Liste gesetzt, da muss ich ordentlich 'drüber nachdenken, evtl. kann man ein SP für 4.0 nachziehen):

1. Das folgende findet nur statt, wenn VCR.NET den Zeitpunkt für die nächste Aufzeichnung berechnet (4.1 : vielleicht periodisch prüfen? viellecht explizit das Join beachten?), das ist eher selten. Sicher beim Starten / Aufwachen, sonst aber nur rund um Aufzeichnungen.


2. Die Latenzzeit hat oberste Priorität (daher sorry in der letzten Mail meine Fehlinterpretation: diese hat hier in der Tat zugeschlagen). Liegt die letzte Aktualisierung länger zurück als die Latenzzeit, so wird die Aktualisierung in die Planung aufgenommen. Das ist beim manuellen Aufwachen fast immer falsch, bei programmiertem Aufwachen fast immer richtig (4.1 : eine Berücksichtigung der Latenzzeit sollte nur erfolgen, wenn eine Aufzeichnung aktiv ist / war / sein wird - ich schaue mal, ob ich das nicht in 4.0 bekomme, will aber nichts versprechen).


3. Der früheste Zeitpunkt einer erneuten Aktualisierung ist das Ende der letzten Aktualisierung plus (minimaler) Wartezeit, sofern diese definiert ist.


4. Der tatsächliche Zeitpunkt wird dann noch auf die nächste volle passende Stunde geschoben, falls mindestens eine konfiguriert ist.

In Deinem Beispiel hast Du nur eine konfigurierte Stunde (06:00), i.e. eine Wartezeit von unter 24 Stunden bewirkt meiner Ansicht nach gar nichts. Genau 24 Stunden würden immer einen Tag überspringen, da vom Ende an gemessen wird. Sinn macht die Wartezeit, wenn man entweder die Stunden ganz weglässt (zum Beispiel wenn der VCR.NET Rechner NICHT im Schlafzimmer steht) oder man alle vier Stunden programmiert und soviel aufnimmt, dass man nie genau weiß, wann eine Aktualisierung stattgefunden hat.

Jochen

ZUSATZ: Geht doch nicht so einfach, das mit dem Berücksichtigen der Latenzzeit, wenn eine Aufzeichnung aktiv ist. Ich würde das gerne auf nach 4.0 verschieben, auch wenn es jetzt mit dem manuellen Aufwachen nicht so ist, wie es sein soll.

Für 4.0 könnte ich die angehängte Lösung anbieten. Sie würde dafür sorgen, dass die Latenzzeit ignoriert wird, solange der VCR.NET nicht irgendwas getan hat. Insbesondere heißt das, das die Aktualisierung nicht nach dem Aufwachen sofort losläuft. Nachteile:

• Weckst Du den Rechner auf, machst nichts (keine Aktivitäten, Programmierung ist davon nciht betroffen) mit dem VCR.NET, dann wird die Aktualisierung auch nicht loslaufen, wenn Du den Rechner dann in den Schlafzustand versetzt - ab Vista kann VCR.NET grundsätzlich den manuellen Übergang in Schlafzustand nicht mehr verhindern, User wins!


• Aktivität bedeutet neben regulärer Aufzeichnung und Aktualisierung von Programmzeitschrift oder Liste der Quellen aber leider auch, dass die Latenzzeit nach der Nutzung des Live Modus (DVB.NET / VCR.NET Viewer) oder einer Testaufzeichnung aktiviert wird. Ersteres wäre noch relativ einfach zu ergänzen, letzteres etwas aufwändiger.

Kannst Du mal prüfen, ob das für 4.0 für Dich so reicht? Dann würde ich die Downloads aktualisieren. Freigabe habe ich erst in den nächsten Wochen geplant, sicher aber vor meinem Geburtstag Ende des Monats.

Jochen

Werde ich morgen früh mal einspielen und in den nächsten Tagen mal das EPG Verhalten beobachten.

Latenzzeit nach Viewer: auf Dauer vielleicht doch lästig wenn der Rechner dann plötzlich runterfahren will. Allerdings bin ich ohnehin weniger der Live User.

Testaufnahme: Habe ich zwar irgendwo mal gesehen, aber wenn mich jemand fragt wo man die findet, könnte ich das erst mal nicht sagen. Die Funktion habe ich noch nie genutzt.

Ich versuche es mal dann mit der folgenden Einstellung (PC steht im Wohnzimmer):

Wartezeit: 12h

Aktualisierungen:

Latenzzeit: 8h

 

Falls keine Aufzeichnungen anstehen soll alle 12h eine Aktualisierung stattfinden, und auch nach einer Aufzeichnung falls es schon länger als 8h her ist.

Helmuth

Na gut, hier die Variante mit dem Live Modus (wird für die Latenzzeit ignoriert).

Vielen Dank!

Jochen

Hallo Jochen,

das EPG läuft jetzt wie erwartet und ohne Pobleme.

Gerade habe ich aber ein seltsames Problem:

Tuner 1: Aufnahme Syfy HD, verschlüsselt: läuft ohne Probleme

Tuner 2,3: haben nichts zu tun

Tuner 4: hier sollte etwas später nach Start der Aufnahme 1 eine unverschlüsselte Aufnahem auf ZDF HD starten. Die Aufnahme bleibt aber bei 0 Bytes hängen (in der Weboberfläche). Im Eventlog sehe ich zwei Tune Failure.

Auf der Platte wird aber gar keine Datei angelegt. Nach manuellem Abbrechen der Aufnahme wird lediglich eine leere Info Datei geschrieben.

Weiter mit dvb.net Viewer: ZDF HD läuft ohne Probleme auf Tuner 2 und Tuner 3. Auf Tuner 4 kommt kein Bild und kein Ton. Diesmal steht aber Tune Success im DD Log. Der Zapping Client zählt auch fleißig die Bytes hoch.

Im Gerätemanager ist kein Fehler zu sehen.

Kannst du dir darauf einen Reim machen ?

Sobald die Aufnahme auf Tuner 1 fewrtig ist werde ich mal eine Reset auf das gemeinsame Tunerdevice machen und mich dann wieder melden.

Noch eine weitere Auffälligkeit: es laufen gerade mehre überlappende Aufnahme auf einem Tuner. Die einzelnen Files werden wie erwartet erzeugt. Ich sehe aber keinerlei epginfo Dateien. Wird erst am Schluss eine gemeinsame Datei geschrieben oder sollte es zu jeder einzelnen Aufnahem eine Info Datei geben ? Nach Ende der Aufnahmen werde ich das nochmal prüfen.

Helmuth

Guten Morgen lieber Tester :-)

zuerst zum einfachen: ja, die EPGINFO Dateien werden erst am Ende erstellt, wenn die Karte freigegeben wird. Ich habe zweimal darüber nachgedacht, dass zu verändern, aber es ist aufwändiger als es scheint. Daher auf 4.1 verschoben. Das gilt übrigens auch für meinen MP Extraktor, der würde auch erst loslaufen, wenn alle Aufzeichnungen auf der Karte beendet sind und dann die Audiospuren extrahieren.

Zu dem Tuner 4 kann ich mir leider keinen Reim machen. Hat der irgendwas mit Tuner 1 in der Konfiguration gemeinsam, etwa CI? Oder ist theorteisch (sorry, dass ich frage) auch eine Fehlkonfiguration der Caüture Gerätes möglich? Ich kann so etwas ja nie testen, darum bin ich unsicher was den Betrieb von Multi-Tuner Karten angeht - vielleicht ist da ja ein Bug im DVB.NET und es findet nicht immer zu einem Tuner den richtigen Capture oder so. Du kann mir zur Kontrolle ja mal die vier DNP Geräteprofile ZIPpen und schicken.

Jochen

Zu den 4 Tunern und einem shared CI gibt es im Gerätemanager ein Base Device, ein Capture Device, ein CI Device und ein Tuner Device. Deshalb helfen die Wakeup Devices bei den Profilen nicht, denn die würden auf alle 4 Tuner Auswirkungen haben. Ich habe mir deshalb ja ein paar Skripte gebastelt die genau einmal nach dem Aufwachen ein CI Reset machen. Vielleicht sollte ich da noch die anderen DD Geräte auch resetten.

Das Problem mit Tuner 4 ist irgendwas temporäres. Ich habe damit bereits erfolgreiche Aufnahmen gemacht und seitdem nichts mehr an der Konfiguration geändert.

Die Profile kommen gleich per Mail.

Helmuth

Also die Profile sehen alle sehr gut aus, komisch. Wenn man das reproduzieren könnte, könnte ich mal überlegen, welche Art von Protokoll man aktivieren kann - gilt dann aber leider für alle Karten gemeinsam, da muss man dann etwas tricksen (e.g. nur auf dem DVB.NET Viewer aktivieren). Ich denke an so etwas wie das im BLog hier und vor allem hier beschriebene. Vielleicht kann man sogar wie im Beispiel das Admin Tool benutzen, aber der Viewer ist i.A. unanfälliger gegen Probleme, da man den nicht mehrfach starten oder das Gerät im Betrieb welchseln kann - ich gehe von einem Aufruf des Viewers im lokalen und nicht VCR.NET Betrieb aus.

Jochen

Der Effekt lässt sich manchmal wiederholen.

Versuch 1: Pay TV auf Tuner 1 und Free TV 1 Minute später auf Tuner 4. Tuner 4 hängt. Es wird keine Datei erzeugt. Erst nach dem Reset des Tunerdevices geht Tuner 4 wieder.

Versuch 2-4: andere Kombinationen von Tunern. Die 4 Tuner sind nicht exakt gleich, sondern 2 Tuner sind aus einer älteren Serie. Alles hängt an einer gemeinsamen Karte an der auch das CI hängt. Keine Probleme.

Nochmal 2x Versuch 1: Diesmal keine Probleme.

Wie kann man so was sinnvoll debuggen ?

Helmuth

Wird sehr schwer. Das Logging kann man leider nicht grundsätzlich für den VCR.NET einschalten (wäre die CONFIG des DVB.NET Card Servers), da alles in die selbe Logdatei geht (glaube ich? hm...). Aber: wenn der Fehler auch mit dem Viewer / Admin also bei lokalem Zugriff auf die Hardware auftritt, während Tuner 1 in Benutzung ist, könnte man wie im vorherigen Post angedeutet das BDA (und die anderen) Logging anschalten.

Jochen