TAP: AutoExtender

[chrisly]

Das Problem ist eigentlich nur, dass Timer 1 wegen Konflikt zu früh beendet wird (in diesem Fall nicht schlimm - aber bei wichtigen Aufnahmen wäre es schon ärgerlich).
Ein Konflikt liegt aber nicht vor, weil nur 2 Timer vorhanden sind. Deshalb vermute ich, dass es irgendwie mit dem AX-Scan zusammenhängen könnte.

[FranzKM]

[quote="flechumer"]Was ist eigentlich das Problem? Beide Timer sind exkludiert, d.h. für beide gibt es keinen Vorlauf, keinen Abgleich und keine Verlängerung. Und weil es keinen Abgleich gibt, gibt es auch keine Pilotierung. Ist es das, was Du meinst?

Ansonsten würde ich jemanden, der hier mitliest und meint verstanden zu haben, was Du eigentlich für ein Problem hast, es mir aus seiner Sicht zu erklären.[/quote]

@chrisly
Wenn AX beim morgendlichen Scan nicht mitläuft, weiß AX es nicht, zudem hast Du die Timer excludiert, also macht AX hier gar nichts auch wenn es mitläuft. Wenn Timer gesetzt werden, sollte AX immer aktiv sein. Vllt solltest Du mal Deine neueste .ini posten!?

Ich arbeite nicht mit ScanTime (trotz durchgeschleift) und letzte Nacht war wieder alles OK. Ich weiß nicht, vllt ist meine Aufnahme-Art einfacher!?
PilotTimer sehe ich nur ab und zu, da sie m. W. nur gesetzt werden, wenn vor einem Timer 60+5+Vorlauf Min. Zeit ist.

Das einzige was mich stört ist, dass beim Anschauen von Aufnahmen mit dem PilotT und auch bei R-Timern das Play abgebrochen wird. das ist aber kein AX-Problem.

[flechumer]

[quote="chrisly"]Das Problem ist eigentlich nur, dass Timer 1 wegen Konflikt zu früh beendet wird (in diesem Fall nicht schlimm - aber bei wichtigen Aufnahmen wäre es schon ärgerlich).
Ein Konflikt liegt aber nicht vor, weil nur 2 Timer vorhanden sind. Deshalb vermute ich, dass es irgendwie mit dem AX-Scan zusammenhängen könnte.[/quote]

Warten wir mal ab, ob es wieder auftritt. Konfliktmanagement und EPG-Abgleich haben nicht viel miteinander zu tun. Das eine betrifft laufende Aufnahmen, das andere Timer. Ich sehe da zunächst keinen Zusammenhang.

[flechumer]

[quote="FranzKM"]Das einzige was mich stört ist, dass beim Anschauen von Aufnahmen mit dem PilotT und auch bei R-Timern das Play abgebrochen wird. das ist aber kein AX-Problem.[/quote]

Vielleicht kann ich daran noch etwas ändern, indem ich den zu erwartenden Pilottimer kurz vor seinem Start auf den gerade laufenden Kanal umprogrammiere. Ich schaue es mir an.

[FranzKM]

[quote="flechumer"]Vielleicht kann ich daran noch etwas ändern, indem ich den zu erwartenden Pilottimer kurz vor seinem Start auf den gerade laufenden Kanal umprogrammiere. Ich schaue es mir an.[/quote]

Das wäre schön, aber muss er dann nicht wieder auf den Kanal des pilotierten Timers umschalten? Ich habe mich schon richtig ausgedrückt: ich schaue da nicht LIVE, sondern von der HDD.

[flechumer]

[quote="FranzKM"]Das wäre schön, aber muss er dann nicht wieder auf den Kanal des pilotierten Timers umschalten? Ich habe mich schon richtig ausgedrückt: ich schaue da nicht LIVE, sondern von der HDD.[/quote]

Das habe ich verstanden. Trotz Playback gibt es einen aktuellen Tuner, der auf einen Kanal eingestellt ist. Nur wenn dieser umgeschaltet werden soll, kommt es zu dem von Dir beschriebenen Effekt. Wenn ich also den P-Timer rechtzeitig auf diesen Kanal umprogrammiere, sollte es nicht zur Umschaltung kommen.

[FranzKM]

Gut! -

Ich habe den Ablauf wie folgt verstanden, aus der Sicht eines AX-Anfängers:

Beispiel ohne ScanTime (Vorlauf 5 Min.):

-> 3PG-Scan 6:00-6:25
-> Timer1 7:00-8:00
-> Timer2 18:00-19:00
-> Timer3 20:00-21:00
-> Timer4 23:00-0:00

- AX startet mit 3PG-Scan, registriert Timer1, der in <70 Min. ist und verlängert/korrigiert Timer1 auf 6:55-8:00.
- 6:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer2 und da >70 Min. entfernt setzt er einen PilotTimer um 16:50.
- PilotTimer startet um 16:50 und verlängert/korrigiert Timer2 auf 17:55-19:00
- 17:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer3 und da <70 Min. entfernt setzt er keinen PilotTimer, sondern verlängert/korrigiert Timer3 auf 19:55-21:00
- 19:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer4 und da >70 Min. entfernt setzt er einen PilotTimer um 21:50.


Gleiches Beispiel mit ScanTime 16:45 (Vorlauf 5 Min.):
- Habe ich noch nicht getestet!

- AX startet mit 3PG-Scan, reg. Timer1, der in <70 Min. ist und verlängert/korrigiert Timer1 auf 6:55-8:00.
- 6:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer2 und da >ScanTime entfernt setzt er einen ScanTimer um 16:45.
- ScanTimer startet um 16:45 und verlängert/korrigiert Timer2 auf 17:55-19:00 und korrigiert die restlichen Timer ohne Vorlauf.
- 17:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer3 und da <70 Min. entfernt setzt er keinen PilotTimer, sondern verlängert/korrigiert Timer3 auf 19:55-21:00
- 19:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer4 und da >70 Min. entfernt setzt er einen PilotTimer um 21:50.

[flechumer]

Ich habe den Ablauf wie folgt verstanden, aus der Sicht eines AX-Anfängers:

AX-Anfänger? AX-Profi! : Nur eine Klitzekleinigkeit würde ich korrigieren:

Beispiel mit ScanTime 16:45 (Vorlauf 5 Min.):
- AX startet mit 3PG-Scan, reg. Timer1, der in <70 Min. ist und verlängert/korrigiert Timer1 auf 6:55-8:00.
- 6:55 startet der Topf und AX verlängert n.B., sieht aber den Nächsten Timer2 und da >ScanTime entfernt setzt er einen ScanTimer um 16:45.
- ScanTimer startet um 16:45 und korrigiert alle restlichen Timer mit Vorlauf.

Ich versuche es mal formelmäßig zu definieren:
Für i = 1, 2,... seien Ti die sortierten Startzeiten von Timern, also Ti < Tj für alle i < j. Dann sei Si(Ti) = Ti - 70' für alle i die optimale Scanzeit. Wenn man jetzt mit fester ScanTime ST arbeitet, so werden zum Termin ST genau die Timer korrigiert und mit Vorlauf versehen, für die gilt: ST <= Si(Ti) < ST + 24 Std. Alle Timer mit Si(Ti) < ST werden sofort behandelt. Die Entscheidung über die Si(Ti) mit Si(Ti) >= ST + 24 Std. wird auf ST + 24 Std. vertagt. Das ist jetzt hoffentlich eindeutig.

Ich habe jetzt mal eine Testversion online gestellt, bei der es in keinem Fall zur Umschaltung durch Pilottimer kommen sollte.

[FranzKM]

AX-Anfänger? AX-Profi!

Ich versuche es mal formelmäßig zu definieren:
Für i = 1, 2,... seien Ti die sortierten Startzeiten von Timern, also Ti < Tj für alle i < j. Dann sei Si(Ti) = Ti - 70' für alle i die optimale Scanzeit. Wenn man jetzt mit fester ScanTime ST arbeitet, so werden zum Termin ST genau die Timer korrigiert und mit Vorlauf versehen, für die gilt: ST <= Si(Ti) < ST + 24 Std. Alle Timer mit Si(Ti) < ST werden sofort behandelt. Die Entscheidung über die Si(Ti) mit Si(Ti) >= ST + 24 Std. wird auf ST + 24 Std. vertagt. Das ist jetzt hoffentlich eindeutig.

Ich habe jetzt mal eine Testversion online gestellt, bei der es in keinem Fall zur Umschaltung durch Pilottimer kommen sollte.

Super, jetzt sind alle Klarheiten beseitigt. Nein wirklich, um etwas kompliziertes zu erklären ist so eine "Formel" gerade richtig.
Es gibt also bei dieser Variante "ScanTime" keine PilotTimer!

Danke für die Testversion, ich überschreibe einfach die alte!?

[flechumer]

[quote="FranzKM"]Danke für die Testversion, ich überschreibe einfach die alte!?[/quote]

So isses.

[chrisly]

Zitat von flechumer Beitrag anzeigen
A
Ich versuche es mal formelmäßig zu definieren:
Für i = 1, 2,...

Puuh - schwere Kost. Aber nach dem 3. Lesen habe ich sogar die Formel verstanden (aber auch nur dank der vorherigen tollen Erklärung von FranzKM). Danke Euch Beiden!!!

Das erklärt zwar immer noch nicht den Abbruch durch Konflikt, aber das scheint dann wohl andere Ursachen zu haben.
AX lasse ich jetzt übrigens ständig mitlaufen (auch beim EPG-Scan), aber ein Scan-Timer wurde auch heute nicht angelegt, obwohl es lt. der Logik hätte so sein sollen. Aber ich kann nicht ausschließen, dass meine Tochter heute kurz vorher am Topf rumgespielt hat, deshalb werde ich es einfach mal eine Zeit lang beobachten und mich freuen, dass ansonsten alles reibungslos und ohne TAP-Locks etc. läuft - das ist schließlich das Wichtigste!

[flechumer]

[quote="chrisly"]Das erklärt zwar immer noch nicht den Abbruch durch Konflikt, aber das scheint dann wohl andere Ursachen zu haben.[/quote]

In der aktuellen Testversion ist auch eine kleine Änderung enthalten, die das von Dir beschriebene Verhalten verbessern könnte. Bitte ausprobieren.

[chrisly]

Super. Vielen Dank!

Eine Verständnisfrage habe ich dann doch noch ...
Du schreibst "- AX startet mit 3PG-Scan, reg. Timer1, der in <70 Min. ist und verlängert/korrigiert Timer1 auf 6:55-8:00."
Du schreibst aber auch: "Alle Timer mit Si(Ti) < ST werden sofort behandelt."
Wenn ich das jetzt richtig verstanden habe, spielt es keine Rolle, ob der erste Timer <70 Min. nach dem EPG-Scan startet. Solange er vor der ScanTime (hier 16:45) startet, müsste AX doch sofort (also beim EPG-Scan) reagieren - oder?
Und das auch nur bei neuen Timern. Timer, die 3PG schon für 2 Tage im voraus angelegt hat, müsste AX ja dann (für den Zeitraum von 24 Stunden nach 16:45) schon zur ScanTime bearbeiten.

[flechumer]

Super. Vielen Dank!

Eine Verständnisfrage habe ich dann doch noch ...
Du schreibst "- AX startet mit 3PG-Scan, reg. Timer1, der in <70 Min. ist und verlängert/korrigiert Timer1 auf 6:55-8:00."
Du schreibst aber auch: "Alle Timer mit Si(Ti) < ST werden sofort behandelt."
Wenn ich das jetzt richtig verstanden habe, spielt es keine Rolle, ob der erste Timer <70 Min. nach dem EPG-Scan startet. Solange er vor der ScanTime (hier 16:45) startet, müsste AX doch sofort (also beim EPG-Scan) reagieren - oder?
Und das auch nur bei neuen Timern. Timer, die 3PG schon für 2 Tage im voraus angelegt hat, müsste AX ja dann (für den Zeitraum von 24 Stunden nach 16:45) schon zur ScanTime bearbeiten.

Die Frage ist nicht, ob die Timerstartzeit vor der fixen Scanzeit liegt, sondern ob die Timerstartzeit - 70 Min. davor liegt. Wenn ja, wird sofort abgeglichen, wenn nein ...

[FranzKM]

Hi flechumer,

habe Deine Testversion (kein Umschalten bei PilotT) laufen lassen.

1. Versuch: Topf läuft auf DMAX - PilotT mit Kabel Eins - Wiedergabe von HDD - zum PilotT-Start wird meine Wiedergabe abgebrochen ohne Bookmark zu setzten.
2. Versuch: Topf läuft auf DMAX - PilotT mit DMAX - Wiedergabe von HDD - zum PilotT-Start wird meine Wiedergabe nicht abgebrochen.

Ich lasse mal die Testversion drauf, da Du weiter oben geschrieben hast, dass noch was anderes geändert wurde.

Werde aber mal ein paar Tage mit ScanTime experimentieren.

Nochmals Danke für Dein Engangement!

[flechumer]

habe Deine Testversion (kein Umschalten bei PilotT) laufen lassen.

1. Versuch: Topf läuft auf DMAX - PilotT mit Kabel Eins - Wiedergabe von HDD - zum PilotT-Start wird meine Wiedergabe abgebrochen ohne Bookmark zu setzten.

War das jetzt mit der Testversion? Da hätte 1 Min. vor PT-Start der PT-Kanal auf DMAX wechseln müssen. Sicher, daß das nicht der Fall war?

[FranzKM]

War das jetzt mit der Testversion? Da hätte 1 Min. vor PT-Start der PT-Kanal auf DMAX wechseln müssen. Sicher, daß das nicht der Fall war?

Ja, habe extra gerade nochmals nachgeschaut, Zeitstempel: Do. 09.12.2010 15:51 88K, da ich ja mit dem TAPCommander an der Version nichts sehe.
Er hat m. W. auch nicht 1 Min. vorher umgeschaltet, da wir gespannt auf 21;04 gewartet haben und schon 3 Min. vorher einen Bookmark gesetzt haben, damit wir die Stelle wieder finden.

Aber ich hatte eigentlich auch nichts anderes erwartet, da ich durchgeschleift habe und auch bei normalen Timern das Prob auch habe. Mach Dir damit nur keinen Streß!

[FranzKM]

So, jetzt habe ich auf ScanTime umgeschaltet ca. 11:30:

1. Start ohne TAPs
2. 3PG+Editor gestartet
3. .ini geändert: Sternchen weg vor ScanTime = 16:45
4. .pti gelöscht
5. TestTimer programmiert TestTimer1 13:00-13:30 h heute Arte, TestTimer2 15:00-16:00 h heute DMAX - erster offiz. Timer ist erst ca. 20:15 h
6. vorh. PilotTimer gelöscht
7. AX gestartet, hat 1x ? kurz PiP aufgeblitzt, dann nach einigen Min. nachgeschaut
8. TestTimer1+2 waren mit 5 Min. Vorlauf versehen. Kein ScanTimer gesetzt, schätze, der wird erst bei TestTimer2-Aufnahme gesetzt.

Resumée:
- Würde ich jetzt die beiden TestTimer löschen, würde AX den ScanTimer sofort setzen? Richtig?
- PilotTimer gibt es nicht mehr, wird ein Timer mit Termin vor der ausstehenden ScanTime neu programmiert, wird sofort abgeglichen mit Vorlauf. ScanTime gleicht immer von heute bis morgen von 16:45 bis 16:45 24 Std ab.
- Also läuft morgen früh mein 3PG-Scan + AX und kommen morgen <16:45 Timer hinzu, werden diese sofort abgeglichen.

[flechumer]

[quote="FranzKM"]Resumée:
- Würde ich jetzt die beiden TestTimer löschen, würde AX den ScanTimer sofort setzen? Richtig?[/quote]

Richtig.

[quote="FranzKM"]- PilotTimer gibt es nicht mehr, wird ein Timer mit Termin vor der ausstehenden ScanTime neu programmiert, wird sofort abgeglichen mit Vorlauf. ScanTime gleicht immer von heute bis morgen von 16:45 bis 16:45 24 Std ab.[/quote]

Es muß heißen: Um 16:45 werden alle Timer mit Anfangszeit ab heute 17:55 bis morgen 17:44 abgeglichen.

[quote="FranzKM"]- Also läuft morgen früh mein 3PG-Scan + AX und kommen morgen <16:45 Timer hinzu, werden diese sofort abgeglichen.[/quote]

Ja, wenn Du 16:45 durch 17:55 ersetzt.

[FranzKM]

[quote="flechumer"]Es muß heißen: Um 16:45 werden alle Timer mit Anfangszeit ab heute 17:55 bis morgen 17:44 abgeglichen.

Ja, wenn Du 16:45 durch 17:55 ersetzt.[/quote]

Aha, da spuckt wieder die TimerRange = 60+5+Vorlauf=70 mit rein?

D.h. wenn ich einen Timer um 17:00 h habe, wird der schon am Vortag mit abgeglichen...oder wie bei mir bei Neustart mit ScanTime schon mit TestTimer1+2.....
deshalb wollte ich weiter vorne die TimerRange = 0 setztn, was aber nicht geht.

Alles klar, danke Dir!

PS.:
Was passiert eigentlich, wenn ich TimeRange ganz rauslösche?