Doppelte Timer (Version 3.01)

[x112]

Bei mir gibt es immer wieder doppelte Timer bei denen mir es nicht klar ist wo die herkommen. In der Form stören die zwar nicht, aber trotzdem seltsam.

 

Zuerst waren da nur die zwei Timer und nach ein paar Tagen sieht es so aus. Das EPG kommt aus einer XML Datei, beim Import lasse ich die alten EPG Daten nicht löschen, da es manchmal ganz praktisch ist wenn man im EPG zurück kann. In der svctimer.xml sieht es so aus:

Spoiler

    <Timer Type="1" ID="{3DC14422-9A47-4177-832E-CB96FA768CBA}" Enabled="-1" ShutDown="3" Date="09.01.2021" Start="22:00:00" Dur="75" PreEPG="10" PostEPG="10" IntID="13432" Priority="50" Action="0" Timeshift="0" EPGEventID="1378464064">
      <Descr>Lucifer - (Staffel 3, Folge 6) Bluff oder Lüge</Descr>
      <Options AdjustPAT="-1" MonitorPDC="1"/>
      <Format>2</Format>
      <Folder>Auto</Folder>
      <NameScheme>%event - %title</NameScheme>
      <Title>Lucifer</Title>
      <Subheading>(Staffel 3, Folge 6) Bluff oder Lüge</Subheading>
      <Series>Lucifer</Series>
      <Source>Search:Lucifer</Source>
      <Channel ID="3431744295312719207|kabel eins HD" EPGID="720900360755051879"/>
    </Timer>
    <Timer Type="1" ID="{9460C3C4-E048-4875-BD89-AD30023B961A}" Enabled="-1" ShutDown="3" Date="09.01.2021" Start="22:55:00" Dur="80" PreEPG="10" PostEPG="10" IntID="13433" Priority="50" Action="0" Timeshift="0" EPGEventID="1378465952">
      <Descr>Lucifer - (Staffel 3, Folge 7) Perspektivenwechsel</Descr>
      <Options AdjustPAT="-1" MonitorPDC="1"/>
      <Format>2</Format>
      <Folder>Auto</Folder>
      <NameScheme>%event - %title</NameScheme>
      <Title>Lucifer</Title>
      <Subheading>(Staffel 3, Folge 7) Perspektivenwechsel</Subheading>
      <Series>Lucifer</Series>
      <Source>Search:Lucifer</Source>
      <Channel ID="3431744295312719207|kabel eins HD" EPGID="720900360755051879"/>
    </Timer>


    <Timer Type="1" ID="{56EB9406-0CA8-472C-A97A-3CC6D34E38C3}" Enabled="0" ShutDown="3" Date="09.01.2021" Start="22:00:00" Dur="75" PreEPG="10" PostEPG="10" IntID="14497" Priority="50" Action="0" Timeshift="0" EPGEventID="1378464064">
      <Descr>Lucifer - (Staffel 3, Folge 6) Bluff oder Lüge</Descr>
      <Options AdjustPAT="-1" MonitorPDC="1"/>
      <Format>2</Format>
      <Folder>Auto</Folder>
      <NameScheme>%event - %title</NameScheme>
      <Title>Lucifer</Title>
      <Subheading>(Staffel 3, Folge 6) Bluff oder Lüge</Subheading>
      <Series>Lucifer</Series>
      <Source>Search:Lucifer</Source>
      <Channel ID="3431744295312719207|kabel eins HD" EPGID="720900360755051879"/>
    </Timer>
    <Timer Type="1" ID="{26F06733-64B6-4974-9A96-A46B240D827D}" Enabled="0" ShutDown="3" Date="09.01.2021" Start="22:55:00" Dur="80" PreEPG="10" PostEPG="10" IntID="14498" Priority="50" Action="0" Timeshift="0" EPGEventID="1378465952">
      <Descr>Lucifer - (Staffel 3, Folge 7) Perspektivenwechsel</Descr>
      <Options AdjustPAT="-1" MonitorPDC="1"/>
      <Format>2</Format>
      <Folder>Auto</Folder>
      <NameScheme>%event - %title</NameScheme>
      <Title>Lucifer</Title>
      <Subheading>(Staffel 3, Folge 7) Perspektivenwechsel</Subheading>
      <Series>Lucifer</Series>
      <Source>Search:Lucifer</Source>
      <Channel ID="3431744295312719207|kabel eins HD" EPGID="720900360755051879"/>
    </Timer>

 

 

 

Edited January 8, 2021 by Griga
Code- und Spoiler-Tags ergänzt

[BirdOfPrey]

Kommt mir bekannt vor:

https://www.DVBViewer.tv/forum/topic/64596-auto-timer-mehrfach-vorhanden/

[x112]

Gerade noch gesehen: nachts sind die Wiederholungen doppelt deaktiviert. Ist natürlich richtig, aber einmal hätte auch gereicht.

 

Für den 16.1. sind die Timer nur einmal da. In der XML Datei stehen die Daten auch nur einmal drin. Import mit XEPG.

[Griga]

vor einer Stunde schrieb x112:

Bei mir gibt es immer wieder doppelte Timer bei denen mir es nicht klar ist wo die herkommen.

 

Deine Auto-Timer-Einstellungen in der dazugehörigen Suchvorgabe wären von Interesse. In dem Screenshot von @BirdOfPrey ist z.B. (unten rechts) sämtliche Deaktivierung ausgeschlossen.

 

[x112]

In searches.xml:

 

    <Search Name="Lucifer" AutoRecording="-1" AutoRemind="0" IgnoreCase="-1" UseRegEx="0" CheckRecTitle="-1" CheckRecSubTitle="-1" CheckTimer="-1" IncRemoved="-1" MonitorPDC="-1" MonitorForStart="0" FavOnly="0" ID="82">
      <EndTime>23:59</EndTime>
      <StartTime>00:00</StartTime>
      <EPGAfter>10</EPGAfter>
      <EPGBefore>10</EPGBefore>
      <Genre>-1</Genre>
      <RecordingFolder>Auto</RecordingFolder>
      <Priority>50</Priority>
      <RecFormat>2</RecFormat>
      <RecRadioFormat>0</RecRadioFormat>
      <RecNameScheme>%event - %title</RecNameScheme>
      <SearchFields>1</SearchFields>
      <SearchPhrase>&quot;Lucifer&quot;</SearchPhrase>
      <DurationMin>0</DurationMin>
      <DurationMax>0</DurationMax>
      <Days>127</Days>
      <Series>Lucifer</Series>
      <Shutdown>3</Shutdown>
      <Channels>
        <Channel>324420375772519</Channel>
      </Channels>
 

[Griga]

Am 8.1.2021 um 13:12 schrieb x112:

In searches.xml:

 

Danke. Das hat dazu beigetragen, potentielle Ursachen einzugrenzen, aber leider noch keine endgültige Klärung gebracht. Ich kann mir nach wie vor keinen Reim darauf machen, warum es hier zu doppelten Timern kommt. Der Autosuche-Code schließt das eigentlich aus.

 

Der DMS prüft bei der Abarbeitung der Suchergebnisse, ob enthaltene EPG-Einträge bzw. Sendungen bereits durch einen Timer abgedeckt sind, egal ob dieser aktiviert oder deaktiviert ist. Falls ja, verwirft er sie. Sie sollten also keine zusätzlichen Timer erzeugen, auch kein deaktivierten. Diese Überprüfung scheint bei dir nicht funktioniert zu haben. Funktioniert hat jedoch die Deaktivierung dieser überflüssigen Timer aufgrund der Einstellungen für die Suchvorgabe ("Auto-Timer deaktivieren bei...").

 

Eine Besonderheit ist bei dir die Einstellung "EPG-Überwachung -> Zeitaktualisierung durch EPG". Offenbar hast du den Tweak "EPG Event ID-Verwendung bei Timer-Handhabung" aktiviert, sonst hätte der DMS die Einstellung für die EPG-Überwachung nicht in den Timer übernommen. Praktisch sagst du ihm damit, dass er darauf vertrauen soll, dass die Event ID für eine Sendung unverändert bleibt, auch wenn sich andere Daten (z.B. Anfangszeit oder Titel) ändern. Deshalb verwendet der DMS bei eingeschalteter EPG-Überwachung (nur dann!) die Event ID für die Überprüfung, ob es schon einen Timer für die Sendung gibt, d.h. er sucht nach einem Timer für den betreffenden Sender mit gleicher Event ID. Ansonsten würde er Anfangszeit und Dauer vergleichen und den Timer für eine bestimmte Sendung anhand einer ausreichenden zeitlichen Überschneidung wiedererkennen.

 

Würde sich die Event ID der Sendung im EPG ändern, würde die Auto-Suche bei eingeschalteter EPG-Überwachung doppelte Timer produzieren. Das könnte mit dem gesendeten DVB-EPG der Privaten passieren, da sie nach meiner Erfahrung die Event ID nicht zuverlässig handhaben (das war allerdings vor längerer Zeit, man müsste es erneut überprüfen). Hier handelt es sich jedoch um einen importierten EPG. Wie es dabei mit der Stabilität der Event ID aussieht, weiß ich nicht. Wie auch immer - wäre dies die Ursache für den zusätzlichen Timer gewesen, hätte er mit einer anderen Event ID als sein Doppelgänger gespeichert werden müssen. Das ist jedoch in der geposteten Timerliste nicht der Fall. Die Event IDs der doppelten Timer stimmen überein, ebenso wie die Sender-IDs.

 

Der andere gemeldete Fall von doppelten Timern weist dazu Parallelen auf. Auch hier war "EPG-Überwachung -> Zeitaktualisierung durch EPG" aktiviert. Es handelte sich jedoch um den gesendeten EPG des ZDF, also um einen öffentlich-rechtlichen Sender, der im Gegensatz zu den Privaten einen PDC-Wert (Program Delivery Control, eine Art VPS-Signal) im EPG mitsendet. Das ist die urspüngliche Anfangszeit der Sendung in kodierter Form, die gleich bleibt, auch wenn sich die tatsächliche Anfangszeit ändert. Deren "Stabilität" vertraut der DMS im Gegensatz zur Event ID ohne Tweak. Wenn er für eine Sendung  mit PDC einen bereits vorhandenen Timer sucht, sucht er also nach einem mit gleichem PDC-Wert. Würde sich die PDC im EPG ändern, ergäbe die Auto-Suche doppelte Timer. Aber auch in diesem Fall waren die PDC-Werte der Doppelgänger gleich.

 

Also ein typischer Fall von "Kann nicht sein, passiert aber trotzdem". Da bin ich erst mal ratlos. Hinzu kommt die schlechte Reproduzierbarkeit des Vorgangs, der sich über mindestens zwei Auto-Suchvorgänge mit größerem (?) zeitlichem Abstand erstreckt. Könnte ich ihn unter Debugger-Kontrolle mit Einzelschritten und der Ausgabe von Variablen-Werten verfolgen, ließe sich die Ursache wahrscheinlich ermitteln. Aber wie soll ich das herstellen?

 

 

[x112]

Ich glaube das diese Doppelung bei Lucifer auch schon mal früher passiert ist. Ich beobachte deshalb ob sich an den Timern für nächsten Samstag etwas ändert und kopiere immer die vorherige Import XML Datei. Bis jetzt passt aber noch alles. Ich melde mich dann sobald sich was tut oder am Sonntag.

 

Der Eintrag in der XML Datei fängt übrigens so an:

<programme start="20210116221500 +0100" stop="20210116231500 +0100" channel="Kabel"> <title>Lucifer</title> <sub-title>Lucinda</sub-title>
<desc>Eine junge Programmiererin wird tot in ihrer Wohnung aufgefunden. Lucifer - geblendet von dem unscheinbaren Erscheinungswesen der Getöteten - ist überrascht, als die erste Spur zu einer exklusiven Dating-App führt, in der Profile erst nach Bewerbungsgesprächen angelegt werden ...&lt;br&gt;&lt;br&gt;Dies ist die 8. Episode der 3. Staffel.</desc>
<date>2017</date> <country>USA</country> <length units="minutes">60</length> <episode-num system="xmltv_ns">2.7.</episode-num>
<category>Detective / Thriller</category>

 

Also keine Event ID. Bei einer Aufnahme sieht es aber so aus (willkürliche Aufnahme nur als Beispiel):

11:35:00 / 00:00:00 (~ 0,00 MB) Start Recording
11:35:00 / 00:00:00 (~ 0,00 MB) Wabbit not running | EventID: 6939 PDC: 0x00000
11:35:00 / 00:00:00 (~ 0,00 MB) EventID change 1378573888 to 6939
11:35:01 / 00:00:01 (~ 0,00 MB) Wabbit running | EventID: 6942 PDC: 0x00000
11:35:02 / 00:00:01 (~ 0,33 MB) PID 553: H.264 Video, 16:9, 1920x1080, 25 fps
11:35:02 / 00:00:01 (~ 0,33 MB) PID 554: AC3 Audio Stereo, 48 khz, 384 kbps
11:49:57 / 00:14:56 (~ 614,78 MB) Wabbit running | EventID: 6939 PDC: 0x00000

 

Es wird immer eine wohl zufällige ID in die korrekte ID gewandelt (falls die Sendungen nicht zu arg verschoben sind).Hier wird also der externe EPG mit dem DVB EPG verglichen. Falls eine Verschiebung erkannt wurde, wird auch die Endzeit angepasst. Dummerweise wird auch die Endzeit verkürzt.

Ich habe diese EPG Option inzwischen nur noch bei wenigen Sendern aktiv.

 

 

 

[Griga]

vor einer Stunde schrieb x112:

Also keine Event ID. Bei einer Aufnahme sieht es aber so aus

 

Die während der Aufnahme geloggte Event ID ist die des via DVB "live" eintreffenden EPG, während die im Timer aus den importierten EPG-Daten stammt. Ich glaube, ich muss mich mal mit dem Nebeneinander von importiertem und DVB-EPG im Recorder befassen und was daraus resultieren könnte (nicht nur im Hinblick auf doppelte Timer). Den Aspekt hatte ich bislang nicht im Blick.

 

Soweit ich weiß, generiert XEPG für importierte EPG-Daten eine künstliche Event ID aus anderen Daten, erkennbar daran, dass sie größer als 65535 ist, weil sie 32 statt 16 Bit nutzt, aber ich weiß nicht wie. Am besten nachfragen:

 

@Delphi Maybe important for this topic: How does XEPG generate the Event ID of imported data? Can it (typecasted to Integer) get negative with bit 31 set?

 

[Delphi]

8 hours ago, Griga said:

 

@Delphi Maybe important for this topic: How does XEPG generate the Event ID of imported data? Can it (typecasted to Integer) get negative with bit 31 set?

 

Xepg does not create any event IDs. DVBViewer/DMS do that by converting the start time af a programme element to a 32 bit integer. Just look into your code

[Griga]

vor 55 Minuten schrieb Delphi:

DVBViewer/DMS do that by converting the start time af a programme element to a 32 bit integer.

 

That's half the truth. The DMS tries to read an eventid value from the imported XML. If this doesn't succeed, the SysUtils DateTimeToFileDate function is used to convert the start time to an Integer, which serves as substitute (which means, if the start time changes, the Event ID also changes). In 2044 it will get negative and cause problems, because the DMS will regard it as invalid (not set) Event ID. So there are 23 years left to fix it. However, regarding my age and Corona, I better do it right now

 

I didn't know that before. Thanks for pointing me to the right direction. After more than 7 years there are still unkown parts of the DVBViewer/DMS code to discover...

 

[Delphi]

11 minutes ago, Griga said:

After more than 7 years there are still unkown parts of the DVBViewer/DMS code to discover...

 

In the old days I actually did deliver Event IDs (derived from the start time). I am pretty sure it was you that told me they were not needed

Edited January 11, 2021 by Delphi

[Delphi]

I actually found the code:

Spoiler

(*
  function TImportEPGThread.CalculateEventID(t: TDateTime): integer;
  begin
    Result := LongWord(YearOf(t) mod 10)*100000000
            + MonthOf(t)*1000000
            + DayOf(t)*10000
            + HourOf(t)*100
            + MinuteOf(t);
  end;
*)

 

 

VERY old code. It can probably be done smarter, but the idea with YearOf(t) mod 10 should be good enough.

Edited January 11, 2021 by Delphi

[Griga]

vor 20 Stunden schrieb Griga:

Ich glaube, ich muss mich mal mit dem Nebeneinander von importiertem und DVB-EPG im Recorder befassen und was daraus resultieren könnte

 

Die Schlussfolgerungen aus Delphis Hinweisen und eigenen Untersuchungen:

• Die Event IDs eines mit XEPG importierten EPGs resultieren aus der Startzeit, d.h. wenn sich die Startzeit ändert, ändert sich auch die Event ID. Bei "EPG-Überwachung -> Zeitaktualisierung durch EPG" zusammen mit dem Tweak "EPG Event ID-Verwendung bei Timer-Handhabung" passt der DMS sowohl die Startzeit als auch die Event ID nach einer (importierten) EPG-Aktualisierung automatisch an (spätestens nach einer Minute), sofern sich die Sendezeit nicht zu stark verschoben hat. Nach einer größeren Verschiebung wird dem Timer eventuell eine falsche Sendung zugeordnet, insbesondere  falls eine andere Sendung exakt die vorherige Startzeit der aufzunehmenden Sendung und damit die gleiche Event ID erhält.
• Auch mit externem EPG empfängt der DMS während einer Aufnahme den originalen DVB-EPG, um den "Running Status" der laufenden und nachfolgenden Sendung zu loggen und gegebenenfalls Korrekturen durchzuführen. Hierbei stellt er fest, dass die gespeicherte Event ID (aus dem importierten EPG) nicht mit der empfangenen Event ID übereinstimmt und korrigiert erstere, wobei es einen "EventID Change" Eintrag im Log gibt. Wenn nachfolgend während der Aufnahme Auto-Timer erzeugt werden, entsteht ein doppelter Eintrag. Ich denke, die Korrektur der Event ID auf die originale (gesendete) sollte unterbleiben, wenn sich der Timer auf einen externen EPG bezieht, da inkonsequent (und inkonsistent).
• Eine weitere Folge der "Einmischung" des originalen DVB-EPGs ist, dass der DMS bei der Einstellung "EPG-Überwachung -> Zeitaktualisierung durch EPG" gegebenenfalls die Endzeit der Aufnahme gemäß dem DVB-EPG korrigiert. Ob das passieren soll, ist IMO Geschmackssache. Konsequent wäre, bei Verwendung eines externen EPG darauf zu verzichten. Meinungen?

[BirdOfPrey]

vor 3 Stunden schrieb Griga:

Meinungen?

Auf Nummer sicher würde man gehen, die Endzeiten zu vergleichen und die größere zu benutzen. Ich vermute niemanden wird es stören, wenn die Aufnahme zu lang ist. Aber eine Aufnahme ohne Sendungsende ist ärgerlich.

Dann stellt sich aber natürlich die zweite Frage, was ist mit der Startzeit?

[x112]

Die Endzeit Aktualisierung finde ich eigentlich sehr praktisch, da hier gewisse Verschiebungen nach hinten berücksichtigt werden. Eine Verkürzung sollte aber auf keinen Fall passieren. Da im DVB EPG nur der Sendungstitel und nicht der Untertitel verglichen wird, kann da schon mal bei mehreren Folgen einer Serie hintereinander die falsche Folge erwischt werden. Die Startzeit kann nur innerhalb des Vorlauf korrigiert werden und dann läuft die Aufnahme ja schon.

[Griga]

Ich befasse mich zunächst weiter mit der Frage, wie es zu doppelten automatisch erzeugten Timern durch EPG-Suche kommen kann. Die bisherigen Ergebnisse zusammengefasst:

• Wenn man EPG-Daten importiert, hängt die Event ID von der Startzeit im EPG ab und kann sich damit ändern. Hat man denTweak "EPG Event ID-Verwendung bei Timer-Handhabung" aktiviert, verlässt sich der DMS auf die Event ID bei der Wiedererkennung von Sendungen. Ein importierter EPG-Eintrag mit (im Vergleich zu vorher) geänderter Startzeit/Event ID ist für ihn deshalb eine andere Sendung, für die ein neuer Auto-Timer erzeugt wird. Die im ersten Post geschilderten Doppeleinträge könnten durch folgenden Ablauf entstehen:
  • Auf Basis eines importierten EPG wurden die Timer für zwei Sendungen mit den Startzeiten X1 und Y1 erzeugt.
  • Eine Zeit später werden EPG-Daten importiert, die für die beiden Sendungen neue Startzeiten X2 und Y2 und damit andere Event IDs angeben.
  • Eine direkt nachfolgende Auto-Suche erkennt die Sendungen nicht wieder und erzeugt deshalb für sie weitere Timer.
  • Etwas später korrigiert der DMS aufgrund der Einstellung "EPG-Überwachung -> Zeitaktualisierung durch EPG" die zuerst erzeugten Timer auf die neuen Anfangszeiten und die neue Event ID, so dass nun identische Doppeleinträge existieren. Diese zeitliche Reihenfolge ist möglich, weil der DMS seine Timer nur einmal pro Minute mit dem EPG abgleicht.
• Wenn man EPG-Daten importiert, aber es gleichzeitig einen DVB-EPG gibt, überwacht der DMS während der Aufnahme dessen Now/Next-Einträge. Dabei registriert er auch die aus dem DVB-EPG stammende Event ID der aufzunehmenden Sendung, stellt fest, dass sie von der des importierten EPGs abweicht, und korrigiert sie. Wenn nun währenddessen bei aktivem Tweak "EPG Event ID-Verwendung bei Timer-Handhabung" Auto-Timer erzeugt werden, gibt es einen Doppeleintrag, weil der DMS die aus dem importierten EPG stammende Event ID im Timer der laufenden Aufnahme nicht wiederfindet. Die Timer-Doppeleinträge aus dem ersten Post können so jedoch nicht entstanden sein, weil die Aufnahmen zu dem Zeitpunkt noch in der Zukunft lagen. NIchtsdestotrotz ist das Abändern der Event ID als Bug anzusehen und sollte vermieden werden.

Damit nun die Frage an @x112: Ist der im ersten Punkt angegebene zeitliche Ablauf bei dir möglich? Folgt die Auto-Suche direkt auf einen EPG-Import?

 

Insgesamt bleibt festzuhalten, dass die Event ID-basierte Wiedererkennung von Sendungen (als Folge des Tweaks "EPG Event ID-Verwendung bei Timer-Handhabung") bei importiertem EPG eine wackelige Angelegenheit und deshalb nicht empfehlenswert ist.

 

[x112]

Heute morgen ist das Problem wieder aufgetreten. Diesmal aber nur bei den Lucifer Sendungen vor Mitternacht.

 

In den XML Dateien habe ich nur Einträge mit Startzeit 22:00 bzw. 23:00 entdeckt.

 

@Claus PeterAber: es gibt ein Problem mit dem EPGBuddy.

Mit EPG Buddy lade ich Daten von Clickfinder und TV Spielfilm. Die beiden werden dann von EPGBuddy in eine Datei zusammen gefasst und diese wird mit XEPG importiert.

Ab und zu scheint das zusammenfassen aber schief zu gehen, die Summendatei wird immer größer und enthält doppelte Einträge. Kann diese Timer Doppelung dadurch entstehen?

 

Liste der XML Dateien:

14.01.2021  19:17       101.973.453 EPG - Kopie.xml
15.01.2021  08:17       153.065.984 EPG.xml
15.01.2021  08:16        53.396.991 EPG_ClickFinder.xml
15.01.2021  08:15         2.344.302 EPG_TVSpielfilm.xml

 

Die EPG Aktualisierung läuft bei mir um 8:00 und um 19:00 nach dem Muster:

 

"Refresh Nick Autotimer" ist ein Script das über die WebAPI alle aktiven Timer auf Nick löscht und danach Autotimer aufruft, die ersten beiden Timer aktualisieren die Autotimer nicht. Während des DVB EPG Scan wird per Windows Task von tvuptodate die Clickfinder Datenbank aktualisiert .

 

Als Workaround werde ich die Zusammenfassung in EPGBuddy deaktivieren und in XEPG die beiden Dateien eintragen.

 

[Claus Peter]

Hi.

Das Problem bei dir dürfte von der "EPG - Kopie.xml" verursacht werden, die dort absolut nichts verloren hat und auch nicht von EPG-Buddy erzeugt wurde...  Beim Zusammenfassen werden alle XML Dateien aneinander gefügt. Eine Kopie alter EPG Daten ist dabei extrem störend. Auf die Idee, das jemand manuell Kopien der alten Daten anlegt und sie im Ausgabeordner hinterlegt, auf die bin ich echt nicht gekommen. Warum machst du das? 

 

Außerdem macht es keinen Sinn, zweimal am Tag EPG Daten zu laden. Die werden sowieso nur einmal am Tag (irgendwann zwischen 5-7 Uhr morgens, je nach Quelle) aktualisiert. Bei mir läuft der Download immer um 8:20 Uhr morgens. Dann sind die Daten sicher aktualisiert und es ist keine "volle Stunde", wo die meisten Leute ja bevorzugt ihre Daten aktualisieren. Alles was über einmal am Tag hinaus geht, ist nur völlig überflüssiger Traffic und völlig überflüssige Last für die Server, die die Daten bereitstellen.  Sollte man unbedingt vermeiden, denn die meisten dieser Dienste werden kostenlos bereit gestellt (abgesehen von Clickfinder und epgData, die man ja kostenpflichtig abonnieren muss). Wird dabei die Server Auslastung zu hoch, besteht die absolut reale Gefahr, das diese Dienste einfach abgeschaltet werden. Also bitte niemals häufiger als einmal am Tag Daten laden...

 

 

Edited January 16, 2021 by Claus Peter

[x112]

Das mit der Kopie Datei ist einfach zu erklären: ich wollte die Vorgängerversion aufheben um zu sehen ob es im EPG Zeit Verschiebungen gibt durch die eventuell diese doppelten Timer entstehen könnten. Eigentlich dachte ich das EPG Buddy nur die von ihm erzeugten Dateien zusammenkopiert (oder EPG_*.xml) und nicht alle EPG*.xml Dateien im Verzeichnis.

 

Bei mir hat manchmal die 19:00 Aktualisierung durchaus was gebracht. Mag sein das um 8:00 manchmal noch keine neuen Daten zur Verfügung stehen. Kann ich mal durch Verschiebung auf 8:30 testen.

 

Also  weiterhin auf Timer Doppelung achten.

[Claus Peter]

Es gibt zu viele Varianten und Kombinationsmöglichkeiten bei den Namen, um das "Einfach" an Hand der Dateinamen zusammen zu fügen. *.xml ist da um ein vielfaches einfacher und funktioniert perfekt, so lange man das Ganze so wie gedacht verwendet. Schließlich muss das ja auch im unbeufsichtigten Hilfstool funktionieren, nicht nur im "großen" GUi Programm. Ich habe schlicht nicht damit gerechnet, das jemand valide TVGudie.xml Dateien manuell in den Ausgabeordner kopiert. Wenn du die Kopien aufheben willst, solltest du entweder die Dateiendung wechseln (z.B. auf .bak) oder einen anderen Ordner zum Speichern verwenden.

 

Bei welchen Quellen hat denn die Aktualisierung um 19:00 Uhr was gebracht? Bei allen, mir bekannten Quellen werden die Daten nur einmal am Tag und zwar früh morgens aktualisiert. Dann kann das erneute Grabben einfach nichts bringen.

[x112]

Das war bei Clickfinder der Fall. Aber wie gesagt kann es auch sein das der Abruf um 8:00 einfach zu früh war.

[x112]

Es ist verteufelt, heute Nacht gibt es schon wieder doppelte Timer.

Nach Löschen der Timer und Autosuche gibt es nur einen Eintrag, so wie sein soll.

 

Ich werde jetzt mal die EPG Zeitaktualisierung aus der Suche rausnehmen. In den letzten Tagen habe ich leider nicht mehr darauf geachtet ob sich zwischenzeitlich die Zeiten für die Sendung geändert haben.