TAP: AutoExtender

[flechumer]

Also geht Scan Time jetzt auch bei mir.

Na siehste!

Das mit den Anführungszeichen bei ScanTime war ein Schnellschuss von mir. Es geht genausogut ohne. Anführungszeichen werden immer nur benötigt, wenn Blanks enthalten sind.

[flechumer]

Weil sich die TAP-Locks wieder gehäuft haben - jetzt mit der .67 ist wieder alle okay.
Ist aber ein Einzelschicksal! Nicht davon irritieren lassen!!!

Nicht aufgeben! Versuche bitte mal diese Version.

[chrisly]

Wie - hast Du etwa noch ´ne Idee?
Eigentlich wollte ich ja still und leise zur .67 zurück, aber die werde ich natürlich nochmal ausprobieren ... :

[Fritzcat]

Wieso wird eigentlich, wenn während einer Wiedergabe ein Pilottimer ansteht, die Wiedergabe unterbrochen? Hatte auch den Fall, dass auf dem TMS gefragt wurde, ob für den Pilot-Timer umgeschaltet werden soll. Beim P-Timer ja eigentlich klar, aber gibt es keine Möglichkeit, den 2. inaktiven Tuner für den Abgleich zu nutzen?

[flechumer]

[quote="Fritzcat"]Wieso wird eigentlich, wenn während einer Wiedergabe ein Pilottimer ansteht, die Wiedergabe unterbrochen? Hatte auch den Fall, dass auf dem TMS gefragt wurde, ob für den Pilot-Timer umgeschaltet werden soll. Beim P-Timer ja eigentlich klar, aber gibt es keine Möglichkeit, den 2. inaktiven Tuner für den Abgleich zu nutzen?[/quote]

Das wird genau so gemacht. Nur wenn der 2. Tuner nicht frei ist, wird versucht, den 1. umzuschalten.

[chrisly]

Was etwas stört ist in bestimmten Fällen das häufige Aufblitzen des PIP-Fensters. Wäre es evtl. möglich, das zu reduzieren? Wenn der periodische Abgleich aufgrund lfd. Aufnahmen nicht möglich ist, bringt es doch eigentlich nichts, dass AX das alle 2 (?) Sekunden immer wieder versucht und dabei PIP aufblitzt. Hier würde es doch auch reichen, wenn das z.B. nur 2-4 mal pro Minute passiert.

Ich habe übrigens vorhin meine übliche Testreihe mit Mehrfachaufnahmen durchgeführt.
Und es kam zu KEINEM TAP-Lock oder gar Reboot.
Was hast Du denn in der Testversion geändert? Oder war es vielleicht doch nur Zufall?
Bis jetzt bin ich jedenfalls sehr optimistisch!

[uenger]

Moin,
Ich hab heute den PilotTimer (bei mir durch ScanTime= "16:45") beobachtet und das war schon toll. Topf schaltete ein, machte den Abgleich und schaltete sich danach wieder aus. Für mich optimal!
Dennoch, wäre es nicht auch machbar, den Pilottimerabgleich in die PrePad-Zeit zu legen(die könnte man ja um die nötigen Minuten verlängern)?
Damit wären doch die Einwände von Fritzcat und chrisly vom Tisch.

LG
uenger

[flechumer]

Ich habe übrigens vorhin meine übliche Testreihe mit Mehrfachaufnahmen durchgeführt.
Und es kam zu KEINEM TAP-Lock oder gar Reboot.
Was hast Du denn in der Testversion geändert? Oder war es vielleicht doch nur Zufall?
Bis jetzt bin ich jedenfalls sehr optimistisch!

"Wer immer strebend sich bemüht, den können wir erlösen"

Das war kein Zufall. Allerdings ist die Testversion noch nichts Endgültiges. Damit gäbe es über kurz onder lang Probleme. Morgen kann ich möglicherweise schon etwas besseres bieten.

[chrisly]

Nur her damit.
Ich bin schon gespannt, was die Ursache war. Ich hoffe, Du lässt uns nicht dumm sterben ...

[flechumer]

[quote="uenger"]Dennoch, wäre es nicht auch machbar, den Pilottimerabgleich in die PrePad-Zeit zu legen(die könnte man ja um die nötigen Minuten verlängern)?
Damit wären doch die Einwände von Fritzcat und chrisly vom Tisch.[/quote]

Die Prepad-Zeit gehört ja schon zur Aufnahme. Beim EPG-Abgleich geht es ja im Wesentlichen um die Startzeit.

Jedesmal wenn ein Timer so spät programmiert wird, daß die reguläre Scanzeit schon überschritten ist, findet der Abgleich sofort statt. Und hier liegt nun das Problem. Wenn man zur Programmierung ein EPG-TAP einsetzt - und das tun wohl die meisten - werden die Aufnahmedaten nicht aus dem laufenden EPG, sondern aus irgendeiner Datenbank geholt. Bei Programmierung aus dem Standard-EPG erübrigt sich ein Umschalten, sonst i.A. nicht. Genau aus diesem Grund habe ich schon mal vor längerer Zeit EPG-TAP-Benutzern empfohlen, auf den Timer-EPG-Abgleich zu verzichten. Das war mir zwischenzeitlich allerdings entfallen. Aber jetzt kommt die Problematik wieder hoch.

[uenger]

Aber wenn es denn um die Startzeit geht, wie bist Du dann auf den PilotTimer 1 Stunde und 8 Minuiten vor Beginn der eigentlichen Aufnahme gekommen?
Könnte man dann nicht den PioltTimer näher an den Aufnahmebeginn legen?
Vielleicht denk ich da auch zu laienhaft.

LG
uengert

[flechumer]

Aber wenn es denn um die Startzeit geht, wie bist Du dann auf den PilotTimer 1 Stunde und 8 Minuiten vor Beginn der eigentlichen Aufnahme gekommen?
Könnte man dann nicht den PioltTimer näher an den Aufnahmebeginn legen?
Vielleicht denk ich da auch zu laienhaft.

Das ergibt sich doch durch TimerRange. Wenn da 60 Min. eingestellt sind - d.h. der Event kann bis zu 60 Min. früher anfangen, wenn der EPG das so anzeigt - kommt dazu noch der Vorlauf von 3 Min. und eine angenommenen Laufzeit des Pilottimers von 5 Min. Das ergibt dann eine Scanzeit = programmierte Startzeit - 68 Min.

[uenger]

Moin,
danke für die tolle Erklärung. Jetzt ist mir einiges verständlicher und ich ahne warum Duhier empfohlen hast ScanTime nicht einzusetzen.

LG
uenger

[flechumer]

Ich habe jetzt eine neue Testversion online gestellt. Wenn auch damit chrislys Problem behoben ist, sind wir einen Riesenschritt weiter. Zur Erklärung komme ich später.

Ebenfalls enthalten ist ein neues, pragmatisches Konzept für den EPG-Abgleich, das hoffentlich dem ganzen Hickhack um die Pilottimer ein Ende macht. Unabhängig von TimerAlign wird jetzt immer der EPG-Abgleich versucht. Dabei wird unterschieden ob AX als Pilot läuft oder nicht. AX läuft dann als Pilot, wenn der Topf durch einen Pilottimer gestartet wurde und nicht bedient wurde. In diesem Fall gibt es keine Beschränkung hinsichtlich Kanalumschaltung. Wenn dagegen AX nicht als Pilot läuft, wird pro Einzelabgleich höchstens einmal versucht, den 2. Tuner umzuschalten. Wenn das nicht gelingt, wird ein permanentes Problem unterstellt und auf den EPG-Abgleich verzichtet. Im Ergebnis wird ein Benutzer also höchstens durch ein einmaliges Aufblitzen des PiPs von dem Vorgang erfahren.

Bei der letzten Testversion habe ich durch die Downloadzahl festgestellt, daß ein erstaunliches Interesse daran besteht mitzutesten. Ich möchte das ausdrücklich ermutigen. Von allen Entwicklungsaufgaben ist mir die Testerei das Lästigste. Alles was dabei hilft, ist mir also willkommen.

[chrisly]

Bei der letzten Testversion habe ich durch die Downloadzahl festgestellt, daß ein erstaunliches Interesse daran besteht mitzutesten.

Vielleicht gab es ja doch noch ein paar unerkannte Mitleidende ...

Die neue Lösung mit dem EPG-Abgleich ist toll. Super Idee!
Jetzt muss nur noch die neue Testversion sauber laufen. Ich versuche, heute Abend zu testen ...

[chrisly]

Kann man die alte (69er) Version einfach überschreiben oder muss man was beachten bzgl. Timerlöschung etc.?

[flechumer]

[quote="chrisly"]Kann man die alte (69er) Version einfach überschreiben oder muss man was beachten bzgl. Timerlöschung etc.?[/quote]

Einfach überschreiben.

[chrisly]

Und Zeile 10 in der ini löschen (Timer Align) - sonst kommt "Syntaxfehler" ...

[chrisly]

Bei einem ersten kurzen Test wurde übrigens der Folgetimer jetzt nach hinten verschoben, wenn schon 2 Aufnahmen laufen. Eigentlich sollte dann doch ein lfd. Timer nicht weiter verlängert werden ("Verlängerung unmöglich"), damit die Folgeaufnahme nicht zu spät startet.
Bisher war das zumindest immer so. Und an der ini habe ich ansonsten nichts geändert.

[flechumer]

Bei einem ersten kurzen Test wurde übrigens der Folgetimer jetzt nach hinten verschoben, wenn schon 2 Aufnahmen laufen. Eigentlich sollte dann doch ein lfd. Timer nicht weiter verlängert werden ("Verlängerung unmöglich"), damit die Folgeaufnahme nicht zu spät startet.
Bisher war das zumindest immer so. Und an der ini habe ich ansonsten nichts geändert.

An der Ecke hat sich nichts verändert. Das Verhalten wird durch AccTimers, MaxTimerDelay und ggf. ProtectTimer bestimmt.