Aktualisierung der Aufnahmezeit

[Lupissimo]

Da es mich wegen der Japan Berichterstattung wieder erwischt hat( ca. 35min Verschiebung der Sendungen), habe ich die Frage:

 

Gibt es eine möglichkeit die Aufnahmezeiten über den sich ändernden EPG automatisch anzupassen? Früher gab es VPS, das diese Funktion bei Videorecordern erfüllte.

 

Vielleicht könnte man z.B. 30 min vor dem programmierten Aufnahmestart eine Aktualisierung vornehmen.

 

Lupsiimo

[desweil]

das geht dann aber auch nur, wenn der Sender tatsächlich das EPG korrekt aktualisiert. Und das ist eher selten der Fall. Solche extreme wie jetzt wegen Japan sind ja nun auch nicht alltäglich.

[Lupissimo]

Gestern haben sie aktualisiert. Jedenfalls hab ich es in der Leiste im Bild gesehen, als die Sendung noch (verzögert) lief.

[desweil]

ja, manchmal ja. Manchmal nein. Dann gibt es noch User (wie ich z. B.) die EPG von externen Quellen importieren. Dieser EPG ist dann deutlich umfangreicher, aber wird dann natürlich nicht so schnell aktualisiert. Dann gibt es noch Fälle, wo auch 30 min. vorher noch nicht klar wäre wie groß die Verzögerung ist usw.

 

Ein recht komplexes Thema, für das es keine zufreidenstellende, allgemeine Lösung gibt. Wenn man dazu bedenkt, wie selten sowas vorkommt ist es wohl nicht so sinnvoll in diese Thematik viel Entwicklungszeit zu investieren.

[Lupissimo]

Komisch, dass sofort immer nur Killerargumente gebracht werden. - Wenn die Funktionalität nur bei Standard EPG möglich ist, dann liegt es im Ermessen des Benutzers, welche Prioritäten er setzt: Fremder EPG oder Aufnahmekontrolle. Ausserdem geht es beim Recording Service zunächst um Aufnahmen und nicht um Inhaltsangaben. Vielleicht sollte doch erstmal einer der Fachleute, die sich mit der Problematik auskennen, dazu etwas sagen.

[desweil]

Das Problem ist, man Programmiert immer nur einen Timer mit Sender und Start- Endzeit. Das wird zwar über eine EPG Anzeige erleichtert, es ist aber NICHT so, dass im Timer ein EPG Eintrag (eine Sendung) steht, der aufgenommen wird, sondern mit dem EPG wird nur das ausfüllen des Timers mit den gewünschten Zeiten erleichtert. Das bedeutet, der DVBViewer/Recording Service weiß gar nicht, welche Sendung(!) man aufnehmen will, sondern nur Sender, start/endzeit. Darum kann man das auch nicht einfach so programmieren, dass er dann guckt, ob die gewünschte SENDUNG sich verschoben hat. Man kann ja z.B. auch timer setzen, die zwei Sendungen am Stück aufnehmen. Oder 2 1/2 oder so. Und was ist wenn sich ein Timer sich dann tatsächlich ändern muss, weil eine Sendung verschoben ist, DANN aber eine anderer Timer z.B. nicht mehr aufgenommen werden kann weil es sich dann auf einmal überschneidet. Was dann? Und wie soll eine Aufnahme 30min vorher gucken ob sie sich geändert hat, wenn der PC erst für die Aufnahme geweckt wird? EInfahc immer min. 30minuten vorher wekcen? Du siehst, das hat vielfältige Auswirkungen.

 

Weil es eben NICHT wirklich gut geht, Sendungen SICHER aufgrund des EPGs aufzunehmen gibt es ja gerade die Vor- und Nachlaufzeiten!

Edited March 15, 2011 by desweil

[MaxB]

@Lupissimo:

Erkläre mir doch mal bitte wie "VPS" funktionert und vor allem, welche Sendeanstalten VPS verwenden. Du wirst relativ schnell herausfinden, das VPS nie bei den privaten (sat.1, Pro7, RTL & Co) verwendet wurde, da diese werbefinazierten Sendeanstalten kein Interesse daran haben, dass man vollständige Aufnahmen erhält... Die Steigerung des Ganzen bei DVB ist CI+, wodurch diese privaten Sendeanstalten die Aufnahme sogar ganz verbieten können...

 

Ähnlich wie bei VPS verhält es sich beim EPG! Zumindest ARD & ZDF versuchen(!) bei Sendungsverschiebungen das "Present"-Event solange onAir zu lassen, wie die Sendung andauert, ohne dabei die Uhrzeiten des EPG anzupassen. Hier mal eine kleine Kritik am DVBViewer: Leider bekommt man diese Verzögerung des "Present-Events" beim DVBViewer nicht angezeigt!

Mein alter Humax PDR9700 Festplattenreceiver hatte dieses "Verzögerungsverfahren" des "Present" EPG-Events mit irgendeiner alten SW mal bei den Timeraufnahmen angewendet und eben nur nach dem EPG-Event aufgenommen => Selbst wenn man sich manuell eine Vor-und Nachlaufzeit programmiert hatte, wurde die Aufnahme automatisch in 3 Teile zerlegt, egal ob der EPG korrekt war oder nicht.

Da die Kunden aber nicht nur von ARD & ZDF aufnehmen möchten musste auch Humax aufgrund von massiven Kundenbeschwerden seine Software anpassen, da man bei den privaten nie das komplette Event in einem Stück auf der HDD hatte.

 

=> Sollte der Rec.-Service extra für Dich angepasst werden, weil Du z.B. nur von den ARD & ZDF aufnehmen möchtest, schauen alle anderen in die Röhre, die auch von anderen Sendeanstalten aufnehmen möchten, ich denke mal, das ist eindeutig die Mehrheit!

Du selbst hast doch aber durchaus die Möglichkeit Dir selbst die Vor-& Nachlaufzeit jeder Timeraufnahme so zu programmieren, dass Du ggf. auch 60/90/120 Minuten Nachlaufzeit eintragen kannst!

 

Wenn Du Deine Aufnahmen archivieren möchtest musst Du eh das Aufnahmefile zurechtschneiden, dabei sollte es egal sein, ob Du nur 5 Minuten am Ende wegschneiden musst oder ggf. 120 Minuten... Es gibt sogar ein Plugin, welches die Aufnahmen nachträglich automatisch schneiden können soll, welches ich aber bisher noch nie benutzt habe, da ich kaum archiviere.

Sollte mal eine Sendung ganz ausfallen, da die aktuelle Nachrichtenlage/Berichterstattung dies erforderte hatte man bei VPS auch nur die kurze Aufnahme mit der durchlaufenden Einblendung auf Band, dass die Sendung ausfällt. Bei VPS wurde genau für diese Einblendung der Timecode der programmierten Aufnahme gesendet und wieder abgeschaltet. Bei DVB gibt es auch bei ARD & ZDF nix vergleichbares vielleicht weil es zuwenig Geräte mit EPG-"Present"-Event-Aufnahme am Markt gibt?

[Derrick]

Bei den ÖRs gibt es noch PDC. Wird aber nicht ausgewertet..

[MaxB]

@Derrick: Was ist PDC?

 

Edit:

OK, gefunden und bei ARD in der EIT gefunden

Edited March 15, 2011 by MaxB

[Griga]

Den PDC-Descriptor (Program Delivery Control, digitale VPS-Variante) habe ich vor einiger Zeit experimentell im DVBViewer GE erfasst, zwecks korrekter Anzeige der verstrichenen bzw. Restlaufzeit von (eventuell verschobenen) Sendungen in der Statusleiste.

 

Was jedoch an PDC-Daten eintraf, war wiederholt bei einzelnen Sendern / Sendungen so katastrophal falsch, dass ich den Versuch schnell wieder aufgegeben habe. Offenbar mangelte es bei den Sendern an der nötigen Sorgfalt und Zuverlässigkeit. Der Code ist jedoch noch da, und ich kann ihn jederzeit per Conditional Define aktivieren.

[Lupissimo]

Vielen Dank für die vielen Antworten! Es ist prima, dass es hier eine technisch konstruktive Diskussion gibt.

Ich verstehe natürlich die ganzen Argumente, dass es keine allgemeingültige Lösung gibt. Auch VPS gabs nicht für die Privaten (die mich aber sowieso nicht interessieren).

 

Aber vielleicht könnte Griga ja - wie er schreibt - sein Angebot wahr machen und eine Recordservice Version mit einer PDC Option (aktivierbar) anbieten. Ich würde sie sehr gerne testen.

 

Da meine SatKarte in einem Server im Keller steckt und ich sie nur zum Aufnehmen benutze, überprüfe ich die Zeiten nicht regelmäßig und eine generelle Nachlaufzeit von >30min führt bei eingehaltenen Sendezeiten immer zu viel Datenmüll, besonders bei HD Aufnahmen.

 

Lupissimo

[Griga]

Aber vielleicht könnte Griga ja - wie er schreibt - sein Angebot wahr machen und eine Recordservice Version mit einer PDC Option (aktivierbar) anbieten.

Kann er nicht, da der RS unter der Regie von Lars steht. Ich habe den Code noch nie gesehen und kenne mich damit nicht aus.

 

Was ich machen kann: Im DVBViewer GE als Testumgebung die PDC-Erfassung aktivieren, die Auswirkungen auf EPG-abhängige Anzeigen beobachten und meine Schlüsse daraus ziehen. Oder eine entsprechende Testversion zur Verfügung stellen.

 

Die Nutzung für Timeraufnahmen ist jedoch eine ganz andere Geschichte. Klar sollte sein, dass die PDC-Informationen nur empfangen werden / Wirkung zeigen, solange der DVBViewer/RS einen Transponder empfängt, auf dem sie übertragen werden. Das ist nicht der Fall, wenn sich der PC im Standby befindet, der DVBViewer nicht läuft oder kein bzw. ein anderer Transponder getuned ist.

 

Eventuelle Nebenwirkungen auf nachfolgende programmierte Aufnahmen wurden bereits erwähnt. Das kann nämlich auch nach hinten losgehen: Wenn eine aufgrund von PDC-Daten automatisch verschobene Aufnahme einen Tuner zu einer ursprünglich nicht vorgesehenen Zeit blockiert, findet eventuell eine andere (vielleicht wichtigere) Aufnahme nicht oder nur unvollständig statt.

 

VPS war ursprünglich für einen VHS-Videorecorder mit einem einzigen (auch im Standby lauschenden) Analog-Tuner konzipiert, der nur wenige öffentliche-rechtliche Sender empfangen konnte, und immer nur einen gleichzeitig. Der Empfang mit DVB-Karten im PC schafft ganz anderen Voraussetzungen, auf die sich das VPS-Konzept nicht einfach übertragen lässt. Eine saubere Realisierung würde einen rund um die Uhr laufenden PC mit einer allein für den EPG/PDC-Empfang reservierten DVB-Karte erfordern, plus einen Recording Service-Mechanismus, der im Hintergrund mit diesem Tuner ständig alle relevanten Transponder scannt. Ansonsten sind X Szenarios denkbar, in denen es nicht funktioniert, was dann hier mangels technischem Sachverstand als "Bug" gepostet wird und den Support beschäftigt hält.

[Derrick]

Klar sollte sein, dass die PDC-Informationen nur empfangen werden / Wirkung zeigen, solange der DVBViewer/RS einen Transponder empfängt, auf dem sie übertragen werden. Das ist nicht der Fall, wenn sich der PC im Standby befindet, der DVBViewer nicht läuft oder kein bzw. ein anderer Transponder getuned ist.

 

Eventuelle Nebenwirkungen auf nachfolgende programmierte Aufnahmen wurden bereits erwähnt. Das kann nämlich auch nach hinten losgehen: Wenn eine aufgrund von PDC-Daten automatisch verschobene Aufnahme einen Tuner zu einer ursprünglich nicht vorgesehenen Zeit blockiert, findet eventuell eine andere (vielleicht wichtigere) Aufnahme nicht oder nur unvollständig statt.

 

Es sollte sich natürlich um eine zuschaltbare option handeln. Zu früh wird kaum begonnen. Wenn der rechner aus dem standby erwacht, kann die EIT-überwachung starten. Wer angst hat, das ende einer wichtigen aufnahme zu verpassen, muss den nachlauf jetzt auch entsprechend verlängern

[Griga]

Es sollte sich natürlich um eine zuschaltbare option handeln.

Eine Option, bei der unsicher ist, inwieweit sie in verschiedenen Szenarios funktioniert und welche Folgen sie hat, werde ich nicht implementieren.

 

Der erste Schritt wäre die nicht so kritische Verwendung der PDC-Daten für EPG-basierte Informationen im UI. Erst auf Basis der dadurch gewonnenen Erkenntnisse könnte man über eine Auto-Korrektur von Aufnahmezeiten nachdenken. Meine bisherigen Ergebnisse waren wie gesagt nicht gerade ermutigend. Aber ich werde darauf zurückkommen und eventuell eine entsprechende Version für Betatester bereitstellen, wenn ich dazu Zeit finde.

[Derrick]

Eine Option, bei der unsicher ist, inwieweit sie in verschiedenen Szenarios funktioniert und welche Folgen sie hat, werde ich nicht implementieren.

..bevor das hier zur grundsatzdiskussion ausartet, klinke ich mich lieber aus. Mir ist dieses feature sowieso ziemlich egal. Trotzdem noch eine bemerkung. Manchmal hat es den anschein, als würden devs den über jahrzehnte entwickelten bedienungskomfort von videorecordern oder dvd/hd-recordern nicht kennen oder bewusst ignorieren. VPS bzw. PDC ist immer eine zuschaltbare option. Hier von einem seit jahren problemlos laufenden Panasonic HD-recorder

[Lupissimo]

...... Eine saubere Realisierung würde einen rund um die Uhr laufenden PC mit einer allein für den EPG/PDC-Empfang reservierten DVB-Karte erfordern, plus einen Recording Service-Mechanismus, der im Hintergrund mit diesem Tuner ständig alle relevanten Transponder scannt.

 

Genau diese Situation ist bei mir gegeben. Der Sever mit der Sat Karte läuft 24/7 im Hintergrund und dient praktisch nur zum Aufnehmen. Wegen der Überlappungs-Gefahr könnte man über eine Priorisierung nachdenken, die bei der EPG- Programmierung vom Benutzer vergeben wird, so dass ggf. die Aufnahme abgebrochen bzw der Start der nächsten verschoben wird. Im Prinzip muss die Problematik bereits zu VPS-Zeiten vorhanden gewesen sein und hat damals sicher zu einem Kompromiss geführt, der letztlich immer noch besser war als die"normale" Zeitprogrammierung.

Edited March 16, 2011 by Lupissimo

[MaxB]

Ich klinke mich hier jetzt auch mal komplett aus und möchte Lupissimo zu dem Kauf eines Festplattenreceivers mit VPS/PDC raten. Der Festplattenreceiver ist auch viel Energiesparender als ein 24/7 laufender Server mit einer TV-Karte...

 

Das Thema wird in meinen Augen nicht händelbar sein, da die Wunschliste mit "Priorisierung", "24 Stunden Dauerscan aller Services(!)", evtl. als nächstes noch die "automatische PDC-Erkennung der Sendeanstalten in der Senderliste" usw. garantiert endlos lang werden wird.

Ebenso stimme ich Griga voll zu, dass es garantiert bei jeder falsch signalisierten Aufnahme zu Supportanfragen kommen wird und man dann am Besten auch noch die PDC-Daten mit in das Aufnahmelogfile schreibt, um zu beweisen, dass es beim Programmanbieter lag.

[Lupissimo]

@MaxB: Ein hervorragender Vorschlag: Ich soll zu dem aus ganz anderen Gründen 24/7 laufenden Server noch einen extra Videorecorder laufen lassen!

 

Ausserdem nehme ich an, dass es bei allen Hersteller von Festplatten PDC-Receivern "garantiert bei jeder falsch signalisierten Aufnahme zu Supportanfragen kommen wird und man dann am Besten auch noch die PDC-Daten mit in das Aufnahmelogfile schreibt, um zu beweisen, dass es beim Programmanbieter lag"

 

@MaxB Ende

 

Anscheinend haben einige Festplatten Receiver das Problem zumindest soweit gelöst, dass es von Kunden akzeptiert wird. Da man bei der PC Software nicht mit den Firmware Limitationen der Receiver kämpfen muss, sollte es an und für sich keinen technischen Grund geben, so ein PDC System nicht zu realisieren. Sicher ist es ein "Nice-to-have" Feature, aber Wünsche kann man doch noch äußern, hoffe ich.

[Griga]

Manchmal hat es den anschein, als würden devs den über jahrzehnte entwickelten bedienungskomfort von videorecordern oder dvd/hd-recordern nicht kennen oder bewusst ignorieren.

Manchmal hat es den Anschein, als würden Anwender den Unterschied zwischen Videorekordern oder DVD-Rekordern und dem DVBViewer nicht kennen oder bewusst ignorieren.

 

Genau diese Situation ist bei mir gegeben.

Deine spezielle Situation ist irrelevant. Wenn es eine solche Option geben soll, muss sie allgemein von Nutzen sein und funktionieren. Ich könnte sowas natürlich auch auf deinen Bedarf zugeschnitten entwickeln. Ab einem Angebot von 50,- Euro die Stunde können wir darüber reden. Rechne mit einer vierstelligen Summe.

[Lupissimo]

@Griga: Ursprünglich hatte ich das Posting im RecordingService Unterforum gestartet. Und alle meine Aussagen beziehen sich nur auf den RecordingService und nicht auf den DVBViewer.

[Griga]

alle meine Aussagen beziehen sich nur auf den RecordingService und nicht auf den DVBViewer.

Die programmtechnischen Probleme sind identisch, abgesehen von der Tatsache, dass der RS immer läuft, wenn Windows läuft, was man beim DVBViewer nicht voraussetzen kann.

 

Allein schon eine Aufnahme exakt zur PDC-Zeit zu starten ist so nicht machbar. Die Systemuhr könnte 30 Sekunden nachgehen. Die Zeit für die Initialisierung des Geräts und eine eventuelle Senderumschaltung ist unbekannt. Wenn eine Schüssel mit Motor im Spiel ist, kann es länger dauern, bis die Position angefahren ist und Daten kommen. Auch mit PDC bräuchte es eine Vorlaufzeit, damit der Anfang des Films nicht abgeschnitten wird.

 

Und was ist, wenn der Anwender eine Vorlaufzeit von X Minuten vorgesehen hat? Der Recorder weiß das nicht, da er nur die programmierte Anfangszeit kennt. Zum programmierten Aufnahmebeginn schaltet er den betreffenden Sender/Transponder ein und muss zwangsläufig sofort die Aufnahme starten, weil er nicht in die Zukunft schauen kann. Ca. 20 Sekunden später treffen relevante PDC-Daten aus der EIT ein. Der Recorder stellt fest, dass die Sendung X Minuten nach der programmierten Startzeit beginnt. Was soll er nun machen? Die Aufnahme läuft bereits... sowas lässt sich nur mit einer ständigen PDC-Überwachung und ständigen Belegung eines Tuners verhindern, siehe oben.

 

Und eine weitere interessante programmtechnische Frage: Wie soll der Recorder PDC-Informationen programmierten Aufnahmen zuordnen? Was ist, wenn eine Aufnahme von zwei aufeinanderfolgenden Sendungen in einer Datei programmiert wurde? Und so weiter...

[Lupissimo]

Ich frage mich nur, wie die PDC-DVD Recorder das alles gelöst haben?? !!

 

Annahme: Wenn es Veränderungen im Zeitplan gibt, sind es Verschiebungen nach hinten.

 

=>Zur ursprünglich programmierten (EPG)-Zeit (ggf.+ Vorlauf), wird der Empfänger auf den Kanal geschaltet und wartet auf die richtige PDC-Information,dann

=>Recording-Start

=>Laufzeit=EPG-Laufzeit (ggf.+Nachlauf)

[Dadurch lassen sich auch aufeinanderfolgende Sendungen auf demselben Kanal aufnehmen. Kanalwechsel mit zeitlich kurz (< Nachlaufzeit)aufeinanderfolgenden Sendungen gehen auch heute nicht. Natürlich wird es Fälle geben in denen durch die Verschiebung der Startzeit einer neuen Aufnahme überschritten wird. Die fällt dann eben aus.]

 

Zur Annahme: Bisher hab ich nur den Verschiebung-nach-Hinten-Fall gehabt. Damit ist sehr wahrscheinlich der größte Teil abgedeckt.

 

Lupissimo

Edited March 16, 2011 by Lupissimo

[Lars_MQ]

Was mir neulich wieder mal durch den kopf ging, nachdem die ARD (ebenso) wiedermal hemmungslos überzogen hat und meine aufnahme trotz 10 minuten nachlaufzeit mitten im Film zuende war (das ist auch nicht das erste mal passiert):

 

- Der Timer wird über das EPG programmiert. Dabei "merkt" sich der Timer die SendungsID (wird vom Sender vorgegeben).

- Der Timer startet IMMER zu der programmierten Zeit. Mit 5 minuten Vorlauf sollte man hinkommen.

- Der Timer wird über änderungen der EIT mit der ID "TABLE_ID_EIT_ACTUAL_PRESENT" für seine EPGChannelID informiert und schaut rein, ob der Eintrag seiner SendungsID entspricht.

- Wenn ja, dann überprüft er ob es Änderungen der Sendungsdauer gegeben hat. Wenn ja und die Dauer + Startzeit des EIT eintrags hinter der Endzeit des Timers liegt, dann wird der Timer einfach verlängert. Niemals gekürzt nur verlängert.

 

Das ganze hat natürlich einige Knackpunkte: Es funktioniert nicht bei wiederholenden Timern, nur mit über EPG programmierten Timern und nicht mit externem EPG.

Der Sender muss den TABLE_ID_EIT_ACTUAL_PRESENT table sauber pflegen und senden. Die Sendung darf sich nicht über die timerdauer hinaus verschieben. Oh und natürlich darf die Sendung nicht ausfallen, aber damit wäre der Timer hinfällig und das aufgenommene kann man direkt entsorgen.

Und sicherlich hab ich noch die eine oder andere Kleinigkeit übersehen, die mir griga um die Ohren hauen wird

 

Mein Ziel ist eben nicht eine punktgenaue (VPS) Aufnahme einer sendung zu ermöglichen, sondern eine möglichst komplette Aufnahme sicher zu stellen.

Eine Aufnahme, bei der die letzen minuten fehlen, ist einfach eine ruinierte aufnahme, man erfährt dann nie, wer der mörder war.

Die halbe stunde "überschuss" als Vorlauf, schnippel ich mit Grigas TSPlayer im handumdrehen weg.

[Griga]

Dabei "merkt" sich der Timer die SendungsID (wird vom Sender vorgegeben).

Das wird dann bei den Schweizer ÖRs lustig, die die Event ID bei jedem EPG-Update (also täglich) neu zuordnen Die Event ID einer Sendung hat dann am nächsten Tag eine andere Sendung... ich weiß nicht, ob sie immer noch diesen Unfug betreiben. Per Mail haben sie ja Besserung versprochen, aber der Austausch / die Neuprogrammierung der Sendetechnik könne ein paar Monate dauern, hieß es.

[Lars_MQ]

Gut dann müssen die Schweizer darauf verzichten. Das schlimmste was in diesem fall passieren könnte, ist, dass die aufnahme zu lange läuft...

 

Ich habe auch schon einige experimente mit dem running status (starts in a few moments oder sowas) hinter mir.

Die ÖR in deutschland machen das auch so einigermaßen richtig, aber auf sowas würde ich mich nicht verlassen, zumal die privaten das komplett ignorieren.

Aber die Current Next informationen des EIT geben die meisten richtig raus, das ist nämlich genau das, was die settop boxen als aktuelle sendungsinformationen anzeigen...

[Griga]

Lars, ich fürchte, eine Laufzeitverlängerung ist zur Zeit alles andere als populär. Frage Frau Merkel... damit du dich nicht wunderst, wenn du als DVBViewer-Entwickler abgewählt wirst und Lupissimo oder ein anderer Grünling deinen Platz einnimmt.

 

Noch mal zum PDC Descriptor. Im Web findet man u.a.:

 

Im digitalen Fernsehen ist das analoge VPS-Signal nicht anwendbar. Deshalb wurde von der ARD ein VPS-ähnliches digitales Signal entwickelt, welches über Satellit, Kabel und DVB-T bereits verbreitet wird. Die Spezifikation für das digitale Fernsehen sieht vor, dieses Signal (PDC-Descriptor) in Form von Zusatzdaten über die DVB-Serviceinformationen (SI-Daten) zu senden.

 

Quelle: http://www.ard-digital.de/ARD-Digital/FAQ/Digitales-Fernsehen/Digitales-Fernsehen#Wird%20ein%20digitales%20VPS-Signal%20ausgestrahlt%3F

 

Die naheliegende Annahme, dass der PDC Descriptor mit seiner Datum/Uhrzeit-Angabe den Aufnahmestart signalisiert, also die tatsächliche Anfangszeit angibt, kommt allerdings ins Wanken, wenn man die Spezifikationen genauer studiert:

 

The descriptor carries the Programme Identification Label (PIL) as defined in EN 300 231

besagt ETSI EN 300 468, und in ETSI EN 300 231 findet man

 

The PIL parameter normally carries the local announced broadcast time (day, month, hour, minute) identifying the transmitted programme.

was soviel heißt wie: Eine Sendung soll anhand dieser Uhrzeit identifiziert werden, sofern sie genau mit dieser Uhrzeit als Aufnahme programmiert ist. Damit war ich mit meinen Experiment im DVBViewer GE erst mal auf dem Holzweg. Wikipedia führt aus:

 

anhand des Labels erkennt der Receiver jedoch, dass es dieselbe Sendung ist und fängt später mit der Aufnahme an. Die Aufnahme dauert, solange der EPG der aktuell laufende (current running) ist.

...womit wir ungefähr bei dem wären, worüber Lars nachdenkt, nur dass er Sendungen anders (schweiz- und serienfeindlich ) identifizieren will und nichts von Spätstartern hält. Ein Ansatz, der mit Einschränkungen praktikabel sein könnte.

 

@Lars: Wie identifiziert der aktuelle DVBViewer Pro, was "jetzt" läuft (z.B. für die Anzeige im Mini-EPG)? Anhand der Systemzeit & EPG-Startzeit oder des Running Status? Ich kann mich erinnern, dass es früher der Running Status war, später dann die Systemzeit, weil sich der Running Status aufgrund von sündigen Sendern als zu wackelig erwiesen hatte. Im DVBViewer GE bin ich letztes Jahr zum Running Status zurückgekehrt, und nach mir die Sintflut...

[Lars_MQ]

@Lars: Wie identifiziert der aktuelle DVBViewer Pro, was "jetzt" läuft (z.B. für die Anzeige im Mini-EPG)? Anhand der Systemzeit & EPG-Startzeit oder des Running Status?

Anhand der systemzeit + epg startzeit. Der running status ist nicht zuverlässig genug und es würde nicht mit dem ganzen "externen" EPG funktionieren.

[Lupissimo]

@Griga: Schade, dass es jetzt ins Persönliche abgleitet: "Frage Frau Merkel... damit du dich nicht wunderst, wenn du als DVBViewer-Entwickler abgewählt wirst und Lupissimo oder ein anderer Grünling deinen Platz einnimmt".

 

Ich habe mit meinem Wunsch nach Lösung dieser "Verschiebe"-Problematik anscheinend eine Schwäche der jetzigen Software artikuliert und als Benutzer versucht zu beschreiben, was ich mir wünsche. Einige der inzwischen 26 Antworten in diesem Topic zeigen, dass ich damit nicht völlig falsch liege.

 

Jedenfalls würde ich mich sehr über eine RecordingService Version freuen, die die Anzahl der zu früh abgebrochenen Aufnahmen verringert, auch wenn man sicher nicht alles abdecken kann.

[Griga]

Schade, dass es jetzt ins Persönliche abgleitet:

Zeigt dein Browser keine Smilies an? Das war ja nun sehr offensichtlich nicht ernst gemeint.

 

Außerdem kannst du doch zufrieden sein. Du hast eine Auseinandersetzung mit dem Thema und eine Diskussion angestoßen, an der zwei Entwickler teilgenommen haben. Es wurde recherchiert, Möglichkeiten und Unmöglichkeiten erwogen... ein solcher Prozess geht einer Realisierung komplexer Funktionen im allgemeinen voraus. Er stellt jedoch keine Garantie dar, dass sie realisiert werden.

 

Ich habe mit meinem Wunsch nach Lösung dieser "Verschiebe"-Problematik anscheinend eine Schwäche der jetzigen Software artikuliert

Vielleicht eine Schwäche aus deiner persönlichen Sicht, aber allgemein nicht. Es gibt auch gute Gründe, so etwas nicht zu machen. Im Web findet sich z.B. die Ansicht, dass PDC/VPS im Zeitalter der Festplattenrecorder nicht mehr zeitgemäß und der Aufwand nicht gerechtfertigt ist. Hat auch etwas für sich. Letzendlich eine Abwägungssache.

 

Anhand der systemzeit + epg startzeit. Der running status ist nicht zuverlässig genug

Meine Erfahrungen damit sind gemischt. Teilweise funktioniert es besser als der Bezug auf die Systemzeit, in einzelnen Fällen aber auch schlechter. Die Auswirkungen auf die angedachte Laufzeitverlängerung von Aufnahmen dürften ähnlich sein. Dein Ansatz, unter diesen Bedingungen eine Aufnahme in keinem Fall (vorne oder hinten) zu kürzen, macht deshalb Sinn.

[Webturtle]

Hallo,

 

mein Grundig DVB-T Empfänger gibt über den AV-Ausgang ein VPS-Signal an einen Videorekorder weiter. Es gibt also auch beim DVB-T technisch eine Möglichkeit, bei Verschiebungen eine pünktliche Aufnahme von Sendungen zu gewährleisten. Vgl. dazu: http://www.ueberallt...pps/VPS-STB.pdf.

 

Übrigens es gab früher mit RTL2 einmal einen Privatsender, der ein VPS-Signal ausgestrahlt hat, allerdings ohne die Werbeunterbrechungen auszusparen.

 

Bei Privatsendern ohne VPS gibt der DVB-T Empfänger einen Status-Code aus, der einen Videorekorder veranlaßt, nach der programmierten Uhrzeit aufzunehmen.

 

Außerdem kann man beim Programmieren wählen, ob mit oder ohne VPS aufgenommen werden soll.

 

 

Viele Grüße

 

Webturtle

[Derrick]

Das ist leider etwas anderes. Der receiver muss den videotext in die austastlücke (VBI) einfügen. Dann funktioniert es so wie gehabt, falls vps/pdc gesendet wird. Sowas kann der DVBViewer von sich aus allerdings nicht bieten.

[Griga]

Auch für DVB-Teletext ist die Möglichkeit spezifiziert, PDC-Daten zu übertragen, und zwar in ETSI EN 300 706 9.8.2 (Enhanced Teletext specification, Packet 8/30 Format 2) und ETSI EN 300 231 8.2.1 (Specification of the Programme Delivery Control system, Recording-control commands).

 

Übertragen werden die Daten in speziellen Teletext-Datenpaketen. Um festzustellen, ob Sender davon Gebrauch machen, müsste man einen fortgeschrittenen Teletext-Analyzer haben...

[Derrick]

..dafür braucht man nur einen receiver mit vbi insertion und einen video- bzw. hd-recorder mit vps/pdc-dekoder. Allerdings über scart und nicht über hdmi verbunden

[huhu22]

ich arbeite fast nur mit Autotimern (insbesondere * Timer für die "Vorratsdatenspeicherung" und optimale Tuner Nutzung) und bei Verschiebungen/Sondersendungen kommt es immer wieder zu Mehrfachaufnahmen, oft auch gestückelt. Mir scheint die EPG Zeiten werden aktualisiert aber dann eine zweite Sendung aufgenommen. Mir würde ein Prozesstimer der vor einer Autosuche alle (nicht Task ) Timer löscht, besser noch natürlich er löscht alle vorhergehenden Autolöschtimer. Eine Aktualiisierung der Timerliste vor Aufnahme-start wäre natürlich das allerbeste. Vielleicht gibt es schon eine Möglichkeit die ich übersehen habe? Mir fällt bsher nur ein die svctimers.xml per Batch durch eine zu ersetzen in welcher nur die Autotimer sind das wäre aber irgendwie unsympathisch falls es praktisch überhaupt geht.

Werde mal schauen ob sich das bessert wenn ich keine zusätzlichen EPG Dienste nutze, danke für den Hinweis.