TAP: AutoExtender

[flechumer]

Lief denn noch eine andere Aufnahme?

[Steven]

[quote="flechumer"]Lief denn noch eine andere Aufnahme?[/quote]

Nein, ich befand mich allerdings im Timeshift der laufenden Aufnahme.

Gruß Steven.

[chrisly]

Leider war meine erste Aufnahme mit der .51 fehlerhaft.

Es wurde trotz nicht veränderter ini (Delay=15) nicht verlängert, sondern pünktlich um 20:00 abgebrochen.
Aufnahme war auf RTL II BigBrother 19:00-20:00 Uhr.
Ebenso wurde kein Log erstellt.
Das hatte in in der Form noch nie.

Gruß Steven.

Genau das gleiche Problem wie bei mir (mit der .50). Komisch.
Bei mir übrigens ohne Timeshift, aber mit parallel lfd. Aufnahme auf anderem Transponder.
Ich werde es auch mit der .51 weiter beobachten - evtl. findet sich ja irgendeine Logik dahinter?

[flechumer]

Einmal ist keinmal.

Das kann natürlich nicht gelten. Inzwischen ist mir die Ursache erklärlich. Ich versuch's mal "populärwissenschaftlich" weiterzugeben. AX hantiert mit einer Vielzahl von Daten, die nicht durchgängig verläßlich sind. Neben EPG-Problemen, die ja jetzt weitgehend bekannt sind, gibt es aber auch Probleme mit der Zuverlässigkeit von Daten der Firmware. Dabei denke ich an Aufnahmedaten einer gerade laufenden Aufnahme. Zur Ermittlung der Bookmark-Infos benötig AX z.B. ständig die Anzahl der aufgenommenen Cluster. Daß dieses Datum unzuverlässig ist, ist lange bekannt und im Prinzip kein Problem. Der betroffene Aufrufzyklus wird einfach abgebrochen und "auf bessere Tage gehofft". Das hat so funktioniert seit AX mit Bookmarks hantiert. Die neue Erkenntnis ist nun, daß diese Ausfälle nicht nur sporadisch einzeln auftreten, sondern sich über "längere" Zeiträume erstrecken können, lange genug, um die Zeit von 20 Sek. zu blockieren, die zur Verlängerung verfügbar ist.

Die gute Nachricht ist: Auch dieses Problem ist beherrschbar - wenn man's denn kennt. Es wird dazu - man ahnt es schon - eine neu AX-Version geben.

[chrisly]

Die gute Nachricht ist: Auch dieses Problem ist beherrschbar - wenn man's denn kennt. Es wird dazu - man ahnt es schon - eine neu AX-Version geben.

Ich hab´s geahnt - auf Dich ist Verlass!

[kantjer]

I have tried AX in the past but never got the results I was expecting, but the last version is working great.

I checked the log this morning and found something strange, according to the log a recoding was extended more than it actually was.

Code: Alles auswählen

AutoExtender 01.07.51
Date:            04.07.2009
Request:         23:22 - 00:30
Execution:       23:22 - 00:40
Reference-Event :d
   static:       23:25 - 00:30
   dynamic:      00:39 - 00:29
Delay:           85:04
Bookmarks:       0

this is my ini

Code: Alles auswählen

BookMarks = yes          * yes/no/y/n          yes
Extend = yes             * yes/no/y/n          yes
AccTimers = yes          * yes/no/y/n          yes
PrePad = 0               * 0 ... 10 min.       3
ExtensionFrom = 0        * 0 ... 23            0
ExtensionTo = 23         * 0 ... 23            23
MaxExtension = 60        * 0 ... 120 min.      60
Delay = 8                * 0 ... 60 min.       5
MaxTimerDelay = 5        * 0 ... 120 min.      5
Logging = on             * on/off              on

AltDelay = "10, 1"
AltDelay = "10, 2"
AltDelay = "10, 3"
AltDelay = "10, 4"
AltDelay = "10, 5"
AltDelay = "10, 6"
AltDelay = "10, 7"
AltDelay = "10, 8"
AltDelay = "10, 9"
AltDelay = "10, 11"
AltDelay = "10, 12"

ProtectTimer = RecCopy
ProtectTimer = 3PG

Any idea what happened here?

I also have one request, any change of adding a AltPrePad function? While for most of my channels 3 min. is Ok, I have a few that need 5 min. and some even 8 min prepadding.

It would be great if we could set the PerPadding based on the channel.

Bauke

[flechumer]

I have tried AX in the past but never got the results I was expecting, but the last version is working great.

I checked the log this morning and found something strange, according to the log a recoding was extended more than it actually was.

Code: Alles auswählen

AutoExtender 01.07.51
Date:            04.07.2009
Request:         23:22 - 00:30
Execution:       23:22 - 00:40
Reference-Event :d
   static:       23:25 - 00:30
   dynamic:      00:39 - 00:29
Delay:           85:04
Bookmarks:       0

Thanks for posting this log. It shows some formal errors as missing channel and event name. Delay seems to be rubbish as well as dyn. reference event. I'll find out why and make a bugfix in ver. .52.

this is my ini

Code: Alles auswählen

BookMarks = yes          * yes/no/y/n          yes
Extend = yes             * yes/no/y/n          yes
AccTimers = yes          * yes/no/y/n          yes
PrePad = 0               * 0 ... 10 min.       3
ExtensionFrom = 0        * 0 ... 23            0
ExtensionTo = 23         * 0 ... 23            23
MaxExtension = 60        * 0 ... 120 min.      60
Delay = 8                * 0 ... 60 min.       5
MaxTimerDelay = 5        * 0 ... 120 min.      5
Logging = on             * on/off              on

AltDelay = "10, 1"
AltDelay = "10, 2"
AltDelay = "10, 3"
AltDelay = "10, 4"
AltDelay = "10, 5"
AltDelay = "10, 6"
AltDelay = "10, 7"
AltDelay = "10, 8"
AltDelay = "10, 9"
AltDelay = "10, 11"
AltDelay = "10, 12"

ProtectTimer = RecCopy
ProtectTimer = 3PG

Any idea what happened here?

I also have one request, any change of adding a AltPrePad function? While for most of my channels 3 min. is Ok, I have a few that need 5 min. and some even 8 min prepadding.

It would be great if we could set the PerPadding based on the channel.

Bauke

There seem to be some misunderstanding of statement "ProtectTimer". It can be used only for protecting a timer from delaying by AX. But you have to state its name-prefix. It has nothing to do with other TAPs.

Your change request will be realized in one of the next versions.

[flechumer]

[quote="kantjer"]IAny idea what happened here?[/quote]
Yes, I think so. "Bookmarks: 0" shows that there has never been a change of event id during recording. On the other hand a static event info was obtained from EPG. So the recording was extended by 10 min. as expected. The lack of id-change led to false log-info. This error is fixed in ver. .52 which will be released after more tests within a few days.

[kantjer]

[quote="flechumer"]TThere seem to be some misunderstanding of statement "ProtectTimer". It can be used only for protecting a timer from delaying by AX. But you have to state its name-prefix. It has nothing to do with other TAPs. [/quote]

I have 2 timers set called RecCopy and 3PG.

Bauke

[flechumer]

Was kantjer hier macht, ist auch für unsere deutschen User von Interesse: Schützt Eure Scan- bzw. RecCopy-Timer vor Verschiebung mit ProtectTimer!

[Steven]

Was kantjer hier macht, ist auch für unsere deutschen User von Interesse: Schützt Eure Scan- bzw. RecCopy-Timer vor Verschiebung mit ProtectTimer!

Ich habe auch diese beiden Timer und die wurden noch nie verlängert, warum auch?

Der 3PG Timer startet ja den Scan und die anschließenden Aufnahmen sind ja nur eine Minute lang. Genau deshalb hast du doch die Mindestaufnahmezeit nach der AX erst eingreift auf zwei Minuten gesetzt.

Und der RecCopy Timer ist lediglich ein Umschalttimer, es findet im Anschluss ja u. U. nur eine Kopie, keine normale Aufnahme statt.

Gruß Steven.

[flechumer]

Ich habe auch diese beiden Timer und die wurden noch nie verlängert, warum auch?

Bei ProtectTimer geht es nicht um die Verlängerung, sondern um den Schutz vor Verschiebung (und der evt. damit verbundenen Löschung). Das kann schon sinnvoll sein.

[uenger]

Bei ProtectTimer geht es nicht um die Verlängerung, sondern um den Schutz vor Verschiebung (und der evt. damit verbundenen Löschung).

Moin,
bei meinen Versuchen neue Timer zu setzen und diese dann wieder zu löschen (damit ich sehe, ob es einen Vorlauf gab), habe ich mindestens drei mal meinen JagEPG-Wecktimer versehentlich gelöscht und insofern macht das schon Sinn.
Aber wie geht denn das :

LG
uenger

[mvordeme]

Hier mal ein interessanter Hinweis. R2-D2 hat bereits ein ähnliches TAP gebastelt: Extend. Auf dem Weg hat er wohl auch ein paar Fehler in der Topfware gepatcht, damit die Daten zuverlässiger werden.

[flechumer]

Moin,
bei meinen Versuchen neue Timer zu setzen und diese dann wieder zu löschen (damit ich sehe, ob es einen Vorlauf gab), habe ich mindestens drei mal meinen JagEPG-Wecktimer versehentlich gelöscht und insofern macht das schon Sinn.
Aber wie geht denn das :

LG
uenger

Also wenn Du einen Timer versehentlich löschst, kann Dir ProtectTimer auch nicht helfen. Es geht um Folgendes: Wenn AX eine Aufnahme verlängert, kann es sein, daß - wenn alle Tuner belegt sind - ein Timer erst mit Verzögerung, schlimmstenfalls auch gar nicht gestartet werden kann. Die Parameter MaxTimerDelay und ProtectTimer beeinflussen diesen Vorgang. MaxTimerDelay ist eine globale Verschiebungsbeschränkung, ProtectTimer schließt namentlich genannte Timer von jeder Verschiebung aus.

[flechumer]

Hier mal ein interessanter Hinweis. R2-D2 hat bereits ein ähnliches TAP gebastelt: Extend. Auf dem Weg hat er wohl auch ein paar Fehler in der Topfware gepatcht, damit die Daten zuverlässiger werden.

Das ist mir wohlbekannt - aber Danke für den Hinweis. Trotz allem Lamento über die Unzuverlässigkeit des EPGs ist es letztendlich doch immer ein eigener Fehler, wenn man bestimmte Situationen nicht einkalkuliert hat. Ähnlich sehe ich das mit FW-Problemen. Ich habe bisher nie erlebt, daß sich die Probleme nicht programmiertechnisch lösen lassen.

[Dixie]

Also wenn Du einen Timer versehentlich löschst, kann Dir ProtectTimer auch nicht helfen.

@uenger,
aber dies erstellt die gelöschten Timer nach Neustart selbstständig wieder her.

Check And Create Timer EPG für den EPG-Scan und

Check And Create Timer z.B. für RecCopy.


Dixie

[uenger]

Moin,
vielen Dank für Eure Erklärungen und Hinweise. Jetzt bin ich wieder mit!

LG
uenger

[Steven]

[quote="flechumer"]Bei ProtectTimer geht es nicht um die Verlängerung, sondern um den Schutz vor Verschiebung (und der evt. damit verbundenen Löschung). Das kann schon sinnvoll sein.[/quote]

OK, Danke für die Erklärung.

Gruß Steven.

[flechumer]

AutoExtender Ver. 01.07.52 steht jetzt online. Was neu ist:

• Parameter AltPrePad. Damit kann man bis zu 32 Kanälen alternative Vorläufe zuordnen.
• Neue Fehlermeldungen für "Event nicht gefunden" und "RecFile Problem".
• Bugfix: Das RecFile-Problem kann jetzt nicht mehr die Verlängerung blockieren.
• Die Beschreibung ist angepaßt.