Vor-/Nachlaufzeit wird manchmal nicht berücksichtigt?

March 21, 2016

Hallo,

ich habe hier manchmal ein merkwürdiges Verhalten, das ich mir nicht erklären kann. Es trat bisher nur bei ZDF info (Kabel) und ZDF info HD (Sat) auf.

Hier z.B. eine Logdatei:

[General]

Version=1.1

[Media]

Created=21.03.2016 04:10:00

Channel=ZDFinfo HD (deu)

[0]

Id=11814

Date=21.03.2016

Time=04:15:00

Duration=00:40:00

Title=Tatort Autobahn

Info=Raser und Drängler im Visier

Series=

Charset=255

Content=128

MinimumAge=0

TimerID={DA996804-7271-4E13-976F-4C68D226BD48}

[stats]

Errors=0

Size=4,68 GB (5024706080 bytes)

Avr. Datarate=1,775 MB/s

Device=Digital Devices DVB-S/S2 Tuner 3 (1)

Die Sendung hat eine Länge von 40 Minuten, die Videodatei hat aber nur genau 44:59 Minuten. Die eigentliche Sendung fängt bei 4:42 an, also ein bisschen zu früh. Der eingestellte Nachlauf von 10 Minuten wurde aber komplett ignoriert. (Sodass jetzt am Ende ein Stück fehlt.)

Ich hatte das auch schon andersrum, dass der Vorlauf komplett ignoriert wurde und so ein Teil am Anfang gefehlt hat.

Wenn alles funktioniert, haben die Videodateien sonst immer die Länge "Duration + Vorlauf + Nachlauf". Was läuft hier verkehrt?

Edit: Da ich gerade diesen Thread hier sehe: http://www.DVBViewer.tv/forum/topic/57984-rs-ignoriert-einstellungen-zu-vor-und-nachlaufzeit/

Ich programmiere die Aufnahmen immer und ausschließlich über das Webinterface und verwende daher auch immer die gleichen Einstellungen.

Es ist außerdem merkwürdig, dass immer nur Vor- oder Nachlauf ignoriert werden, nicht beide gleichzeitig (zumindest bisher noch nicht).

support.zip

Edited March 21, 2016 by KarlSquell

March 21, 2016

Ich hatte eben noch den Gedanken, dass der Nachlauf eventuell zugunsten einer anderen Sendung/Aufnahme ignoriert wurde, dem ist aber nicht so, die nächste Aufnahme lief erst einige Stunden später. In der Aufnahmeübersicht im Webinterface wird als Zeitpunkt der Sendung korrekt(?) "04:15 - 04:55" angezeigt. Wie man im Log sieht, hat die Aufnahme dank Vorlauf um 4:10 angefangen. Beendet wurde sie allerdings um Punkt 4:55, mit Nachlauf hätte es eigentlich 5:05 sein sollen... Die EPG-Überwachung ist komplett ausgeschaltet.

ZDFinfo HD (deu) 21.03.2016

E:\recording\2016-03-21_04-10-00_ZDFinfo HD (deu)_Tatort Autobahn - Raser und Drängler im Visier.ts

Device: Digital Devices DVB-S/S2 Tuner 3 (1)

EventID: 11814 PDC: 0xA990F

04:10:00 / 00:00:00 (~ 0,00 MB) Start Recording

04:10:01 / 00:00:00 (~ 0,36 MB) PID 6710: H.264 Video, 16:9, 1280x720, 50 fps

04:10:01 / 00:00:00 (~ 0,36 MB) PID 6720: MPEG Audio Stereo, 48 khz, 256 kbps

04:10:01 / 00:00:00 (~ 0,36 MB) PID 6721: MPEG Audio Stereo, 48 khz, 192 kbps

04:10:01 / 00:00:00 (~ 0,36 MB) PID 6722: AC3 Audio Stereo, 48 khz, 448 kbps

04:10:01 / 00:00:00 (~ 0,36 MB) PID 6723: MPEG Audio Stereo, 48 khz, 192 kbps

04:10:02 / 00:00:01 (~ 0,36 MB) Tatort Autobahn not running | EventID: 11814 PDC: 0xA990F

04:10:02 / 00:00:01 (~ 0,36 MB) Geheim, getarnt, gejagt: Erlkönige im Visier running | EventID: 11813 PDC: 0xA98DE

04:14:41 / 00:04:40 (~ 489,15 MB) Tatort Autobahn running | EventID: 11814 PDC: 0xA990F

04:14:41 / 00:04:40 (~ 489,15 MB) Mythos VW-Bus - Wie der "Bulli" die Welt eroberte not running | EventID: 11815 PDC: 0xA9937

04:55:00 / 00:44:59 (~ 4791,93 MB) Stop

Average Data Rate: 1,775 MB/s

Total Size: 4791,9 MB (5024706080 Bytes)

Removed Filler Data: 0,5 MB (0,0%)

Edited March 21, 2016 by KarlSquell

March 22, 2016

Ich programmiere die Aufnahmen immer und ausschließlich über das Webinterface und verwende daher auch immer die gleichen Einstellungen.

Wie genau? Übernimmst du die Vorgaben für den Vor/Nachlauf, oder änderst du die Werte manuell?

Wenn man z.B. als Nachlauf 1o Minuten eintippt, setzt der RS beim Speichern die ungültige Eingabe kommentarlos auf 0. Man merkt es nur, wenn man den Timer danach noch einmal aufruft bzw. editiert. Die Ziffer 0 und der Buchstabe o liegen auf der Tastatur halt verdammt nahe beieinander

Um dem Effekt auf die Spur zu kommen, würde ich in nächster Zeit die erstellten Timer noch mal kontrollieren, d.h. in der Timerliste das auf der rechten Seite der Einträge angezeigte Stift-Symbol anklicken und den Vor/Nachlauf überprüfen.

March 22, 2016

5 Minuten als Vor- und 10 Minuten als Nachlauf sind als Default eingestellt, diese Werte übernehme ich auch immer und ändere sie nicht manuell. Um genau zu sein ändere ich gar nichts an den Einstellungen, auch nicht den Dateinamen, ich klicke auf den roten Button und Speichern (via Sender EPG) oder setze den/mehrere Haken und klicke auf "Aufnahme" (via EPG Suche). Die Eingabe fehlerhafter Werte kann ich also definitiv ausschließen.

Edited March 22, 2016 by KarlSquell

March 23, 2016

Ich habe es mir noch mal im Code angeschaut, aber keinen Anlass gefunden, aus dem sich ohne EPG-Überwachung (!) die Aufnahmedauer ändern könnte, bzw. da wo es passiert, erscheint es auch im Log.

Der RS speichert die Startzeit (Vorlauf einberechnet) sowie die Dauer (Vor und Nachlauf einberechnet, also Brutto-Aufnahmezeit). Danach dienen Vor- und Nachlauf eigentlich nur noch informativen Zwecken, d.h. sie besagen, wieviel von der Dauer Vor- und Nachlauf sind. Das sieht man am besten, wenn man sich im Konfigurationsverzeichnis -> config-Unterordner den Inhalt der Datei svctimers.xml mit einem Texteditor anschaut.

Dort findet man die Angaben Date (= Datum), Start (= Brutto-Startzeit), Dur (= Brutto-Dauer in Minuten), PreEPG und PostEPG (Vor/Nachlauf in Minuten). Setzt man dort bei gestopptem RS PreEPG und PostEPG auf 0 oder entfernt die Angaben (was gleichbedeutend ist), so ändert sich an der Aufnahmedauer überhaupt nichts. Auf den Zeitpunkt, an dem der RS die Aufnahme beendet, haben Vor/Nachlauf intern jedenfalls keinen Einfluss, sondern nur Brutto-Startzeit plus Brutto-Dauer, so wie sie in der svctimers.xml stehen.

Auch die Von...Bis-Angabe in der Timerliste entspricht der Brutto-Aufnahmedauer inklusive Vor- und Nachlauf. Auseinanderklamüsert wird das nur für die Anzeige des Timers, wenn man ihn im Web Interface ediert.

Deshalb ist IMO nicht die entscheidende Frage, warum bei dir Vor/Nachlauf verschwinden, sondern warum sich die Aufnahmedauer ändert. Womöglich sogar erst während der Aufnahme (?). Und warum diese Änderung offenbar gerne mit Vor- oder Nachlauf übereinstimmt.

Wie gesagt stehe ich da noch vor einem Rätsel. Bislang fällt mir dazu nur ein, den RS in der nächsten Version noch mehr loggen zu lassen, um dem Phänomen auf die Spur zu kommen. Und du könntest die genannten Faktoren verstärkt beobachten, um zu sehen, ob sich vielleicht schon vor Aufnahmen Auffälligkeiten zeigen, vielleicht auch im Zusammenhang mit bestimmten anderen Vorgängen oder Gegebenheiten.

Ich programmiere die Aufnahmen immer und ausschließlich über das Webinterface und verwende daher auch immer die gleichen Einstellungen.

Ich kann also davon ausgehen, dass keine Autosuche nach bestimmten Sendungen / Auto-Erzeugung von Timern aktiv ist, und auch keine Timer im DVBViewer nachträglich editiert werden?

March 23, 2016

Die Autosuche benutze ich nicht. Über den DVBViewer habe ich Timer nicht editiert, nein.

Bisher ist das Phänomen auch wie gesagt nur bei ZDF info aufgetreten (Kabel und Sat).

Vielleicht könnte man in das Log noch die geplante Aufnahmedauer schreiben und/oder den Grund für den Abbruch der Aufnahme, sofern es mehr als einen gibt?

Oder vielleicht kann man Änderungen der Aufnahmedauer loggen, ggf. ebenfalls mit Grund?

Ich werde in Zukunft die svctimers.xml sichern, sodass man nachträglich vielleicht noch etwas nachvollziehen kann.

Nur noch eine ganz vage Idee hätte ich: Ich (de)aktiviere manchmal Timer (Button ganz links in der Timer-Liste, NICHT über den "Stift" rechts und dann "Timer aktiv"), es könnte also sein, dass die Timer der entsprechenden Aufnahmen mal deaktiviert waren und ich sie wieder aktiviert habe.

Edited March 23, 2016 by KarlSquell

March 23, 2016

Oder vielleicht kann man Änderungen der Aufnahmedauer loggen, ggf. ebenfalls mit Grund?

Wird bereits gemacht, das ist ja das Merkwürdige Ob es noch eine versteckte Möglichkeit gibt, die man nicht sofort sieht? Der diesbezügliche RS Code ist nicht gerade trivial, wie du dir vorstellen kannst. Ich habe das Programm ja nicht geschrieben, sondern nur die Pflege übernommen, als der vorherige Autor verstorben ist. Von daher kann es natürlich sein, dass ich etwas übersehe.

Bisher ist das Phänomen auch wie gesagt nur bei ZDF info aufgetreten (Kabel und Sat).

:iiam: Vielleicht mal einen Parapsychologen zu Rate ziehen?

March 23, 2016

Mail an Galileo Mystery ist raus...

April 3, 2016

Es ist schon wieder passiert. Die Aufnahme hat eine Länge von 44:59, dabei sollten es 50 Minuten sein.

[General]

Version=1.1

[Media]

Created=30.03.2016 12:10:00

Channel=ZDFinfo HD (deu)

[0]

Id=14559

Date=30.03.2016

Time=12:10:00

Duration=00:35:00

Title=ZDF.reportage

Info=Willkommen in der Realität - Deutschland und die Flüchtlinge

Series=

Description=Reportage, Deutschland 2016|Die Idee war gut gemeint. Der Plan nicht durchdacht. Die unbegrenzte Aufnahme von Flüchtlingen bringt Politik und Gesellschaft an Grenzen.|Enttäuschung, Überforderung und Frust gibt es bei allen - Flüchtlingen, Helfern und Politikern. Den Start ins bessere Leben hatten sich die Flüchtlinge anders vorgestellt. Die Erstaufnahmeeinrichtungen scheinen Sackgassen. Helfer sind überlastet.|HD-Produktion|[16:9] [H.264] [HD]|[stereo] [deu]|[stereo] [mul]|[stereo] [mis]|[Dolby Digital 2.0] [deu]|[DVB subtitles] [deu]|PDC: 30.03. 12:10 (989962)

Charset=255

Content=128

MinimumAge=0

TimerID={C477F659-59C5-4D42-9358-B255B0F9FFA4}

[stats]

Errors=0

Size=4,45 GB (4779464028 bytes)

Avr. Datarate=1,688 MB/s

Device=Digital Devices DVB-S/S2 Tuner 3 (1)

ZDFinfo HD (deu) 30.03.2016

E:\recording\2016-03-30_12-10-00_ZDFinfo HD (deu)_ZDF.reportage - Willkommen in der Realität - Deutschland und die F.ts

Device: Digital Devices DVB-S/S2 Tuner 3 (1)

EventID: 14559 PDC: 0xF1B0F

12:10:00 / 00:00:00 (~ 0,00 MB) Start Recording

12:10:01 / 00:00:00 (~ 0,21 MB) ZDF.reportage not running | EventID: 14559 PDC: 0xF1B0A

12:10:02 / 00:00:01 (~ 2,12 MB) PID 6710: H.264 Video, 16:9, 1280x720, 50 fps

12:10:02 / 00:00:01 (~ 2,12 MB) PID 6720: MPEG Audio Stereo, 48 khz, 256 kbps

12:10:02 / 00:00:01 (~ 2,12 MB) PID 6721: MPEG Audio Stereo, 48 khz, 192 kbps

12:10:02 / 00:00:01 (~ 2,12 MB) PID 6722: AC3 Audio Stereo, 48 khz, 448 kbps

12:10:02 / 00:00:01 (~ 2,12 MB) PID 6723: MPEG Audio Stereo, 48 khz, 192 kbps

12:10:03 / 00:00:02 (~ 2,12 MB) ZDFzoom running | EventID: 14558 PDC: 0xF1AE8

12:10:12 / 00:00:11 (~ 18,85 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:10:12 / 00:00:11 (~ 18,85 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:28:32 / 00:18:31 (~ 1967,14 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:28:32 / 00:18:31 (~ 1967,14 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:28:44 / 00:18:43 (~ 1989,05 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:28:44 / 00:18:43 (~ 1989,05 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:28:58 / 00:18:57 (~ 2015,10 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:28:58 / 00:18:57 (~ 2015,10 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:29:13 / 00:19:12 (~ 2040,31 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:29:13 / 00:19:12 (~ 2040,31 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:29:27 / 00:19:26 (~ 2066,17 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:29:27 / 00:19:26 (~ 2066,17 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:29:42 / 00:19:41 (~ 2093,77 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:29:42 / 00:19:41 (~ 2093,77 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:29:57 / 00:19:56 (~ 2121,19 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:29:57 / 00:19:56 (~ 2121,19 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:30:11 / 00:20:10 (~ 2146,52 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:30:11 / 00:20:10 (~ 2146,52 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:30:41 / 00:20:41 (~ 2200,15 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:30:41 / 00:20:41 (~ 2200,15 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:30:55 / 00:20:54 (~ 2222,22 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:30:55 / 00:20:54 (~ 2222,22 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:31:17 / 00:21:16 (~ 2256,87 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:31:17 / 00:21:16 (~ 2256,87 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:40:12 / 00:30:11 (~ 3171,32 MB) ZDF.reportage not running | EventID: 14559 PDC: 0xF1B0A

12:40:12 / 00:30:11 (~ 3171,32 MB) Drohnenkrieg - Tod aus der Luft starts in a few seconds | EventID: 12288 PDC: 0xF1B2D

12:40:23 / 00:30:22 (~ 3184,62 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:40:23 / 00:30:23 (~ 3184,62 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:42:24 / 00:32:23 (~ 3356,00 MB) ZDF.reportage running | EventID: 14559 PDC: 0xF1B0A

12:42:24 / 00:32:23 (~ 3357,11 MB) Drohnenkrieg - Tod aus der Luft not running | EventID: 12288 PDC: 0xF1B2D

12:43:36 / 00:33:35 (~ 3482,39 MB) Drohnenkrieg - Tod aus der Luft running | EventID: 12288 PDC: 0xF1B2D

12:43:36 / 00:33:35 (~ 3482,39 MB) Das Grauen des Krieges not running | EventID: 12289 PDC: 0xF1B59

12:55:00 / 00:44:59 (~ 4558,05 MB) Stop

Average Data Rate: 1,688 MB/s

Total Size: 4558,1 MB (4779464028 Bytes)

Removed Filler Data: 6,0 MB (0,1%)

April 3, 2016

Hm, kann es sein, dass die "Duration"-Angabe auch einfach nicht stimmt? Ich habe hier für eine andere Aufnahme tatsächlich den Eintrag aus der svctimers.xml und dazu im Vergleich die Log-Dateien. Die Aufnahme hat eine Länge von 44:59.

<Descr>Drogenmetropole Frankfurt - Der lange Kampf gegen die Sucht</Descr>

<NameScheme>%year-%date_%time_%station_%name</NameScheme>

</Timer>

[General]

Version=1.1

[Media]

Created=29.03.2016 09:55:01

Channel=ZDFinfo HD (deu)

[0]

Id=12247

Date=29.03.2016

Time=10:10:00

Duration=00:25:00

Title=Drogenmetropole Frankfurt

Info=Der lange Kampf gegen die Sucht

Series=

Description=Deutschland 2014|Frankfurt, 1992 - mehr als 10 000 Junkies, Straßenkriminalität wie in der Bronx und Anlagen, die von Drogenabhängigen überschwemmt werden, die sich ihren Schuss setzen. Wie ist es heute?|Frankfurt, 2014: Die Zahl der Drogenabhängigen ist halbiert, statt 147 Drogentoten gibt es 29 im Jahr 2013, und die Taunusanlage ist eine grüne Oase mitten in der Stadt. Selbst die Begründer des Konzepts sind vom durchschlagenden Erfolg überrascht.|HD-Produktion|Altersfreigabe: 6|[16:9] [H.264] [HD]|[stereo] [deu]|[stereo] [mul]|[stereo] [mis]|[Dolby Digital 2.0] [deu]|PDC: 29.03. 10:10 (957066)

Charset=255

Content=128

MinimumAge=0

TimerID={DE57CCB0-D9BB-4F6A-8A88-41010E2D7D29}

[stats]

Errors=0

Size=4,33 GB (4651717464 bytes)

Avr. Datarate=1,643 MB/s

Device=Digital Devices DVB-S/S2 Tuner 3 (1)

ZDFinfo HD (deu) 29.03.2016

E:\recording\2016-03-29_09-55-01_ZDFinfo HD (deu)_Drogenmetropole Frankfurt - Der lange Kampf gegen die Sucht.ts

Device: Digital Devices DVB-S/S2 Tuner 3 (1)

EventID: 12247 PDC: 0xE9A80

09:55:01 / 00:00:00 (~ 0,00 MB) Start Recording

09:55:01 / 00:00:00 (~ 0,00 MB) Ulrich protestiert running | EventID: 12245 PDC: 0xE9A54

09:55:01 / 00:00:00 (~ 0,30 MB) PID 6720: MPEG Audio Stereo, 48 khz, 256 kbps

09:55:01 / 00:00:00 (~ 0,30 MB) PID 6721: MPEG Audio Stereo, 48 khz, 192 kbps

09:55:01 / 00:00:00 (~ 0,30 MB) PID 6722: AC3 Audio Stereo, 48 khz, 448 kbps

09:55:01 / 00:00:00 (~ 0,30 MB) PID 6723: MPEG Audio Stereo, 48 khz, 192 kbps

09:55:02 / 00:00:01 (~ 0,30 MB) Drogenmetropole Frankfurt not running | EventID: 12247 PDC: 0xE9A8A

09:55:02 / 00:00:01 (~ 1,75 MB) PID 6710: H.264 Video, 16:9, 1280x720, 50 fps

09:58:19 / 00:03:18 (~ 305,89 MB) Ulrich protestiert running | EventID: 12245 PDC: 0xE9A54

09:58:19 / 00:03:18 (~ 305,89 MB) Drogenmetropole Frankfurt not running | EventID: 12247 PDC: 0xE9A8A

10:07:07 / 00:12:06 (~ 1090,13 MB) Ulrich protestiert running | EventID: 12245 PDC: 0xE9A54

10:07:07 / 00:12:06 (~ 1090,13 MB) Drogenmetropole Frankfurt not running | EventID: 12247 PDC: 0xE9A8A

10:08:49 / 00:13:48 (~ 1235,25 MB) Drogenmetropole Frankfurt running | EventID: 12247 PDC: 0xE9A8A

10:08:49 / 00:13:48 (~ 1235,25 MB) Crystal Meth: Die Horror-Droge not running | EventID: 12248 PDC: 0xE9AA3

10:25:01 / 00:30:00 (~ 2902,57 MB) Crystal Meth: Die Horror-Droge not running | EventID: 12248 PDC: 0xE9AA3

10:25:02 / 00:30:01 (~ 2904,44 MB) Drogenmetropole Frankfurt running | EventID: 12247 PDC: 0xE9A8A

10:37:47 / 00:42:46 (~ 4230,54 MB) Crystal Meth: Die Horror-Droge running | EventID: 12248 PDC: 0xE9AA3

10:37:47 / 00:42:46 (~ 4230,54 MB) Mexikos schmutziger Drogenkrieg not running | EventID: 12249 PDC: 0xE9AD4

10:40:00 / 00:44:59 (~ 4436,22 MB) Stop

Average Data Rate: 1,643 MB/s

Total Size: 4436,2 MB (4651717464 Bytes)

Removed Filler Data: 15,3 MB (0,4%)

April 4, 2016

Ich nehme an, die Angabe im XML-Timer entspricht dem, was aus dem EPG heraus programmiert wurde: Sendung von 10:00 bis 10:30, 5 Minuten Vorlauf, 10 Minuten Nachlauf macht eine Brutto-Dauer von 45 Minuten.

Die Angaben in der EPG-Informationsdatei entsprechen den Angaben im EPG bei Durchführung der Aufnahme: Sendung von 10:00 bis 10:25, Netto-Dauer 25 Minuten. Offenbar hat sich der EPG in der Zeit von der Programmierung der Aufnahme bis zur Durchführung geändert - so etwas kann je nach Sender öfters vorkommen. Deshalb gibt es ja Überwachungsfunktionen.

Das Aufnahme-Log spiegelt dagegen das wieder, was während der Aufnahme tatsächlich passiert ist - bei dir ohne EPG-Überwachung, aber geloggt wird der EPG-Running-Status trotzdem, damit man später nachvollziehen kann, warum der Anfang oder das Ende der Sendung fehlt Gemäß Aufnahme-Log lief die Aufnahme wie programmiert von 9:55 bis 10:40. Die Sendung begann laut EPG Statusmeldungen um 10:08:49, die nachfolgende Sendung um 10:37:47.

Fazit: Man kann sich nicht unbedingt darauf verlassen, dass die Zeiten im EPG über einen längeren Zeitraum (also einige Tage) stabil bleiben. Es kann bei den Sendern jederzeit kleinere oder größere Verschiebungen geben. Sucht man die von dir aufgenommene Sendung im Web, gibt jede Quelle andere Zeiten an...

Das sollte man auf der Rechnung haben, wenn man Sendungen lange im Voraus und ohne EPG-Überwachung programmiert - es ist ein Glücksspiel. Mit EPG-Überwachung manchmal ebenso, denn die Angaben im EPG und der Running-Status sind auch nicht immer korrekt - insbesondere bei zweiteiligen Sendungen wie Fußballspielen mit Nachrichten in der Halbzeit habe ich schon wüste Sachen erlebt.

Mit der Option "Zeitaktualisierung durch EPG" wäre die Aufnahme bei dir mit Vor/Nachlauf von 9:55 bis 10:35 gelaufen - eventuell hätte am Ende ein kleines Stück gefehlt. Die Angaben im EPG zum Aufnahmezeitpunkt waren also wahrscheinlich zumindest unpräzise! Mit "Start/Stop durch EPG-Status" wäre die Aufnahme von 10:08:49 bis 10:37:47 gelaufen und hätte vermutlich den Trailer vor der nächsten Sendung noch mitgenommen (falls es einen gab).

Bei den Sendern sind halt auch nur Menschen am Werk, und Menschen machen Fehler... will man maximale Sicherheit haben, dass das Gewünschte tatsächlich vollständig aufgenommen wird, muss man die Sendung schauen und dabei die Aufnahme manuell starten und beenden.

April 4, 2016

Also lässt sich zusammenfassen: DVBViewer funktioniert, das Verhalten kommt durch ein fehlerhaftes EPG. Dass es so aussah, als würde entweder Vor- oder Nachlauf fehlen ist Zufall.

"Zeitaktualisierung durch EPG" ist doch aber vielleicht keine schlechte Idee, die Aufnahmezeit wird wenn ich das richtig verstehe ja nur verlängert und nicht verkürzt, also kann es durch aktivieren dieser Funktion ja eigentlich nicht schlimmer werden, oder? ^^

April 4, 2016

die Aufnahmezeit wird wenn ich das richtig verstehe ja nur verlängert und nicht verkürzt

Denkste! Die Aufnahmezeit wird bei geänderten EPG-Zeiten entsprechend modifiziert, also so, als ob du die Sendung nach der Änderung programmiert hättest. Dabei kann sie sich auch verkürzen. Vor- und Nachlauf bleiben jedoch erhalten.

Nehmen wir obiges Beispiel. Angenommen, die Zeitaktualisierung wäre aktiv gewesen.

Vor der EPG-Änderung: Sendung von 10:00 bis 10:30, 5 Minuten Vorlauf, 10 Minuten Nachlauf macht eine Brutto-Dauer von 45 Minuten.

Nach der EPG Änderung: Sendung von 10:00 bis 10:25, 5 Minuten Vorlauf, 10 Minuten Nachlauf macht eine Brutto-Dauer von 40 Minuten.

Das wäre angesichts der tatsächlichen Sendezeit (abgeleitet aus dem EPG-Status und vorausgesetzt, dass er präzise war) am Ende verdammt knapp geworden

Man muss sich darüber im Klaren sein, dass der EPG geplante Sendezeiten (scheduled) angibt. so ähnlich wie ein Zugfahrplan geplante Fahrzeiten. Die Realität kennen wir ja...

April 4, 2016

Dann sind die Informationen im Wiki aber nicht korrekt: "Bei der Programmierung über das EPG aus dem Webinterface heraus wird die PIL im Timer mit abgespeichert. Damit "weiss" der Timer, zu welcher Sendung er gehört. Wenn sich die Sendezeit oder -dauer verändert, passt der Timer seine Daten automatisch an. Das funktioniert sogar, wenn sich während der Aufnahme die Dauer der Sendung verändert und der Sender das im EPG widerspiegelt. Allerdings beschränkt es sich dort nur auf eine Verlängerung der Aufnahmedauer, eine Verkürzung wird sicherheitshalber nicht berücksichtigt."

April 4, 2016

Allerdings beschränkt es sich dort nur auf eine Verlängerung der Aufnahmedauer, eine Verkürzung wird sicherheitshalber nicht berücksichtigt."

Keine Ahnung, wo das Gerücht herkommt. Ich habe es in dem alten vom ursprünglichen Autor (Lars) stammenden Code überprüft. Dort wird bereits die Aufnahmedauer in jedem Fall an den EPG angepasst.

Es wäre allerdings eine Überlegung wert, es in zukünftigen Versionen so wie im Wiki beschrieben zu halten.

Grundsätzlich muss "EPG allgemein" und "EPG Running Status" unterschieden werden. Ersteres ist wie gesagt nur ein Fahrplan. Letzteres bietet Sendern die Möglichkeit, im speziellen Present/Following-EPG, der sich allein auf die aktuelle und nachfolgende Sendung bezieht, präzise zu signalisieren, was zur Zeit läuft und danach laufen wird (ob die Sender es wirklich präzise tun, ist eine andere Frage...).

Eine Zeitaktualisierung erfolgt vor Beginn der Aufnahme durch den allgemeinen Fahrplan-EPG, während der Aufnahme jedoch durch den Present-EPG, der eine höhere Aktualität haben kann (jedoch nicht muss).

Sign In

Vor-/Nachlaufzeit wird manchmal nicht berücksichtigt?

Recommended Posts

KarlSquell

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

KarlSquell

Link to comment

KarlSquell

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

KarlSquell

Link to comment

Griga

Link to comment

Forum

Activity

Wiki

Main Page