Probleme mit der Priorität der Suchworte und Timer

[harbad]

hallo,

hab ein kleines "problemchen" mit meinen suchwörtern. ich hatte die suchwörter schön mit vol+- sortiert. hab aber irgendwann auf eine falsche bunte taste gedrückt. jedenfalls werden die suchworte mir jetzt alphabetisch angezeigt und zwar erst die "r", dann die "p" suchwörter und zuletzt suchwörter ohne eventprogrammierung. in welcher datei erfolgt denn die speicherung der reihenfolge und priorität der suchbegriffe, ist dafür nur die Jags_EPG.Search.ini verantwortlich oder gibt es dafür noch eine andere datei? jetzt hab ich aber bei der automatischen programmierung ein problem. hab heute "the guardian" und "navy cis" als "r" suchwort in der liste, dazu noch "familienanwältin" als "p" suchwort. in der suchwortliste stehen guardian und navy cis weit vor familienanwältin. navy cis läuft von sat1 von 22.15-23.15uhr, guardian von sat1 von 23.15-00.15uhr und familienanwältin von rtl von 21.15-22.15uhr. alle suchwörter haben 6 minuten vor- und 11 minuten nachlauf. warum erstellt mir jetzt das epg tap einen umschalttimer für familienanwältin und einen timer für guarian und lässt navy cis aus? obwohl navy cis eine höhere priorität hat als familienanwältin. hab jetzt mal navy cis in meiner suchwortliste an stelle 2 verschoben und die timer gelöscht. danach wurden die timer richtig angelegt. einmal umschalt rtl und einmal sat1 von 22.09-00:26uhr.

[emarzinkowski]

die Datei ist die richtige.
warum er das nun falsch programmiert hat verstehe ich nicht. aber ich verstehe auch nicht, wie die Begriffe vor der Programmierung/Änderung durch dich sortiert waren.
wenn ich das richtig verstanden habe, war da navy cis auch schon vor der familienanwältin, oder?
Dann sollte es auch vorher schon korrekt gewesen sein.

[harbad]

wie schon gesagt, vorher waren zuerst die "r" suchbegriffe alphabetisch in der liste, dann kamen die "p" begriffe alphabetisch und zuletzt die ohne event alphabetisch. ich hab jetzt nur navy cis von platz ca. 20 auf zwei geschoben und dann funktioniert es wie es sollte. müssten eigentlich nicht aufnahme suchwörter eine höhere priorität habe wie umschaltsuchwörter? am freitag müsste dann das gleiche problem nochmal auftreten. da hab ich eine ähnliche konstellation nochmal.

[emarzinkowski]

müssten eigentlich nicht aufnahme suchwörter eine höhere priorität habe wie umschaltsuchwörter?

hätte ich jetzt zumindest auch gedacht.

[Happy]

müssten eigentlich nicht aufnahme suchwörter eine höhere priorität habe wie umschaltsuchwörter?

Hallo,
so würde man es sich wünschen.
Ich kenne aber nur die Aussage, dass die Suchbegriffe von oben nach unten gesucht werden.

Gruß,
Happy

[emarzinkowski]

aber wenn die Rec Such Begriife eh vor den P Begriffen standen, dann hätte es doch klappen sollen

[Happy]

aber wenn die Rec Such Begriife eh vor den P Begriffen standen, dann hätte es doch klappen sollen

Würde ich auch so sehen

[harbad]

gestern das gleiche spiel nochmal.
1. r-suchwort nr. 14 17-18uhr
2. r-suchwort nr. 28 18.15-19.30uhr
3. p-suchwort nr. 54 17.15-18.30uhr

das führte zum ergebnis, das jeweils ein event auf einen transponder gefunden wurde (also drei verschiedene transponder).

programmiert wurde ein aufnahmetimer von 17-18uhr und ein umschalttimer von 17.15-18.30uhr. damit war ich natürlich nicht einverstanden. also die zwei timer gelöscht und gewartet. beim nächsten mal wurden die aufnahmetimer wunschgemäss angelegt und der umschalttimer ignoriert. sehr seltsam.

[Happy]

programmiert wurde ein aufnahmetimer von 17-18uhr und ein umschalttimer von 17.15-18.30uhr. damit war ich natürlich nicht einverstanden. also die zwei timer gelöscht und gewartet. beim nächsten mal wurden die aufnahmetimer wunschgemäss angelegt und der umschalttimer ignoriert. sehr seltsam.

Ich glaube nicht seltsam, wenn Du den Scan alle 10 Minuten aktiviert hast.
Dein 3. Suchwort rückt vor dem Suchwort 2 in das Zeitfenster (Standard 26 Stunden), in dem im voraus programmiert wird. Suchwort 2 wird dann erst eine Stunde später programmiert, schlägt aber fehl da die beiden Tuner schon belegt sind.

Löschst Du die Timer, klappt es natürlich, da dann alle gleichzeitig im 26h-Fenster sind
Gruß,
Happy

[harbad]

da hast du natürlich recht. noch ein grund das scanfenster zu erweitern. oder der aufnahme vorrang vor dem umschalten einzuräumen.

[Happy]

Das betrifft ja nicht nur P-Timer. Durch den 10-Minuten-Scan wird die Prioritätenvergabe nach Reigenfolge der Suchwörter komplett ausgehebelt.
Wenn man das Intervall vergrößert, wird dieses Problem auch nur abgemildert, aber nicht ausgeschlossen.
Man müßte die Logik etwas intelligenter machen.
Man müßte nicht nur im 26h Fenster suchen, sondern gleichzeitig schauen, ob in einem 30h Fenster evtl. konkurrierende Sendungen kommenund dann auf eine Programmierung verzichten. Wäre aber deutlich aufwändiger zu programmieren, da man sich erst alle möglichen Timer merken , und dann checken müßte ob es keine Konflikte gibt.

Gruß,
Happy

[harbad]

richtig. für den anfang würde es aber schon reichen das r-timer vor p-timern gehen und der scanintervall vergrössert wird. wenn der intervall grösser ist, dann könnte man vielleicht ein hinweisfenster einbauen das es einen konflikt gab und das suchwort x nicht aufgezeichnet wird.

[emarzinkowski]

oder einfach das 26 Stunden Fenster ab dem Scanzeitpunkt beibehalten und nicht alle 10 min erweitern.
reicht doch auch, oder?

[Happy]

Enrico, das wäre auch schon eine gewisse Abhilfe und nicht so sehr kompliziert.
Notfalls nimmt man nicht den Scanzeitpunkt, denn den müßte sich das TAP ja speichern, sondern den letzten Start des TAPs als Referenz.

Gruß,
Happy

[harbad]

das ändert doch aber alles nichts an meinen problem, oder? normalerweise müsste doch gescant werden x stunden, wenn am ende der zu überprüfenden zeit nichts gefunden wurde dann ende scan. wird etwas am ende der zu überprüfenden zeit etwas gefunden dann rechne die zeit der gefundenen timer zur scanzeit zu und überprüfe ob in diesen zeitraum noch timer gefunden werden. bei konflikten gebe eine warnmeldung aus und r-timer haben vorrang vor p-timern. ob sich das bewerkstelligen lässt - keine ahnung. oder die scanintervalle auf mindestens vier stunden erhöhen, aber auch dann mit konfliktmeldungen.

[Happy]

das ändert doch aber alles nichts an meinen problem, oder?

Es käme zumindest seltener vor.

wird etwas am ende der zu überprüfenden zeit etwas gefunden dann rechne die zeit der gefundenen timer zur scanzeit zu und überprüfe ob in diesen zeitraum noch timer gefunden werden. bei konflikten gebe eine warnmeldung aus und r-timer haben vorrang vor p-timern. ob sich das bewerkstelligen lässt - keine ahnung.

Konfliktmeldungen wäre eine Möglichkeit, aber automotisch wäre auch nicht besser.

Das Problem liegt darin, dass Jag zwischen selbst gesezten und fremdgesetzten Timern nicht unterscheidet. Wenn Jag das wüßte, könnte er bei einem Konflikt einen niedriger priorisierten Timer löschen und den mit hoher Prio setzen.

Aber auch das führt wieder zu Problemen. Hat man sich zu einem Zeitpunkt vergewissert, dass ein Timer gesetzt wurde, könnte es sein, dass der Timer wieder verschwindet, weil eine andere Sendung höher priorisiert war. Wäre zwar logisch, das würde aber nicht allen gefallen.

Gruß,
Happy

[Jag]

Hallo,

müssten eigentlich nicht aufnahme suchwörter eine höhere priorität habe wie umschaltsuchwörter?

...
so würde man es sich wünschen.

so ist es auch, Rec-Timer haben immer Vorrang vor P-Timer!

Die Reihenfolge bei der Suche+Programmierung lautet erst die 1xRec-Timer, dann Rec-Timer und danach P-Timer, innerhalb der jeweiligen Gruppe ist dann die Sortierungen (Oben/Unten) entscheidend!

Unter bestimmten Umständen könnten jedoch P-Timer dort gesetzt werden, wo weitere Rec-Timer wegen Kollisionen nicht mehr gesetzt werden können!

Beispiel:
Zwei sich überschneidende Rec-Timer zur selben Zeit, während hier u.U. parallel dazu kein dritter Rec-Timer möglich ist, könnte theoretisch ein P-Timer noch zusätzlich programmiert werden, wenn er auf einen der benutzen Transponder liegt!
Müsste man manuell nachprüfen


Gruß
Jag

[Happy]

so ist es auch, Rec-Timer haben immer Vorrang vor P-Timer!

Außer wenn der P-Timer aufgrund des Zeitfensters vor einem 2. REC-Timer gesetzt wird. Dann hat der 2. REC-Timer Pech gehabt, oder ?

Gruß,
Happy

[Jag]

Außer wenn der P-Timer aufgrund des Zeitfensters vor einem 2. REC-Timer gesetzt wird. Dann hat der 2. REC-Timer Pech gehabt, oder ?

Ja, richtig, daher sollte man das 26 h Fenster für die Programmierung auch nicht beliebig erweiterten!
Einige Sender strahlen ja eben nur die EPG Daten für einen Tag und andere Sender für eine ganze Woche in Voraus aus und da währen die Timer von den entsprechenden Sendern im Vorteil! Ein P-Timer der bereits gesetzt wurde (und nicht wieder automatisch gelöscht wird) könnte dann einen Rec-Timer blockieren, der wegen "zu spät eingehender" EPG Daten erst später programmiert worden wäre!


Gruß
Jag

[harbad]

@Jag
dann bleibt aber doch das problem mit dem zehn minuten fenster. bei der suche nach den suchworten wurden alle sendungen die ich am samstag aufnehmen bzw. sehen wollte schon am donnerstag gefunden. dafür hat dann Happy eine für mich logische erklärung geliefert. beim überprüfen alle zehn minuten wurde ein r-timer gefunden und ein p-timer, diese wurden dann programmiert und weil der zweite r-timer ausserhalb der 26 stunden lag, wurde dieser ignoriert. oder wird bei einen weiteren scan z.b. geprüft: aha, ich hab hier einen r- und einen p-timer und hab jetzt noch eine r-timer gefunden also mache ich den p-timer platt und setze dafür den r-timer? wenn nicht, dann nützt auch eine verkürzung/verlängerung des bereiches unter punkt 39 nichts. wenn am ende des bereiches dann etwas gefunden wird, dann kann es immer vorkommen das einträge die eine höhere priorität haben aber minimal ausserhalb des bereiches liegen eben ignoriert werden. es müssten dann z.b. die 26 stunden überprüft werden und die endzeit des prüfzeitraums mit der endzeit des am weitesten in der zukunft liegenden neu gefunden times verglichen werden. ist die endzeit des neu gefundenen timers grösser müsste der prüfzeitraum entsprechend erweitert werden. oder sehe ich das falsch.