Autotimer erzeugen oft doppelte Timer Einträge

[Trill Ian]

Guckstdu rot unterlegt:

Es existiert nur ein Autotimer für "Game Two" (bei MAITHINK X übrigens das Gleiche, aber das war ne Wiederholung, deshalb sind alle Einträge deaktiviert).

Es werden aber zwei Timer angelegt, wobei der zweite (korrekterweise) deaktiviert ist.

Passiert nicht bei allen Timern, aber häufig bei zdf neo, Welt HD und noch ein paar anderen.

 

Ist ja nicht schlimm, aber bringt mich ins Grübeln.

 

Hat irgendjemand ne Idee, wo das herkommen kann???

 

[Griga]

Ist bekannt, ob die fraglichen Einträge gleichzeitig oder nacheinander (an verschiedenen Tagen) entstanden sind?

 

Analysieren und eventuell nachvollziehen kann ich das nur anhand der svctimers.xml und searches xml - eventuell per PM, falls sie öffentlichkeitsscheu sind.

 

[Trill Ian]

vor einer Stunde schrieb Griga:

Ist bekannt, ob die fraglichen Einträge gleichzeitig oder nacheinander (an verschiedenen Tagen) entstanden sind?

Nein, ich guck da nicht jeden Tag hin, und manche Timer enstehen ja schon Wochen im Voraus, soweit scrollt man ja nicht runter.

Aber wenn man sich den weiten Abstand in der Datei anguckt (>1000 Zeilen), drängt sich die Vermutung auf, dass die Einträge NICHT am selben Tag erfolgt sein können.

 

Hängt an (was soll daran "geheim" sein ??? sind keine Pornos im Suchraster :-)))) )

 

Ach ja, falls es was hilft: der Media Server läuft auf eine W11 VM mit 2 emulierten LAN Karten (läuft nun aber schon seit 3 Monaten stabil und ohne Paketverluste).

 

ServiceDinga.zip

Edited June 13 by Trill Ian

[Bob.Dig]

Hab so was bei mir im Kabel auch schon gesehen, scheint mir vor allem vom Sender abzuhängen.

[Trill Ian]

Hmm, das KANN natürlich passieren, wenn der Sender EPG Updates schickt und dabei die ProgramID ändert. Dann weis der arme unschuldige Media Server gar nicht, dass es dieselbe Sendung ist, ausser, er würde auch die anderen Felder alle miteinander vergleichen. Aber er checkt ja nur Titel und Sub-Titel, nicht die Zeiten.

[Griga]

Bei Game Two #337 liegt es daran, dass sich der PDC-Wert geändert hat (Program Delivery Control), oder genauer gesagt das mit dem EPG im PDC-Descriptor gesendete PIL (Program Identification Label). Das ist praktisch das digitale VPS-Signal. Das PIL besteht aus 20 Bit und gibt binär kodiert die ursprünglich vorgesehene Sendezeit an (von links nach rechts gelesen Bit 1..5 Tag, Bit 6..9 Monat, Bit 10..14 Stunde, Bit 15..20 Minute). Auch wenn sich die Sendezeit verschiebt, muss dieses PIL gleich bleiben, weil VPS-fähige Recorder daran die Sendung wiedererkennen.

 

Bei Game Two #337 ist das PIL jedoch nicht gleichgeblieben. Im ersten der beiden Einträge in der svctimers.xml hat der DMS PDC="439774" notiert - das entspricht dem 23.06. 23:30 - aber im zweiten PDC="439779", entsprechend dem 23.06. 23:35. Damit sind das für den Recorder verschiedene Sendungen, weil sie verschiedene urspüngliche Sendezeiten haben.

 

Bei der MAITHINKX-Sendung ist es offenbar ebenso - ich habe aber bislang nur einen kurzen Blick darauf geworfen. Es liegt der Verdacht nahe, dass die Sendetechnik hier Mist baut. Sowas darf nicht passieren, da es die DVB-Spezifikationen verletzt.

 

vor 5 Stunden schrieb Trill Ian:

Passiert nicht bei allen Timern, aber häufig bei zdf neo, Welt HD und noch ein paar anderen.

 

Die Privatsender haben fast alle keinen PDC-Descriptor im EPG. Da muss es also an etwas anderem liegen. Ich bräuchte den Namen einer "gedoppelten" Sendung in der svctimers.xml, anhand der ich es überprüfen kann.

 

[Trill Ian]

vor 18 Stunden schrieb Griga:

Ich bräuchte den Namen einer "gedoppelten" Sendung in der svctimers.xml, anhand der ich es überprüfen kann.

z.B. "Traumzüge - Tren Crucero" (Samstag 15.6 um 16:37). Ist 2* zur selben Zeit drin, aber auf 2 verschiedenen "Welt HD" (Kabel / SAT). Das MAG ja dann auch richtig sein, die haben sicherlich nicht dieselbe ID. Sind aber beide grau, weil es eine Wiederholung ist. Also könnten die Einträge durchaus korrekt sein.

 

Gag am Rande: "Game Two #337" wurde heute Nacht gar nicht gesendet! Kann es sein, dass das EPG den Entfall anzeigen wollte, der Media Server dies aber als 2ten Eintrag interpretiert hat?

Edited June 14 by Trill Ian

[Griga]

Am 13.6.2024 um 20:17 schrieb Trill Ian:

aber auf 2 verschiedenen "Welt HD" (Kabel / SAT).

 

Damit haben sie eine verschiedene Sender-ID, und gleichzeitige Sendungen werden nicht als gleich erkannt.

 

Am 13.6.2024 um 20:17 schrieb Trill Ian:

Kann es sein, dass das EPG den Entfall anzeigen wollte, der Media Server dies aber als 2ten Eintrag interpretiert hat?

 

Der EPG signalisiert einen "Entfall" nicht explizit. Die Sendung fehlt dann einfach bzw. an ihrer Stelle befinden sich andere Sendungen.

 

[Trill Ian]

vor 35 Minuten schrieb Griga:

Die Sendung fehlt dann einfach bzw. an ihrer Stelle befinden sich andere Sendungen.

Ja, da war dann sonne komische Fußball (IGITT!!!) Doku. Aber der alte Timer wurde nicht gelöscht.

Verständlich, aber vielleicht mit Verbesserungspotential??? Bei gleichem Sender und gleichen Zeiten könnte man den alten Timer doch zumindest deaktivieren ? 🤩

[Bob.Dig]

Am 15.6.2024 um 08:55 schrieb Trill Ian:

Bei gleichem Sender und gleichen Zeiten könnte man den alten Timer doch zumindest deaktivieren ? 🤩

Das oder vielleicht auch nur eine Info, welcher Timer als letztes hinzugefügt wurde und damit am aktuellsten ist, denn zurzeit kann ich das nirgends erkennen. Vielleicht kann das auch noch in die Leuchte gequetscht werden.

[Griga]

vor 17 Stunden schrieb Bob.Dig:

Das oder vielleicht auch nur eine Info, welcher Timer als letztes hinzugefügt wurde und damit am aktuellsten ist,

 

Die nächste Version wird folgende Lösung bieten:

 

https://www.dvbviewer.tv/forum/topic/72521-removing-timers-created-by-searchdisabling-auto-generate/?do=findComment&comment=520028

 

Der neue Button "Timer löschen" auf der Seite EPG-Suche ermöglicht es, alle von einer bestimmten Suchvorgabe erzeugten Timer zu eliminieren. Lässt man darauf ein "Timer erzeugen" für die selbe Suchvorgabe folgen, entspricht dies praktisch einer Aktualisierung der Timer. Damit verschwinden dann z.B. Timer für nicht mehr vorhandene EPG-Einträge oder auch Timer, die sich auf einen nicht mehr vorhandenem PDC-Wert beziehen. Gleichzeitig kommen dabei eventuell in der Suchvorgabe geänderte Timer-Einstellungen zur Geltung, z.B. eine andere Vorlaufzeit oder eine andere Sender-Auswahl.

 

Zu überlegen wäre, ob man nicht sogar (optional) jeder automatischen Timer-Erzeugung ein Löschen der zuvor durch die selbe Suchvorgabe erzeugten Timer vorangehen lässt. Zu bedenken ist jedoch, dass bei einer solchen Holzhammer-Aktualiserung alle Anpassungen verloren gehen, die ein Anwender zuvor manuell bei automatisch erzeugten Timern durchgeführt hat. Deshalb scheue ich noch davor zurück. Gibt es dazu Meinungen?

 

[Bob.Dig]

vor 2 Stunden schrieb Griga:

 

Zu überlegen wäre, ob man nicht sogar (optional) jeder automatischen Timer-Erzeugung ein Löschen der zuvor durch die selbe Suchvorgabe erzeugten Timer vorangehen lässt. Zu bedenken ist jedoch, dass bei einer solchen Holzhammer-Aktualiserung alle Anpassungen verloren gehen, die ein Anwender zuvor manuell bei automatisch erzeugten Timern durchgeführt hat. Deshalb scheue ich noch davor zurück. Gibt es dazu Meinungen?

 

 

Wow, ich hoffe, es ist nicht zu früh für mich und ich hab das richtig verstanden. Grundsätzlich würde ich das sehr begrüßen, aber mit "einer" Ausnahme: Sobald jemand manuell Änderungen an einem Timer vorgenommen hat, sollte dieser Timer nicht mehr angefasst werden. Ich denke, das würde 99,9% der Fälle abdecken und wäre sowieso eine Verbesserung zu davor.

 

Beispiel: Ich ändere manuell den Kanal bei einem Timer, dann möchte ich, dass das auch so bleibt. Das ist ja auch der Ist-Zustand, dieser Timer wird ja schon jetzt nicht mehr angefasst oder irre ich da? Aber selbst wenn ich mich irre, sobald manuell dran herumgepfuscht wurde, soll der so bleiben. Es darf in diesen Fällen dann auch gerne ein "doppelter" Timer erstellt werden, diese Unschärfe nehme ich gerne in Kauf.  

 

Wenn aber jemand die EPG-Suchvorgabe ändert, dann können die daraus generierten Timer gerne gelöscht werden, was wohl im englischen Bereich gefordert war.

Edited July 28 by Bob.Dig

[HaraldL]

Dem kann ich mich anschließen. Grundsätzlich eine gute Idee, so bei der EPG-Suche Timer die nicht mehr gefunden werden zu eliminieren oder bei zeitlicher Verschiebung doppelte zu vermeiden.

 

Aber wie Bob.Dig finde ich, daß es pro Timer ein Flag geben müsste ob er manuell angefasst wurde und dann NICHT gelöscht wird. Bestes Beispiel: Auto-Timer findet eine Sendung 3x und legt 3 Timer an. Ich deaktiviere zwei davon manuell. Würden jetzt bei der nächsten EPG-Suche alle 3 Timer gelöscht und neu angelegt wären wieder alle 3 aktiv. Also irgendeine händische Aktion (aktivieren/deaktivieren, Zeiten ändern usw.) sollte diesen Timer vor automatischem Löschen schützen. Die anderen gerne (Außer natürlich Timer die bereits aufnehmen 😉 selbst wenn die bei der EPG-Aktualisierung jetzt fehlen sollten).

 

 

[Trill Ian]

Also Teil 1 gefällt mir, bei Teil 2 (automatisches Löschen vor jeder Suche) bin ich skeptisch. Ich guck die manchmal 200 Einträge nur sporadisch durch, da kann man sich den einzelnen Eintrag nicht merken, und es fällt nicht auf, wenn er auf einmal verschwunden ist.

 

Eine etwas harmlosere Variante wäre, vor der Suche alle vorhandenen Timer zu deaktivieren und bei der Suche die gefundenen nicht gleich neu anzulegen, sondern zu reaktivieren, wenn sie schon da sind. (sonst hätte man schnell 30 deaktivierte Timer für eine einzige Aufnahme, weil das EPG der Öffis doch recht weit in die Zukunft zeigt).

 

Aber das Flag "ich wurde manuell geändert! lass mich in Ruhe!!!" muss eingebaut und beachtet werden.

 

[HaraldL]

vor 21 Minuten schrieb Trill Ian:

sonst hätte man schnell 30 deaktivierte Timer für eine einzige Aufnahme, weil das EPG der Öffis doch recht weit in die Zukunft zeigt

Nicht wenn man die Suchvorgabe mit Datumsbereich "today" bis z.B. "today+2" anlegt (Info dazu steht jetzt auch im Tooltip der Felder). Bringt eh nichts Timer 10+ Tage im Voraus anzulegen. Macht die Liste nur unnötig lang und unübersichtlich, und evtl. stimmen die Timer gar nicht mehr bis es soweit ist. Da die Timer sowieso bei jeder EPG-Suche angelegt werden reicht mir das. Ich habe ausnahmslos alle Suchvorgaben mit today/today+X ergänzt, bei Sendern die viel verschieben nur mit "today+1".

[Griga]

vor 9 Stunden schrieb HaraldL:

Grundsätzlich eine gute Idee, so bei der EPG-Suche Timer die nicht mehr gefunden werden zu eliminieren oder bei zeitlicher Verschiebung doppelte zu vermeiden.

 

Du meinst wahrscheinlich "bei der EPG-Suche Timer für Sendungen, die nicht mehr gefunden werden, zu eliminieren". Denn wie willst du einen Timer eliminieren, der nicht mehr auffindbar ist?

 

Am einfachsten lässt sich das Eliminieren realisieren, indem man vor einer Auto-Timer-Suche alle Timer löscht, die eine bestimmte Suchvorgabe beim vorherigen Durchgang erzeugt hat. Eine solche Radikal-Aktualisierung hinterlässt nur Timer, die der aktuelle Zustand des EPG bei der Suche hergibt.

 

Die zu löschenden Timer lassen sich durch einen Vergleich der Timerquelle ermitteln, also dem, was auf der Timerseite des Web Interface beim Button für das Aktivieren/Deaktivieren von Timern ganz links als Hinweis erscheint, wenn man den Mauszeiger drüber hält. Sowas wie z.B. Search:Nord bei Nordwest, wobei hier wohlgemerkt nicht der Name der Sendung, sondern der Name der erzeugenden Suchvorgabe auftaucht. Ändert man diesen Namen auf der Seite EPG-Suche, funktioniert das selektive Löschen nicht mehr.

 

Bei der Vorgehensweise stellt sich zunächst die Frage: Auf welche Weise kann es schiefgehen? Sowas finden i.a. Anwender nach einem Release heraus, mit deren speziellen Verhältnissen der Entwickler nicht gerechnet hat. Nur ein Beispiel: Es gibt für den DMS den Tweak "Lösche alle EPG-Daten vor einem EPG Update". Er wurde vor Jahren eingeführt, um Chaos verhindern zu können, das in bestimmten Fällen durch die Überlagerung alter EPG-Daten mit neuen entstand, deren Zeiten sich verschoben hatten. Also ebenfalls ein Mittel zur "Radikal-Aktualisierung". Angenommen, ein Anwender hat diese Einstellung aktiviert. Beim EPG-Update liefert ein Sender aber plötzlich keine EPG-Daten mehr - solche zeitweiligen Ausfälle hat es schon gegeben. Bei der Auto-Timer-Suche werden nun zunächst reihenweise Timer für diesen Sender gelöscht, aber anschließend nicht neu erzeugt, weil der EPG des Senders ja nun leer ist... und es lassen sich weitere Fälle konstruieren, in denen nach dem Löschen von Timern eine anschließende Neu-Erzeugung scheitert. Solche Eventualitäten sind zwar eher unwahrscheinlich, aber nicht unmöglich.

 

vor 9 Stunden schrieb HaraldL:

finde ich, daß es pro Timer ein Flag geben müsste ob er manuell angefasst wurde und dann NICHT gelöscht wird.

 

Dann die Frage, was mit Timern passieren soll, die eine Suchvorgabe automatisch erzeugt, aber die der Anwender danach "angefasst", also irgendwie geändert hat. Es gibt verschiedene Wege, die Timer-Eigenschaften beeinflussen - Editieren in einem der beiden Webinterfaces, aber auch das API, also von einem DVBViewer-Client, dem Kodi-Add-On oder dem DVBViewer Controller ausgehend. Ist das alles zu berücksichtigen? Und was heißt überhaupt "angefasst"? Wenn ein Timer durch einen Klick im Webinterface kurz (und vielleicht irrtümlich) deaktiviert und gleich wieder aktiviert wird, gilt er dann als "angefasst"?

 

Programmtechnisch ließen sich "angefasste" Timer leicht vom Löschen ausschließen. Es reicht eine modifizierte Quellenangabe, die nicht mehr mit dem Namen der Suchvorgabe übereinstimmt, z.B. Search:Nord bei Nordwest|modified. Nichtsdestotrotz stellt sich die Frage, ob die Radikal-Strategie "Löschen plus Neu-Erzeugung" wirklich angebracht ist.

 

Eine andere Strategie wäre, vorhandene Timer nicht in Bausch und Bogen zu verwerfen, sondern anhand der Ergebnisse einer Auto-Suche zu aktualisieren. Eventuelle EPG-Ausfälle oder auch Änderungen durch den Anwender wären so unproblematisch. Die Methode würde jedoch einen Kreuzvergleich zwischen alten und neuen Timern beinhalten, und vor allem auch ein Wiedererkennen von Sendungen, was auf bekannte Weise in Teufels Küche führt. Wenn die Öffentlich-Rechtlichen nicht mal mehr mit der PDC-Angabe zuverlässig und den DVB-Spezifikationen gemäß umgehen, die der Media Server bislang als sicheren Anker ansieht, wie soll man dann die Gleichheit von Sendungen sicher erkennen? Das war der Ausgangspunkt dieser Diskussion.

 

[HaraldL]

vor 57 Minuten schrieb Griga:

Du meinst wahrscheinlich "bei der EPG-Suche Timer für Sendungen, die nicht mehr gefunden werden, zu eliminieren".

Moment, bin grad beschäftigt, Haare spalten, ein paar hab ich noch 😉

 

vor 58 Minuten schrieb Griga:

Wenn ein Timer durch einen Klick im Webinterface kurz (und vielleicht irrtümlich) deaktiviert und gleich wieder aktiviert wird, gilt er dann als "angefasst"?

Meiner Meinung nach: Ja. Angefasst ist angefasst. Im Zweifelsfall lieber das Verhalten genau wie jetzt und ggf. eine Aufnahme zu viel als eine dadurch möglicherweise zu verlieren. Der Anwender ist dann ja selber "schuld" weil er den Timer angefasst hat. Genau den Fall hab ich immer wieder mal: Zwei Timer einer Sendung, einer abends, einer Wiederholung in der Nacht. Ich deaktiviere einen manuell. Entscheide mich dann aber um und aktiviere ihn wieder und deaktiviere den anderen. Dann soll das auch bei der nächsten Autosuche genau so bleiben.

 

Fehlendes EPG wäre tatsächlich ein Problem. Ich würde da aber keinen aufwendigen Kreuzvergleich machen sondern vielleicht ist es möglich beim Löschen der alten (aber nicht angefassten) Timer pro Timerquelle jeweils zu testen ob für diesen Zeitpunkt und den Sender ein EPG vorliegt, egal was genau. Ist was da -> Timer löschen, wenn nicht -> stehen lassen. Und danach dann vom EPG neue Timer für diese Timerquelle anlegen nach dem System genau wie bisher.

 

Aber wenn es zu komplex wird dann bitte besser lassen wie jetzt. Lieber mal eine Aufnahme zu viel, z.B. zwei zeitversetzte Aufnahmen der gleichen Sendung wo man danach halt eine löscht als daß Timer "verloren" gehen und z.B. eine Folge einer Serie dann gar nicht aufgenommen wird. Ich persönlich bin mit dem derzeitigen Zustand recht zufrieden, das hier beschriebene wäre jetzt für mich halt nur ein klein wenig "Komfort" für wenige Sonder-Situationen.

[Griga]

vor 10 Stunden schrieb HaraldL:

bin grad beschäftigt, Haare spalten,

 

An derartigen begrifflichen Spitzfindigkeiten scheitern mitunter Anwender, die dann posten "Ich habe einen Timer für die Sendung XYZ programmiert, aber wieder gelöscht. Trotzdem nimmt der Media Server die Sendung weiter auf. Wie kann ich das abstellen?"

 

Der Zauberlehrling-Effekt... die ich rief, die Geister, werd’ ich nun nicht los. Eine der unbeliebtesten Erscheinungen beim Umgang mit Computern. Der Anwender hat natürlich keinen Timer programmiert, sondern eine Suchvorgabe, die automatisch Timer erzeugt - ein Unterschied, der manche überfordert. Wenn der Anwender die Vorgabe löscht, sind die Timer noch vorhanden. Er muss sie zusätzlich löschen. Aber woher soll er das wissen? Zur Vorgabe gehören auch Timer-Eigenschaften, die sie im Webinterface wie eine Art erweiterter Timer aussehen lassen. Und ist es so abwegig, anzunehmen, dass der Media Server weitere Aufnahmen der Sendung  unterlässt, wenn man sie löscht?

 

Das war das ursprüngliche Motiv für die Einführung eines Buttons, der die von einer Suchvorgabe erzeugten Timer eliminiert (z.Z. erst in einer internen Beta). Zu anderen Aspekten komme ich später, habe gerade nicht genug Zeit...

 

[Griga]

Am 2.8.2024 um 08:04 schrieb Griga:

Das war das ursprüngliche Motiv für die Einführung eines Buttons, der die von einer Suchvorgabe erzeugten Timer eliminiert (z.Z. erst in einer internen Beta).

 

Jetzt weiter im Text.

 

Mit dem "Proof of Concept" im obigen Zitat lässt sich schon einiges anfangen. Zum Beispiel alle von einer Suchvorgabe erzeugten Timer löschen, wenn es z.B. viel mehr sind und für ganz anderen Sendungen, als man eigentlich haben wollte. Die neue Löschfunktion gibt Gelegenheit, die Suchvorgabe zu korrigieren und es erneut zu probieren, ohne dass man unzählige Timer auf der Timerseite manuell löschen muss.

 

Außerdem kann man so die in diesem Post erwähnte "Radikal-Aktualisierung" automatisch erzeugter Timer manuell anstoßen, indem man auf der Seite "EPG-Suche" des Webinterface erst auf "Timer löschen" und dann auf "Timer erzeugen" klickt - allerdings geht das immer nur für eine einzelne Suchvorlage, nicht für alle zusammen. Eine Berücksichtigung nachträglich vom Anwender modifizierter Timer ist dabei (noch) nicht vorgesehen.

 

Es fragt sich nun, ob die Löschfunktion aufgrund ihres praktischen Nutzens bei bestimmten Gelegenheiten automatisch tätig werden soll. Zum Beispiel, indem sie, wenn der Anwender eine Suchvorgabe löscht, auch alle zugehörigen Timer eliminiert, weil das viele intuitiv erwarten (siehe letzter Post). Allerdings ist ein unaufgefordertes Löschen immer etwas riskant - es kann Situationen geben, in denen Anwender das nicht möchten. Also eine Sicherheitsabfrage "Sollen auch die dazugehörigen Timer gelöscht werden"?

 

Das wird dann für den Programmierer ungemütlich. Die Abfrage muss JavaScript-Code im Browser realisieren, wenn jemand auf der Webinterface-Seite "EPG-Suche" auf Löschen klickt, und der Code muss vorab wissen, ob es überhaupt betroffene Timer gibt, damit er nicht umsonst nachfragt. Und das ganze in zwei Webinterface-Varianten (Desktop und Mobil). Wobei mir gerade einfällt, dass es den Button "Timer löschen" im Mobil-Webinterface noch gar nicht gibt. Dort herrscht Platzmangel. Ich weiß nicht, wohin damit.

 

Und natürlich die oben diskutierte Frage: Sollen vor jeder automatischen Timer-Erzeugung zuvor automatisch erzeugte Timer zwecks Radikal-Aktualisierung ebenso automatisch gelöscht werden? Außer den vorher vom Anwender manuell modifizierten? Bislang verzichtet der DMS grundsätzlich auf die automatische Erzeugung eines Timers für eine Sendung, wenn es für diese bereits einen Timer gibt. Eine Sendung erkennt der DMS aufgrund folgender Merkmale wieder:

• wenn der Sender übereinstimmt (gleiche Sender-ID)

und

• wenn der PDC-Wert übereinstimmt (sofern vorhanden)

oder

• wenn die Event ID übereinstimmt (und der Event ID-Vergleich durch einen Tweak ermöglicht wurde)

oder

• wenn es eine ausreichende zeitliche Überschneidung gibt (auf die Angabe der komplizierten Details der Berechnung verzichte ich hier).

Die Nachteile:

• Wenn der PDC-Wert (oder auch mit Tweak die Event ID) verschieden ist, geht der DMS immer davon, dass es sich um unterschiedliche Sendungen handelt, selbst bei aus menschlicher Sicht augenscheinlich identischen. Dass sich der PDC-Wert oder die Event ID für ein und die selbe Sendung ändert, dürfte nach den DVB-Spezifikationen nie passieren, aber der entsprechende Sachverstand und die Kontrolle ist bei den Sendern oft erschreckend gering. So entstehen die in diesem Thema beklagten doppelten Timer.
• Wenn ein Timer z.B. drei Wochen vor Beginn der Sendung erzeugt wird, weil der EPG so lange voraus reicht, finden nachfolgende EPG-Änderungen keinen Eingang mehr in den Timer. Das kann ebenso ein ausführlicherer Untertitel sein wie geänderte Zeiten. Letztere werden nur aktualisiert, wenn für den Timer eine EPG-Überwachung aktiv ist, und das geht wiederum (standardmäßig) nur bei vorhandenem PDC-Wert, also bei den öffentlich-rechtlichen.

Die Nachteile lassen sich durch die von @HaraldL empfohlene Eingrenzung des Datumbereichs auf today...today+2 deutlich abmildern (siehe hier), aber nicht ganz vermeiden. Eine Radikal-Aktualisierung durch automatisches Löschen zuvor automatisch erzeugter Timer würde praktisch den Datumsbereich zwangsweise kleinstmöglich halten und Timer möglichst aktuell erzeugen. Zuvor erzeugte Timer hätten nur informativen Wert, da sie ja bei jeder Auto-Suche wieder verschwinden bzw. ersetzt werden. Es fragt sich übrigens, wie Add-Ons und Clients damit zurechtkommen, die sich mit DMS-Timern befassen (DVBViewer, Kodi, DVBViewer Controller). Jeder Timer hat eine eindeutige ID. Wenn ein Timer gelöscht und neu erstellt wird, bekommt er eine andere, ist also nicht mittels ID wiedererkennbar.

 

Bleiben nun zuvor automatisch erzeugte Timer ungelöscht, weil der Anwender sie zwischenzeitlich manuell modifiziert hat, würde bei diesen wieder die alte Methode greifen, d.h. sie blieben auf jeden Fall stehen und würden eine Neuerstellung verhindern, oder wenn nicht, zu doppelten Timern führen - siehe oben.

 

Soweit erst mal für heute...

 

[Trill Ian]

vor einer Stunde schrieb Griga:

ig werden soll. Zum Beispiel, indem sie, wenn der Anwender eine Suchvorgabe löscht, auch alle zugehörigen Timer eliminiert, weil das viele intuitiv erwarten (siehe letzter Post).

Auf keinen Fall! Es kommt hier nicht selten vor, dass ich die Suchvorgabe schon lösche, obwohl die letzte Folge noch nicht gelaufen ist (aber der Timer schon existiert). Das wäre dann ein Eigentor 😞

Am 1.8.2024 um 21:17 schrieb HaraldL:

Meiner Meinung nach: Ja. Angefasst ist angefasst. Im Zweifelsfall liebe

Meiner Meinung nach: Nein 🙂

Die (De)Aktivierung kann ja jeder (auch aus Versehen) auf der Weboberfläche mit einfachem Klick besorgen. Unter "angefasst" verstehe ich da schon eher Detailänderungen wie Titel, Vor- Nachlauf, Senderliste usw. Dazu muss man den Timer explizit öffnen, drin rummatschen und noch mit "Ok" bestätigen. Bei "Abbruch" natürlich auch NICHT "angefasst".

 

[Griga]

vor 17 Stunden schrieb Trill Ian:

Auf keinen Fall!

 

Every change breaks someone's workflow. Es ist gut, vorab zu wissen, bei welchen Anwendern das der Fall ist, so dass man sie rechtzeitig im Forum sperren kann

 

vor 17 Stunden schrieb Trill Ian:

Unter "angefasst" verstehe ich da schon eher Detailänderungen wie Titel, Vor- Nachlauf, Senderliste usw. Dazu muss man den Timer explizit öffnen, drin rummatschen und noch mit "Ok" bestätigen.

 

In dem Dialog gibt es weder OK noch Abbruch, sondern nur Speichern, was im Browser ein Submit der angezeigten/eingegebenen Daten auslöst. Abbruch ist, wenn man das Fenster mit einem Klick außerhalb zum Verschwinden bringt. Und wenn nun jemand auf Speichern klickt, ohne vorher etwas zu ändern? Muss der DMS-Code nach einem Submit jede einzelne Timer-Eigenschaft darauf überprüfen, ob sie sich geändert hat? Ebenso bei /api/timeredit.html? Leider habe ich keinen Praktikanten, dem ich eine solche Fleißarbeit aufdrücken kann. Deshalb wäre ich geneigt, bei Speichern und einem entsprechenden API-Aufruf den Timer auf jeden Fall als "angefasst" zu betrachten.

 

[Trill Ian]

vor 2 Minuten schrieb Griga:

Deshalb wäre ich geneigt, bei Speichern und einem entsprechenden API-Aufruf den Timer auf jeden Fall als "angefasst" zu betrachten.

Dann mach doch neben dem "Speichern" Knopf noch einen mit "Abbruch". muss ja nix anderes tun, als "daneben geklickt" aufzurufen

 

[HaraldL]

Was wäre denn das "Schlimmste" was passiert wenn ein Timer als angefasst betrachtet wird?

- Wenn sich der Zeitpunkt der Ausstrahlung nicht ändert -> gar nichts, Aufnahme wie geplant falls Timer aktiv

- Wenn sich der Zeitpunkt ändert aber per EPG vor Aufnahme korrigiert wird -> gar nichts, Timer wird korrigiert wie jetzt und Aufnahme findet statt falls Timer aktiv

- Wenn sich der Zeitpunkt ändert aber nicht rechtzeitig korrigiert werden kann -> Aufnahme versetzt, ggf. abgeschnitten wie jetzt. Daran würde auch die oben angedachte Logik nichts ändern. Käme die Info per EPG rechtzeitig wäre es der Fall davor

- Wenn sich der Zeitpunkt zu weit verschiebt oder der Sender Details ändert -> Zweiter Timer, doppelte Aufnahme genau wie jetzt. DAS würde die angedachte Logik verhindern wenn der Timer nicht angefasst ist weil der "falsche" dann gelöscht würde

- Wenn die Sendung wegfällt -> Timer bleibt stehen statt mit neuer Logik entfernt zu werden. Also genau wie jetzt, Aufnahme würde stattfinden was halt gerade läuft

 

Also nur die letzten beiden Punkte wären anders wenn ich nichts übersehen habe. In beiden Fällen ggf. eine Aufnahme zu viel die man dann halt löscht. Besser als daß was nicht aufgenommen wird.

 

Ob das von Griga angesprochene Problem mit neuen Timer-IDs bezüglich Kodi usw. problematisch sind kann ich aber nicht beurteilen. Wie oben schon geschrieben, falls es zu viele oder neue Probleme macht dann besser so lassen wie es jetzt ist.

[Griga]

vor 4 Stunden schrieb Trill Ian:

Dann mach doch neben dem "Speichern" Knopf noch einen mit "Abbruch"

 

Das wäre der einzige im Webinterface. Vielleicht der einzige in sämtlichen Webseiten weit und breit. Abbruch-Buttons gibt es nur noch in Old School-UIs.

 

vor 9 Minuten schrieb HaraldL:

Was wäre denn das "Schlimmste" was passiert wenn ein Timer als angefasst betrachtet wird?

 

Kurz gesagt, dass mit ihnen verfahren wird, wie zur Zeit noch mit allen. Es kommt aber eine gewisse Inkonsistenz ins Spiel. Mit manchen automatisch erzeugten Timern wird so verfahren, mit anderen anders. Das ist für Anwender undurchsichtig. Sie haben insbesondere keine Gelegenheit, den "Angefasst"-Status zurückzusetzen, außer durch Stoppen des DMS und Editieren des Source-Eintrags in der svctimers.xml.

 

Ein noch nicht berücksichtigtes Problem bei kompletter Timer-Neuerzeugung ist die Option "Mail senden, wenn durch Autosuche neue Timer hinzugefügt werden". Ist sie aktiviert, gibt es nach jeder Autosuche sehr inhaltsreiche Post, da kein Vergleich des vorherigen Timer-Bestands mit dem neuen stattfindet. Im Grunde ist die Funktion damit sinnlos.

 

[Trill Ian]

vor 50 Minuten schrieb Griga:

Das wäre der einzige im Webinterface. Vielleicht der einzige in sämtlichen Webseiten weit und breit. Abbruch-Buttons gibt es nur noch in Old School-UIs.

Ein Alleinstellungsmerkmal von hohem Wiedererkennungswert 🤩

Dann schreib doch einfach ins Fenster "Zum Abbruch NEBEN das Fenster klicken!" (auch nicht viel hübscher).

 

Bei euer ganzen Diskussion um das "wann ist ein Timer angepasst" Thema scheint mir langsam der ursprüngliche Sinn verloren gegangen zu sein:

* Wenn eine Sendung ausfällt und im EPG dafür eine andere auftaucht, sollte der ursprüngliche, nun falsche, Timer gelöscht werden.

 

Passiert derzeit zuhauf auf den 3ten der Öffis, ist ein echter Run drauf...

 

[Griga]

vor 12 Minuten schrieb Trill Ian:

Wenn eine Sendung ausfällt und im EPG dafür eine andere auftaucht,

 

Das berührt das Grundproblem: Wie soll der DMS feststellen, ob die Sendung eine andere ist? Oder anders gesagt: Wie kann er eine Sendung wiedererkennen? Menschen können das i.a, selbst wenn sich die Sendezeit deutlich verschoben hat, der Titel um weiteren Text ergänzt und der Untertitel geändert wurde... und auch feststellen, dass die Sendung durch eine andere ersetzt wurde. Der DMS scheitert immer mal wieder daran. Braucht es KI, um das zu lösen?

 

Die Diskussion hier befasst sich mit einer Strategie, die unzuverlässige Wiedererkennung beim Vergleich von EPG-Einträgen mit bereits vorhandenen Timern möglichst zu vermeiden. Es werden einfach alle aus einer Suchvorgabe resultierenden Timer gelöscht und anhand aktueller EPG-Daten neu erstellt. Dabei ist kein Vergleich nötig. Aber es ergeben sich andere Probleme. Was tun mit vom Anwender modifizierten Timern und der EMail-Benachrichtigung?

 

Optimal wäre, wenn der DMS Sendungen mit ausreichender Zuverlässigkeit wiedererkennen (bzw. ihr Fehlen feststellen) könnte. Die bislang verwendete Methode habe ich hier geschildert. Hier noch mal die für einen Vergleich in Frage kommenden Parameter im Überblick:

1. Der Sender, identifiziert durch seine Sender ID.
2. PDC und Event ID. Sie sollten eigentlich bei Gleichheit die Gleichheit einer Sendungen garantieren, tun es aber in der Praxis aufgrund von Schlampereien in manchen Sendeanstalten nicht zuverlässig.
3. Die Sendezeit und Dauer der Sendung. Sie können sich bei jedem EPG-Update ändern, insbesondere die Sendezeit sogar drastisch.
4. Titel und Untertitel der Sendung im EPG, die der DMS bislang noch nicht für eine Widererkennung verwendet. Auch sie können sich jederzeit ändern.

Für einen EPG-Eintrag einen bereits vorhandenen Timer zu finden (oder umgekehrt), entspricht einer Ähnlichkeitssuche in einer Datenbank. Dazu gibt es eine Menge Material im Web. Es läuft darauf hinaus, einen Ähnlichkeitswert zwischen den zu vergleichenden Datensätzen zu berechnen. Beträgt er 1, sind sie identisch, bei 0 in jeder Hinsicht verschieden. Den Ähnlichkeitswert liefert eine Vergleichs- bzw. Bewertungsfunktion, in der wiederum Ähnlichkeiten zwischen den obigen einzelnen Parametern gewichtet eingehen, also um so mehr, je wichtiger sie sind.

 

In der Praxis wird man so häufig Werte zwischen 1 und 0 erhalten. Dann braucht es einerseits eine Suche nach dem EPG-Eintrag mit maximaler Ähnlichkeit zu einem gegebenen Timer, und dazu einen Schwellwert, ab dem man davon ausgehen kann, dass es sich um die gleiche Sendung handeln könnte. Für Zeichenketten wie Titel und Untertitel gibt es im DVBViewer und DMS bereits einen Ähnlichkeitsalgorithmus (Ratcliff Pattern Recognition), der bislang nur der Zuordnung von Logo-Dateinamen zu Sendern dient. Damit ist es aber nicht getan. Das Problem ist, dass Bewertungfunktionen für eine solche Thematik meist über einen längeren Zeitraum heuristisch (aufgrund von Erfahrungswerten) entstehen und immer wieder anhand der Ergebnisse, die sie in verschiedenen Situationen liefern, optimiert werden müssen. Man kann sie nicht ad hoc aus dem Ärmel schütteln, da es keinen exakten und allgemeingültigen mathematischen Ansatz gibt. Für eine erste Version könnte ich nur von Annahmen ausgehen, die sich womöglich als nicht zutreffend erweisen.

 

[Trill Ian]

vor einer Stunde schrieb Griga:

Wie soll der DMS feststellen, ob die Sendung eine andere ist?

Ihr denkt einfach zu kompliziert...

Ein alter Timer ist zu ersetzen wenn (alles muss zutreffen, aka "UND"):

 

• Das Progamm gleich ist
• Anfangszeit identisch oder mit konfigurierbarer Toleranz (z.B "innerhalb von 10min")
• Endzeit identisch oder mit konfigurierbarer Toleranz (z.B "innerhalb von 10min") oder egal (kann ja ne 30min Sendung durch einen Spielfilm ersetzt worden sein)

Namen, Pids usw dürfen keine Rolle spielen.

[Griga]

Die bisher im DMS implementierte Wiedererkennung von Sendungen aufgrund der Anfangszeit und Dauer werde ich nicht ändern, da sie sich alles in allem bewährt hat. Sie funktioniert im Prinzip so: Ein EPG-Eintrag gilt als durch einen Timer abgedeckt, wenn der Sender übereinstimmt und die Sendung laut EPG komplett innerhalb der Brutto-Aufnahmezeit liegt (mit Vor und Nachlauf) und sie sich mindestens um ihre halbe Dauer mit der Netto-Aufnahmezeit (ohne Vor- und Nachlauf) überschneidet.

 

Dieser Zeitvergleich kommt allerdings nur bei Sendungen ohne PDC zur Geltung (also konkret bei Privatsendern), da sonst der PDC-Vergleich Vorrang hat. Die Vergleichsfunktion verwendet der DMS nicht nur bei der automatischen Timer-Erzeugung, sondern auch im Webinterface auf allen EPG-Seiten, da diese durch Timer abgdeckte Sendungen markieren bzw. den Aufnahmebutton weglassen.

 

Eine Alternative zu dem bislang diskutierten kompletten Löschen aller durch eine Suchvorlage erzeugten Timer vor einer Neuerzeugung könnte so aussehen:

• Findet sich für eine (der Suchvorlage entsprechenden) Sendung kein vorhandener (zuvor von der gleichen Suchvorlage erzeugter) Timer, wird er neu erzeugt und intern als "gefunden" markiert. Andernfalls wird der vorhandene Timer aktualisiert und ebenfalls intern als "gefunden" markiert. Die Aktualisierung kann auf zweierlei Weise geschehen:
  • Mit den Daten aus dem EPG-Eintrag (Startzeit, Dauer, Titel, Untertitel, Event ID). Das sollte IMO auf jeden Fall geschehen.
  • Mit den Daten aus der Suchvorlage (Vor/Nachlauf, Aktion nach Aufnahme, Namensschema usw.). Die Suchvorlage kann sich ja auch geändert bzw. der Anwender dort Korrekturen durchgeführt haben. Allerdings würde diese Aktualisierung auch Eigenschaften überschreiben, die der Anwender bei einem einzelnen Timer manuell geändert hat.
• Wenn eine Suchvorlage abgearbeitet ist, werden danach alle von dieser Suchvorlage zuvor erzeugten Timer gelöscht, die nicht als "gefunden" markiert sind, d.h. deren Sendungen nicht im EPG wiedergefunden wurden - unabhängig davon, ob sie der Anwender "angefasst" hat oder nicht. Zuvor müsste man eventuell noch sicherstellen, dass es überhaupt EPG-Daten für den betreffenden Sender gibt.

Was kann dabei passieren?

• Angenommen, bei einer Sendung ändert sich entgegen den DVB-Spezifikationen der PDC-Wert (das war der Ausgangspunkt in dieser Diskussion), und sie wird deshalb nicht wiedergefunden. Dann würde der obige Ablauf einen neuen Timer erzeugen und den alten für die gleiche Sendung löschen, da nicht mehr gefunden.
• Angenommen, eine Sendung kommt gar nicht mehr im EPG vor. Dann verschwindet der Timer einfach.
• Angenommen, eine Sendung ohne PDC verschiebt sich so weit, dass sie nicht mehr vollständig in der Brutto-Aufnahmezeit des Timers liegt. Dann passt der Timer nicht mehr. Jetzt können zwei Sachen passieren:
  • Die Auto-Suche findet keine Sendung, die in die Timerzeit passt. Dann verschwindet der Timer. Findet die Auto-Suche die Sendung zu einem anderen Zeitpunkt, wird dafür ein neuer Timer erzeugt.
  • Die Auto-Suche findet eine zeitlich passende andere Sendung (z.B. eine andere Folge einer Serie - die Privaten senden oft mehrere hintereinander). Dann wird der Timer auf die andere Sendung aktualisiert. Das wäre wohl unerwünscht, lässt sich aber nicht vermeiden, außer man bezieht auch Titel und Untertitel in den Vergleich ein. Für die eigentlich gewünschte Sendung wird wahrscheinlich ein neuer Timer erzeugt.

Insgesamt sieht das für mich gut aus. Oder kann jemand einen Fall konstruieren, bei dem die Vorgehensweise eine gewünschte Aufnahme verhindert?

 

[Trill Ian]

Ist mir etwas zu hoch. Ich will eigentlich nur, dass der Anzeige und Dateiname geändert wird. Bislang läuft der Timer und auch der Speichername wie bisher auf dem alten Eintrag, erst beim Blick in die Infodatei (oder beim Schnitt) merkt man, dass da was ganz anderes auf der Platte gelandet ist.

 

[HaraldL]

vor 7 Stunden schrieb Trill Ian:

Ich will eigentlich nur, dass der Anzeige und Dateiname geändert wird.

Dann kommen sofort Beschwerden "Warum hat der DVBViewer die Sendung 'Fußball' aufgenommen obwohl ich doch einen Timer für den 'Musikantenstadl' angelegt hatte? Ich hatte ganz sicher keinen Timer für 'Fußball' angelegt, wo kommt der her?". Also hat für die der DVBViewer dann scheinbar was falsch gemacht. Wenn die Aufnahme "Musikantenstadl" heißt und beim Anschauen ist Fußball drin ist jedem klar der Sender hat um die Zeit halt was anderes gesendet.

 

Du willst also nach deiner Beschreibung gar keine intelligente Korrektur wenn ein Sender was ändert sondern einfach die falsche Aufnahme ohne Rücksicht auf Verluste laufen lassen aber das Ergebnis umbenennen? Für Anwender die sonst zu wenig verwirrt sind?? Warum sollte man eine falsche Sendung ÜBERHAUPT aufnehmen wenn es wie oben beschrieben ggf. Möglichkeiten gibt (nicht immer aber in manchen Fällen) das zu korrigieren?

[Trill Ian]

vor 1 Minute schrieb HaraldL:

Du willst also nach deiner Beschreibung gar keine intelligente Korrektur wenn ein Sender was ändert sondern einfach die falsche Aufnahme ohne Rücksicht auf Verluste laufen lassen aber das Ergebnis umbenennen? Für Anwender die sonst zu wenig verwirrt sind?? Warum sollte man eine falsche Sendung ÜBERHAUPT aufnehmen wenn es wie oben beschrieben ggf. Möglichkeiten gibt (nicht immer aber in manchen Fällen) das zu korrigieren?

Nein nein, ich will schon bei Ersatz den Timer weghaben, aber, wenn Griga hier so auf die Tränendrüsen drückt, würde es reichen, die Texte anzupassen, weil dann jeder sofort sieht, dass da was falsch gelaufen ist. Und, er kann ja immer noch über den Eintrag hovern und sieht dann im Tooltip, woher dieser Timer ursprünglich stammt.

Oder meinetwegen in die Textdatei oben mit reinschreiben: "Ersatz für Musikantenstadl" (SCHAUDER!) oder "Ersatz für Fußball!" (ebenfalls SCHAUDER).

 

Und, egal wie toll und clever Du es machst, es wird immer einen geben, dem es nicht gefällt oder der es nicht kapiert. Damit muß man bei der Gestaltung von Software leben.

"Man kann ein Programm nicht idiotensicher machen, da Idioten sehr erfinderisch sind".

 

 

[HaraldL]

vor 19 Minuten schrieb Trill Ian:

 Und, er kann ja immer noch über den Eintrag hovern und sieht dann im Tooltip, woher dieser Timer ursprünglich stammt.

Das schafft/weiß geschätzt maximal einer von Tausend Usern, der Rest beschwert sich hier.

 

vor 20 Minuten schrieb Trill Ian:

"Ersatz für Musikantenstadl" (SCHAUDER!) oder "Ersatz für Fußball!" (ebenfalls SCHAUDER).

Genau darum hab ich diese beiden Begriffe gewählt weil beide auch bei mir ganz sicher nie in der Timerliste auftauchen werden 😉

 

vor 21 Minuten schrieb Trill Ian:

"Man kann ein Programm nicht idiotensicher machen, da Idioten sehr erfinderisch sind".

Korrekt. Ich programmiere im Job Mediensteuerungen (Crestron und Extron, für Konferenzräume, Hörsäle, Hotels usw.) mit Touchpanel-Bedienung für Displays, Beamer, Licht, BluRay, TV, Kameras, Verdunkelung, Leinwand usw. und oft wenn ich glaube fertig zu sein lass ich Kollegen damit "spielen" und immer mal wieder schafft einer was Verrücktes das ich dann noch extra berücksichtigen muß.

[Griga]

vor 24 Minuten schrieb HaraldL:

"Warum hat der DVBViewer die Sendung 'Fußball' aufgenommen obwohl ich doch einen Timer für den 'Musikantenstadl' angelegt hatte?

 

Ein derartiger Austausch von Timern ist bei den hier besprochenen Strategien sehr unwahrscheinlich, weil sie sich immer auf eine bestimmte Suchvorlage beziehen. Es kann im Timer höchstens eine Sendung gegen einen andere ausgetauscht werden, die die selbe Suchvorlage ermittelt. Wer Suchbegriffe wie Fußball|Musikantenstadl formuliert, wird allerdings die Folgen tragen müssen...

 

vor 26 Minuten schrieb Trill Ian:

ich will schon bei Ersatz den Timer weghaben

 

Darauf zielt meine letzte Überlegung ab. Wenn mit der betreffenden Suchvorlage die Ersatzsendung nicht gefunden wird, verschwindet der Timer.

 

[Trill Ian]

vor 5 Minuten schrieb Griga:

enn mit der betreffenden Suchvorlage die Ersatzsendung nicht gefunden wird, verschwindet der Timer.

ok, kann ich mit leben. werden sich einige aber doch wundern und fragen, wohin der timer verschwunden ist.

[Griga]

Am 6.8.2024 um 10:33 schrieb Griga:

Eine Alternative zu dem bislang diskutierten kompletten Löschen aller durch eine Suchvorlage erzeugten Timer vor einer Neuerzeugung könnte so aussehen: (...) Insgesamt sieht das für mich gut aus. Oder kann jemand einen Fall konstruieren, bei dem die Vorgehensweise eine gewünschte Aufnahme verhindert?

 

Der Fall lässt sich sehr leicht konstruieren. Oder besser gesagt, er hat sich nach einer Testimplementation selbst konstruiert, als Folge eines typischen Denkfehlers. Erläutern lässt sich das am besten anhand eines Beispiels:

• Eine Autosuche mit einer bestimmten Suchvorlage findet eine Sendung ABC und erzeugt einen (aktivierten) Timer mit dem PDC-Wert XYZ.
• Beim nächsten Durchlauf hat sich der PDC-Wert der Sendung geändert (genauer gesagt habe ich ihn für den Test in der svctimers.xml gefälscht), d.h. die Autosuche erkennt nicht mehr, dass der Timer die Sendung abdeckt.
• Die Autosuche erzeugt deshalb einen neuen Timer für die Sendung ABC (was bislang zu einem Doppeleintrag führt). Aufgrund der Option "Deaktivieren bei gleichem EPG Titel/Untertitel in Aufnahme-Timern" wird der neue Timer deaktiviert, weil ja noch der alte mit gleichem Titel und Untertitel vorhanden ist.
• Zum Abschluss löscht die neue Auto-Such-Methode den alten Timer, da er zu keiner Sendung mehr passt. Übrig bleibt ein deaktivierter Timer für die gewünschte Aufnahme.

Fazit: Die neue Autosuch-Methode darf bei der Deaktivierung von Timern keine beim vorherigen Durchlauf von der selben Suchvorlage erzeugten Timer einbeziehen, solange diese noch nicht aktualisiert sind bzw. die Sendung nicht wiedergefunden wurde. Die Autosuche muss so tun, als wären diese Timer nicht vorhanden, weil man sonst am Ende (bei eingeschaltetem Abgleich mit Titel/Untertitel von vorhandenen Timern) nur deaktivierte Timer erhält. Auch bei Timern, die nur aktualisiert werden, weil die Autosuche die Sendung wiedererkennt, muss der Aktiviert/Deaktiviert-Status neu ermittelt werden, nicht nur bei neu hinzugekommenen Timern. Allerdings: Wer manuell automatisch erzeugte Timer aktiviert/deaktiviert, wird feststellen, dass der DMS es bei der nächsten Autosuche wieder rückgängig macht. Das ist unschön, und dafür habe ich noch keine Lösung.

 

Ansonsten funktioniert die Angelegenheit nach Korrektur des obigen Punktes gut. Zum Beispiel hat der Suchbegriff "CSI: Miami" die folgenden Timer erzeugt:

 

 

Danach habe ich den DMS gestoppt und in der svctimers.xml auf verschiedene Weise die Startzeiten gefälscht, bis hin zu einem anderen Aufnahmedatum. Nach einem DMS-Neustart plus erneuter Autosuche war in jedem Fall alles wieder richtig. Es gab keine Doppeleinträge. Nur das Vertauschen zweier Sendezeiten führte zu einer falschen Untertitel-Zuordnung.

 

Im Grunde stellt die neue Autosuch-Methode eine Art EPG-Überwachung dar, auch für Sender ohne PDC. Bei jeder Autosuche erfolgt eine Anpassung der Timer an die aktuellen EPG-Daten.

 

[Griga]

vor 5 Stunden schrieb Griga:

Auch bei Timern, die nur aktualisiert werden, weil die Autosuche die Sendung wiedererkennt, muss der Aktiviert/Deaktiviert-Status neu ermittelt werden, nicht nur bei neu hinzugekommenen Timern. Allerdings: Wer manuell automatisch erzeugte Timer aktiviert/deaktiviert, wird feststellen, dass der DMS es bei der nächsten Autosuche wieder rückgängig macht. Das ist unschön, und dafür habe ich noch keine Lösung.

 

Es ist bei der neuen Autosuch-Methode möglich, den Aktiviert/Deaktiviert-Status von Auto-Timern bei einer Aktualisierung unverändert zu lassen oder neu zu ermitteln - ich habe beide Varianten probiert, und bei beiden gibt es unschöne Fälle, in denen letztendlich etwas anderes passiert, als der Anwender (vermutlich) möchte.

 

Eine Verbesserung ist wohl nur möglich, wenn ein neues dauerhaft gespeichertes Flag in Timern besagt, ob der Aktiviert/Deaktiviert-Status durch eine Autosuche oder nachträglich durch den Anwender hergestellt wurde. Im ersteren Fall wird der Status bei einer Aktualisierung gemäß der Suchvorgabe neu ermittelt, im zweiten bleibt er unverändert.

 

Aber selbst das schützt nicht sicher vor ungewollten Folgen. Man betrachte die drei RTL-Timer im obigen Screenshot (jeweils mit 5 Minuten Vor- und 10 Minuten Nachlauf). Angenommen, der Anwender hätte den ersten und dritten Timer deaktiviert. Er möchte nur die zweite Sendung aufnehmen. Weiterhin stelle man sich vor, die Sendezeiten würden sich im EPG um 45 Minuten auf später verschieben, also ungefähr um die Dauer einer Sendung. Was passiert bei der nächsten Autosuche mit der neuen Methode?

• Die erste Sendung läuft nun zur ursprünglichen Zeit der zweiten. Der zweite Timer wird auf die erste Sendung aktualisiert und bleibt aktiviert.
• Die zweite Sendung läuft zur ursprünglichen Zeit der dritten. Der dritte Timer wird auf die zweite Sendung aktualisiert und bleibt deaktiviert.
• Für die dritte Sendung gibt es keinen passenden Timer. Es wird ein neuer aktivierter erzeugt und der erste Timer (zu dem keine Sendung mehr passt) gelöscht.

Das betrübliche Endergebnis: Der DMS nimmt die erste und dritte Sendung auf, die zweite jedoch nicht. Also genau umgekehrt, als gewünscht...

 

Worauf habe ich mich da bloß eingelassen

 

[HaraldL]

vor 7 Stunden schrieb Griga:

Fazit: Die neue Autosuch-Methode darf bei der Deaktivierung von Timern keine beim vorherigen Durchlauf von der selben Suchvorlage erzeugten Timer einbeziehen, solange diese noch nicht aktualisiert sind bzw. die Sendung nicht wiedergefunden wurde.

 

ich bin bisher davon ausgegangen daß bei der EPG-Suche dann neu zuerst die vorhandenen Timer getestet werden ob noch vorhanden/gültig und nicht passende gelöscht. Und erst danach das passiert was auch jetzt schon der Fall ist, neue Timer erstellen oder vorhandene anhand z.B. EPG korrigieren falls möglich. So würde es nicht passieren daß erst ein neuer Timer deaktiviert angelegt wird weil schon einer da ist der erst danach gelöscht wird weil nicht mehr gültig.

 

vor einer Stunde schrieb Griga:

Worauf habe ich mich da bloß eingelassen

 

Ich hab es ja schon 2x geschrieben: Im Zweifelsfall alles so lassen wie es ist. Funktioniert gut und ab und zu eine doppelte/falsche Aufnahme die man dann löscht, ich finde nicht daß das ein großer Beinbruch ist.

[Griga]

vor 11 Stunden schrieb HaraldL:

ich bin bisher davon ausgegangen daß bei der EPG-Suche dann neu zuerst die vorhandenen Timer getestet werden ob noch vorhanden/gültig und nicht passende gelöscht.

 

Nein, so funktioniert das nicht. Das wäre ein erheblicher programmtechnischer Mehraufwand.

 

Suchvorgaben produzieren quasi eine (gefilterte) Liste mit zu ihnen passenden EPG-Einträgen bzw. Sendungen. Diese werden dann nacheinander abgearbeitet. Als erstes überprüft die Autosuche, ob eine Sendung schon durch einen Timer abgedeckt ist. Falls ja, passiert bislang gar nichts. Falls nein, wird ein neuer Timer erzeugt. Die Nachteile sind bekannt: Es findet keine Aktualisierung der Timer statt, überflüssige Timer für ausgefallene Sendungen bleiben stehen, und es kommt zu Doppeleinträgen, falls der Test auf "schon abgedeckt" aufgrund eines geänderten PDC-Wertes oder einer zeitlichen Verschiebung fehlschlägt.

 

Die Idee war nun, vor der Abarbeitung der Liste einfach pauschal alle Timer zu löschen, die eine Suchvorgabe beim vorherigen Durchgang erzeugt hat, und so eine Neuerzeugung und damit komplette Aktualisierung zu erzwingen. Der Nachteil ist jedoch, dass beim Löschen manuell vorgenommene Änderungen an den Timern verloren gehen. Und dass die Mailbenachrichtigung über neu erzeugte Timer nicht mehr sinnvoll funktioniert.

 

Daraus entstand die nächste Idee: Timer, die eine Sendung abdecken und vorher durch die selbe Suchvorlage erzeugt wurden, werden mit den EPG-Daten aktualisiert (Zeit, Dauer, Titel, Untertitel...). Alle nicht aus dem EPG stammenden Timer-Eigenschaften, die der Anwender vielleicht abgeändert hat (Vorlauf, Nachlauf, Aktion nach Aufnahme...), bleiben unberührt. Aktualisierte und neue Timer werden dabei markiert. Am Ende schaut die Autosuche, ob unmarkierte Timer übrig sind, die die Suchvorgabe früher erzeugt hat, die aber nicht aktualisiert wurden, weil keine passende Sendung mehr existiert. Und die kann sie dann löschen. Das erspart es, dafür einen zusätzlichen Abgleich zwischen Timern und EPG-Daten durchzuführen.

 

Und jetzt bin ich mit den Problemen dieser Methode befasst. Ein Knackpunkt ist dabei insbesondere der Aktiviert/Deaktiviert-Status der Timer. Soll er auch aktualisiert werden oder unverändert bleiben?

 

Stelle dir vor, die Autosuche hat drei Timer für eine Sendung angelegt, die im Ersten sowie (zeitversetzt) im SWR und WDR läuft. Den Timer für die Sendung im Ersten hat die Autosuche aktiviert, die anderen beiden deaktiviert, weil man ja nur eine Aufnahme der Sendung braucht. Nun lässt aber das Erste aufgrund aktueller Ereignisse die Sendung ausfallen. Deshalb löscht die Autosuche beim nächsten Durchgang den dazugehörigen Timer, weil die Sendung nicht mehr im EPG steht. Es sind zwar noch zwei Timer für die Sendung im SWR und WDR übrig, aber die sind leider deaktiviert. Also wird die Sendung nicht aufgenommen, obwohl es möglich wäre.

 

Daraus folgt: Der Aktiviert/Deaktiviert-Status der Timer muss auch aktualisiert werden. Aber das hat ebenfalls unschöne Konsequenzen: Wenn der Anwender bestimmte Ergebnisse der Autosuche bewusst deaktiviert hat, weil er die Aufnahmen nicht haben will, wird die nächste Autosuche sie wieder aktivieren... und wenn der Anwender die Aufnahme der Sendung vom Ersten absichtlich deaktiviert und dafür die Aufnahme vom WDR aktiviert, weil er sie aus irgendeinem Grund lieber von diesem Sender haben will, macht die Autosuche das wieder rückgängig...

 

Deshalb:

 

vor 12 Stunden schrieb Griga:

Eine Verbesserung ist wohl nur möglich, wenn ein neues dauerhaft gespeichertes Flag in Timern besagt, ob der Aktiviert/Deaktiviert-Status durch eine Autosuche oder nachträglich durch den Anwender hergestellt wurde. Im ersteren Fall wird der Status bei einer Aktualisierung gemäß der Suchvorgabe neu ermittelt, im zweiten bleibt er unverändert.

 

[Bob.Dig]

Es wäre schön, wenn man in der WEB-GUI der Timer-Liste auch ganze Tage an-/abwählen könnte, also eine Checkbox auch in der Tageszeile bekäme. Damit könnte man dann mit drei Klicks alle Timer bis auf den aktuellen Tag löschen (Klick alle Timer, dann Klick aktueller Tag und dann Klick auf löschen).

 

Zurück zur letzten Diskussion: Es fällt mir schwer, dem im Detail zu folgen und daher hierzu Aussagen zu machen. Deswegen wiederhole ich einfach noch mal meinen (häufigen) Anwendungsfall. Ich gehe in einen durch eine Suchvorgabe erstellten Timer und ändere den Sender.

Würde nun durch eine unwesentliche Änderung des EPGs dieser von mir modifizierte Timer anschließend gelöscht und komplett neu erstellt werden, hätte ich ein Problem. 🙂

 

Edited August 8 by Bob.Dig

[Griga]

vor 2 Stunden schrieb Bob.Dig:

Ich gehe in einen durch eine Suchvorgabe erstellten Timer und ändere den Sender. Würde nun durch eine unwesentliche Änderung des EPGs dieser von mir modifizierte Timer anschließend gelöscht und komplett neu erstellt werden, hätte ich ein Problem.

 

Der würde mit der neuen Autosuch-Methode auf jeden Fall gelöscht, wenn die Suchvorgabe, die den Timer ursprünglich erzeugt hat, keine passende Sendung mehr für ihn liefert. Beispiel: Du programmierst einen Timer, den eine Suchvorgabe mit dem Suchbegriff "Tatort" für das Erste erzeugt hat, auf das ZDF um. Da es unwahrscheinlich ist, dass das ZDF zu dem betreffenden Zeitpunkt ein Sendung bringt, in deren Titel der Suchbegriff vorkommt, wird der Timer eliminiert.

 

Ausnahme: Wenn der neue Sender überhaupt keinen EPG hat, würde der Timer bestehen bleiben, weil ein kompletter EPG-Ausfall bei einem Sender in Betracht gezogen wird (siehe hier). Falls du zufällig einen für einen DVB-Sender erzeugten Timer auf einen äquivalenten Internet TV-Kanal umwidmest, könnte das zutreffen. In dem Fall würde ich jedoch überlegen, den EPG des DVB-Senders mittels EPGPairingList.txt auf den TS Stream-Kanal zu duplizieren. Dann findet die Autosuche die Sendung auch dort.

 

Aber erst mal abwarten, ob es die neue Autosuch-Methode bis ins Release schafft. Die Sache ist ja noch in einem experimentellen Stadium, und dein Post insofern von Wert, weil ich mir gar nicht alle merkwürdigen Sachen vorstellen kann, die Anwender so machen...