TAP: AutoExtender

[flechumer]

Hier ist nochmal eine geänderte Testversion mit mehr Trace-Events und genauerer Diagnosemöglichkeit. Bitte nur noch damit testen.

[chrisly]

Danke! Ist schon im Topf. Mal sehen, wie´s ihm bekommt ... :d rink:

[chrisly]

Jetzt liefen mit der neuesten Version neben einer längeren Aufnahme zusätzlich 4 Aufnahmen abwechselnd nacheinander.
Die gute (und wichtigste!) Nachricht zuerst: kein Reboot!

Aber: bei 2 der Aufnahmen blieben über die gesamte Aufnahmezeit alle Taps (außer AX) deaktiviert. Erst mit Beginn der nächsten Aufnahme oder durch manuellen Abbruch waren die Taps wieder aktiv (schrecklich - ein Topf ohne Taps ).

Irgendwas stimmt da noch nicht so ganz. Die Trace-Datei war in diesem Fall übrigens leer (wird wohl nur bei Reboot / Freeze gefüllt?).

Edit: Beendigungsgrund bei den o.g. Aufnahmen war immer korrekt: "Verlängerung unerwünscht (5)"

[flechumer]

Jetzt liefen mit der neuesten Version neben einer längeren Aufnahme zusätzlich 4 Aufnahmen abwechselnd nacheinander.
Die gute (und wichtigste!) Nachricht zuerst: kein Reboot!

Aber: bei 2 der Aufnahmen blieben über die gesamte Aufnahmezeit alle Taps (außer AX) deaktiviert. Erst mit Beginn der nächsten Aufnahme oder durch manuellen Abbruch waren die Taps wieder aktiv (schrecklich - ein Topf ohne Taps ).

Irgendwas stimmt da noch nicht so ganz. Die Trace-Datei war in diesem Fall übrigens leer (wird wohl nur bei Reboot / Freeze gefüllt?).

Edit: Beendigungsgrund bei den o.g. Aufnahmen war immer korrekt: "Verlängerung unerwünscht (5)"

Das kann nicht sein: Einerseits wurden Log-Dateien geschrieben, andererseits aber kein Trace? Hast Du den Trace ausgeschaltet (Default)? So langsam kommen mir Zweifel, ob Du das alles ernst meinst ...

[chrisly]

Glaub mir - ich meine es ernst und bin Dir dankbar, dass Du dran bleibst!!!
Trace ist auch eingeschaltet. Die wird doch dann beim Abschalten erzeugt. Und diese Datei war gestern nach o.g. Situation leer. Beim Abschalten davor war sie aber gefüllt.

[flechumer]

Bei jedem Neustart wird die Trace-Datei neu angelegt. Man muß also erst sichern, dann AX starten.

[chrisly]

Dann war ich wohl zu langsam.
Beim nächsten Mal werde ich den Topf dann erst mal ohne Taps neu starten und die Datei sichern.

[chrisly]

Ich hatte jetzt wieder deaktivierte Taps während einer Aufnahme. Aber keinen Reboot mehr! Dieser Fehler scheint endgültig Geschichte zu sein!

Ich sende Dir mal die Trace-Datei, die ich rechtzeitig gesichert habe. Vielleicht bringt sie ja Licht ins Dunkel!?

[andreas-beck]

Hi,
ich habe einmal wieder eine Frage zu AutoExtender.

Ich hatte gestern endlich einmal die Gelegenheit ein Log zu ziehen und zwar von folgendem Fall:

Aufnahme auf RTL Programmiert: Alles was zählt (bis 20:15).
Danach sollte der TF weiter aufnehmen: WWM (bis 21:15).

Parallel wurde ab 20:15 eine Aufnahme auf Pro7 einprogrammiert.

Nach der Programmierung hatte ich in der Timerliste geschaut. Die Tunerverteilung sah gut aus.

Um 20:15 musste ich leider feststellen, dass die beiden Aufnahmen nach 20:15 nicht stattgefunden haben.

Das letzte im Log war Alles was zählt (bis 20:15).

AutoExtender 02.09.66(0)
Alles was zählt
RTL
Datum: 04.10.2010
Vorgabe: 18:57 - 19:40
Ausführung: 18:57 - 20:15
Bezugs-Event
statisch: 19:05 - 19:40
dynamisch: 19:06 - 19:39
Verzögerung: 19:19
Beendigungsgrund: Abbruch
Bookmarks: 2


Warum wurden die anderen beiden Aufnahmen nicht gestartet?
Aus irgend einem Grund wurde die letzte Aufnahme mit "Abbruch" gekennzeichnet. Manuell wurde aber die Aufnahme nicht beendet.

Gerät ist dein TF60000, der mit 2 Satellitenkabel angeschlossen ist (kein Durchschleifen).

Diese Kombination von Sendungen wird öfters programmiert und läuft leider immer schief (
Was mache ich hier falsch?

[flechumer]

Ich hatte jetzt wieder deaktivierte Taps während einer Aufnahme. Aber keinen Reboot mehr! Dieser Fehler scheint endgültig Geschichte zu sein!

Aber warum? Da ich keine substantiellen Änderungen gemacht habe, mußt Du etwas geändert haben. Das sollte ich erfahren, gern per Mail.

Ich sende Dir mal die Trace-Datei, die ich rechtzeitig gesichert habe. Vielleicht bringt sie ja Licht ins Dunkel!?

Die Trace-Datei zeigt 9 (in Worten: neun) Aufnahmebeendigungen und alle völlig normal. Die Stellen, an denen Locks gesetzt und rückgesetzt werden, werden, so wie es sein soll, angesteuert. Abnormalitäten sind nicht erkennbar. Wie stellst Du das Problem eigentlich fest? Ab wann existiert der Lock, gleich nach dem Start von AX? Oder nach der ersten Aufnahmebeendigung?

[flechumer]

[quote="andreas-beck"]Ich hatte gestern endlich einmal die Gelegenheit ein Log zu ziehen ...[/quote]

Was heißt das denn? AX-Logs werden automatisch gezogen. Die jeweils letzten 8 können über die Browser-Funktion bequem eingesehen werden.

[quote="andreas-beck"]Aufnahme auf RTL Programmiert: Alles was zählt (bis 20:15).
Danach sollte der TF weiter aufnehmen: WWM (bis 21:15).

Parallel wurde ab 20:15 eine Aufnahme auf Pro7 einprogrammiert.

Nach der Programmierung hatte ich in der Timerliste geschaut. Die Tunerverteilung sah gut aus.[/quote]
Etwas genauer sollte es schon sein. Womit hast du programmiert? In welcher Reihenfolge? Versuche mal folgendes: Programmiere mit dem Standard-EPG die Aufnahmen jedes Kanals in chronologischer Reihenfolge. Gibt's damit Probleme?

Die letzte Bemerkung hinsichtlich Tunerverteilung macht mich allerdings stutzig: Was genau hast Du da gesehen? Alle Timer die unter Mitwirkung von AX programmiert werden, werden auf Tuner 4 umgelegt.

[Dixie]

@Chrisly,
nutzt du die letzte Eumeltier Version von Overfly. Bei älteren Versionen und bei bei als 200 Dateien dauerte der Scan sehr lange, da immer alles neu gescannt wurde. Während des Scans ist der Topf kaum bedienbar und NiceDisplay steht dann.

Ist nur so eine Idee!

Dixie

[chrisly]

Danke für die Idee!
Aber ich nutze die Eumeltier-Version, die auch problemlos läuft.

Aber warum? Da ich keine substantiellen Änderungen gemacht habe, mußt Du etwas geändert haben. Das sollte ich erfahren, gern per Mail.

Die Trace-Datei zeigt 9 (in Worten: neun) Aufnahmebeendigungen und alle völlig normal. Die Stellen, an denen Locks gesetzt und rückgesetzt werden, werden, so wie es sein soll, angesteuert. Abnormalitäten sind nicht erkennbar. Wie stellst Du das Problem eigentlich fest? Ab wann existiert der Lock, gleich nach dem Start von AX? Oder nach der ersten Aufnahmebeendigung?

Ich habe eigentlich nur die Testversion aufgespielt und Trace=j ergänzt. Sonst gab es keinerlei Änderungen am Topf!
Das würde ja dann bedeuten, dass der Fehler doch wieder auftreten kann.
Ich war fast sicher, dass Du was am Tap geändert hast, zumal auch das Verhalten bei mehreren Folgeaufnahmen jetzt anders ist:
wenn die erste Aufnahme (bei lfd. weiterer Aufnahme) ein Exclude-Event ist, stoppt AX diese Aufnahme jetzt schon ca. 1/2 Minute früher, bevor die nächste Aufnahme losgeht.
Und wenn es eine "normale" Aufnahme ist, läuft sie etwas länger als vorgegeben (allerdings dann ohne "Gedenkpause" bis zur nächsten Aufnahme).

Die Trace-Datei wurde nach einem Test erzeugt - deshalb so viele Aufnahmen.
Der Lock passierte beim stoppen einer Aufnahme und Beginn der nächsten Aufnahme (aber nicht bei der ersten, sondern zwischendrin). Und die Taps wurden erst nach Ende dieser Aufnahme wieder freigegeben.
Der Topf ließ sich zwar in dieser Zeit noch bedienen, aber halt ohne Taps (grauenvoll!).

[flechumer]

Ich war fast sicher, dass Du was am Tap geändert hast, zumal auch das Verhalten bei mehreren Folgeaufnahmen jetzt anders ist:
wenn die erste Aufnahme (bei lfd. weiterer Aufnahme) ein Exclude-Event ist, stoppt AX diese Aufnahme jetzt schon ca. 1/2 Minute früher, bevor die nächste Aufnahme losgeht.
Und wenn es eine "normale" Aufnahme ist, läuft sie etwas länger als vorgegeben (allerdings dann ohne "Gedenkpause" bis zur nächsten Aufnahme).

Ich habe einen internen Parameter, der den Zeitabstand zu einem möglichen Konflikt definiert, von 30 auf 40 Sek. erhöht. Das habe ich hiermit rückgängig gemacht und gleich noch einige Änderungen zur Diagnose eingebaut. Bitte damit mal probieren und mir den Trace mailen. Die Trace-Date wird jetzt wrap-around fortgeschrieben. Es geht also nichts mehr verloren. Bitte auf Fehlermeldungen im Log achten!

Die Trace-Datei wurde nach einem Test erzeugt - deshalb so viele Aufnahmen.
Der Lock passierte beim stoppen einer Aufnahme und Beginn der nächsten Aufnahme (aber nicht bei der ersten, sondern zwischendrin). Und die Taps wurden erst nach Ende dieser Aufnahme wieder freigegeben.
Der Topf ließ sich zwar in dieser Zeit noch bedienen, aber halt ohne Taps (grauenvoll!).

Wie hast Du das festgestellt? Durch Eingabe von TAP-Kommandos?

[andreas-beck]

Was heißt das denn? AX-Logs werden automatisch gezogen. Die jeweils letzten 8 können über die Browser-Funktion bequem eingesehen werden.


Etwas genauer sollte es schon sein. Womit hast du programmiert? In welcher Reihenfolge? Versuche mal folgendes: Programmiere mit dem Standard-EPG die Aufnahmen jedes Kanals in chronologischer Reihenfolge. Gibt's damit Probleme?


Die letzte Bemerkung hinsichtlich Tunerverteilung macht mich allerdings stutzig: Was genau hast Du da gesehen? Alle Timer die unter Mitwirkung von AX programmiert werden, werden auf Tuner 4 umgelegt.

Ich meinte mit "Logs gezogen" auch auf den Rechner geladen )

Die Aufnahme wurde 2 geteilt programmiert.
Erst bis 20:15 Uhr und danach noch einige Zeit Später die Sendungen nach 20:15 Uhr. Ist dies ein Problem mit AX und müssen immer alle Timer zur gleichen Zeit hintereinander weg programmiert werden?
Würde evtl. erklären, warum ich den Fehler nicht immer beobachten kann.

Programmierung wurde mit Standart EPG gemacht. Außer QuickJump laufen auf dem TF6000 keine Taps.

Zu den Tunern: ich beobachte das Ganze noch einmal und schaue, ob immer Tuner4 genommen wird von AX (danke für den Hinweis)

[flechumer]

[quote="andreas-beck"]Die Aufnahme wurde 2 geteilt programmiert.
Erst bis 20:15 Uhr und danach noch einige Zeit Später die Sendungen nach 20:15 Uhr. Ist dies ein Problem mit AX und müssen immer alle Timer zur gleichen Zeit hintereinander weg programmiert werden?
Würde evtl. erklären, warum ich den Fehler nicht immer beobachten kann.[/quote]

Das ist kein Problem, solange man in chronologischer Reihenfolge programmiert, d.h. in der Anfangsreihenfolge. Ich empfehle, das noch mal in Ruhe zu beobachten. Das ganze ist eine Allerweltssituation, die dauernd vorkommt, auch auf meinem 6000er.

Noch ein Nachtrag: Unübersichtlich wird es, wenn man ohne AX programmiert und später AX zuschaltet. Dann sind die Ergebnisse zufallsabhängig.

[chrisly]

Das habe ich hiermit rückgängig gemacht


Wie hast Du das festgestellt? Durch Eingabe von TAP-Kommandos?

Hoffentlich kommt damit nicht der alte Fehler zurück. Ich werde es mal 1 Tag lang testen - für den Urlaub danach ist mir das zu riskant.

Den Lock habe ich zuerst bemerkt, als Nicedisplay hängen blieb. Während dieser Zeit gab´s dann z.B. auch nur Original-Filer und -EPG.

Mir ist da noch was eingefallen, was ich heute bei einem erneuten Lock bestätigt sah:
es ist bisher nur dann passiert, wenn während einer lfd. Aufnahme eine weitere Exclude-Event-Aufnahme beendet und die nächste Aufnahme gestartet wurde (aber nicht jedesmal).
Bei "normalen" Aufnahmen passierte es noch nie.

[chrisly]

Ich habe jetzt mehrere Aufnahmen mit der neuesten Version gemacht - bisher kein Reboot / kein Freeze / kein Lock - warum auch immer ...
Eigentlich hat sich ja nichts Grundlegendes geändert.

Egal - Hauptsache, es klappt!
Die Trace-Datei ist in dem Fall dann wohl auch eher uninteressant - oder?

[flechumer]

[quote="chrisly"]Mir ist da noch was eingefallen, was ich heute bei einem erneuten Lock bestätigt sah:
es ist bisher nur dann passiert, wenn während einer lfd. Aufnahme eine weitere Exclude-Event-Aufnahme beendet und die nächste Aufnahme gestartet wurde (aber nicht jedesmal).
Bei "normalen" Aufnahmen passierte es noch nie.[/quote]

Vielleicht hilft das ja weiter. Sicher würde helfen, wenn Fehlermeldungen der Art "SetLock-Fehler n" oder "RelLock-Fehler n" geloggt würden. Bitte immer die Logs kontrollieren.

[flechumer]

[quote="chrisly"]Die Trace-Datei ist in dem Fall dann wohl auch eher uninteressant - oder?[/quote]

Erst wenn ein Problem eintritt, die .trc kopieren und mir mailen, auch während laufender Aufnahmen.