Posts by MarkusE

Quote from shofmann

Nov 4 23:29:00 HTPC vdr: [20080] EPGSearch: recdone thread ended (pid=18885, tid=20080)

Nov 4 23:29:01 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:01 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:29:11 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:11 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:29:21 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:21 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:29:31 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:31 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:29:41 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:41 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:29:51 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:29:51 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:30:02 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:30:02 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:30:11 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:30:11 HTPC vdr: [18885] markad: shutdown request accepted

Nov 4 23:30:21 HTPC vdr: [18885] markad: got shutdown request

Nov 4 23:30:21 HTPC vdr: [18885] markad: shutdown request accepted

…

Display More

kfb77 , auch wenn ich mich jetzt unbeliebt mache . Ich würde so etwas vermeiden, auch im debug log level. Es hilft nicht, Fehler zu finden.

Man kann ja z.B. nach 3 solchen Meldungen ausgeben, dass weitere Meldungen dieser Art erstmal nicht mehr ausgegeben werden, z.B. für 10 min oder eine Stunde.

Aber bitte nicht falsch verstehen: Es ist Dein Plugin, da kannst Du das natürlich so machen wie Du möchtest.

Quote from wmautner

Mußte erst vor kurzem entdecken, daß z.B. LIVE in der (zugegeben unbedeutenden) Anzeige des Plugin-Status im "?"-Menü das tvscraper-Plugin als "nicht installiert" anzeigt, wenn der DEFAULT-Debuglevel von vdr (=3) reduziert und so die "started plugin: xxx"-Anzeigen im syslog unterdrückt werden ...

Irgendwie glaube ich noch immer nicht, dass das reproduzierbar ist.

Hi,

Im git ist 3.3.9 .

• Unterstützung von Timerüberwachung mit epgsearch über die Sendungskennung. Dank an LotharE für den Feature Request und Test.
• MainThreadHook wird nicht mehr verwendet. Damit werden viele Aktionen schneller ausgeführt, z.B. Löschen von Timern, ... Außerdem wird der Fehler behoben, dass in der "Fernbedienung" Ansicht das OSD nicht gezeigt wurde während VDR eine Meldung ausgegeben hat. Dank für die Fehlermeldung und Analyse an shofmann .

Viel Spaß, Markus

shofmann , was soll ich dazu sagen? Code Verbesserungen sind immer möglich.

TFEVENT kannst Du ignorieren. Ich hatte das mal direkt im VDR definiert (über einen VDR Patch, nur für mich), um Patches in Vor- und Nachlauf bei Aufnahmen testen zu können.

Ich beobachte das jetzt mal, aber ich glaube inzwischen nicht mehr so wirklich, dass diese Patches in den VDR kommen. Dann nehme ich den TFEVENT block wieder raus.

Quote from wmautner

Und siehe da, die Anzeige im Live-Bildschirm hat jetzt auch "3 greens"

Ist nur interessant, daß dies vom Loglevel des VDR abhängt ...

Sollte es eigentlich nicht. Du kannst ja testweise den Loglevel wieder heruntersetzten, und nochmal neu starten.

Nach dem Start von VDR steht doch im syslog für jedes Plugin eine Zeile

initializing plugin ...

Sollte ab VDR log level 2 ausgegeben werden, im Code steht:

isyslog("initializing plugin: %s (%s): %s", p->Name(), p->Version(), p->Description());

Bei mir wurde der Timer auch angelegt wenn VPS angekreuzt war.

Nimmst Du noch eine weitere Sendung mit der gleichen VPS Zeit auf?

Ich hab mal mit dem Suchtimer

29:Sportschau - Bundesliga am Sonntag:0:::1:S19.2E-1-1021-28337:0:0:1:0:0:0:::1:0:0:0::50:99:0:0:1:0:0::0:0:0:0:0:0:0:0:0:0:0:0::1:0:0:0:0:0:0:0:0:0:90::0

getestet. Hat einen Timer für heute 21:45 angelegt.

Quote from kfb77

Ich vermute mal, da ist ein "=" zu viel drin.

Sehe ich auch so. Hat mein Compiler nicht gefunden, danke für den Fehlerreport.

Im git ist ein Update

Quote from kfb77

Der letzte Commit hat ein Problem: "Verzeichnis" beim Timer anlegen funktioniert nicht mehr. Timer werden grundsätzlich ohne angegebenes Verzeichnis erstellt. Ein revert vom letzten Commit beseitigt das Problem.

Im git ist ein Update. Bitte testen

Quote from kfb77

- Wenn ich einen Timer mit Überwachung "Sendungskennung" (also Event ID) oder "Uhrzeit" anlege, sorgt epgsearch aufgrund des AUX Feldes im Timer dafür, dass die Zeiten des Timers bei Änderung des Events verschoben werden, auch ohne dass es einen Suchtimer dafür gibt ?

Ja.

Quote from kfb77

VDR arbeitet bei "nicht VPS" Timer grundsätzlich immer nach der Uhrzeit ?

Ja, außer bei "Pattern-Timern".

Quote from kfb77

- Was passiert, wenn sich die Event ID ändert ? Erfolgt dann keine Aufnahme oder macht epgsearch einen Fallback zur Uhrzeit bei der Suche und aktualisiert die Event ID ?

Das müsste in der Dokumentation von epgsearch stehen. Schlimmstenfalls hat ein anderes Event diese Event ID bekommen und dann wird das andere Event aufgezeichnet

Quote from kfb77

- So eine Option macht beim Anlegen eines Suchtimers keinen Sinn, da dies eh Funktion jedes Suchtimers ist ?

Ja. Es geht ja darum, das korrekte Event zu identifizieren. Und das mach bei Suchtimern epgsearch ja über die Felder im Suchtimer.

Quote from wmautner

Mal was anderes:

Ich habe vdr-plugin-tvscraper in Version 1.2.10 installiert ...

Poste doch mal die Zeile in Deiner syslog, die

initializing plugin: tvscraper

enthält.

Quote from shofmann

Aber wenn der VDR in seinem eigenen Timer-Dialog:

… die Überwachung per Senderkennung anbietet, gehe ich davon aus, dass er sich auch selbst darum kümmert und Verschiebungen trackt.

Das ist nicht das original VDR Timer Menü. Das ist das Timer Menü von epgsearch

Ich muss da glaube ich etwas ausholen:

Normalerweise will ich mit einem Timer ein Event aufzeichnen. Die Frage ist nun, wie kann ich ein Event eindeutig identifizieren? Dass die Sender gelegentlich mal Zeiten verschieben, ist ja bekannt. Also gibt es:

1. VPS: Klar definiert und im Standard und von VDR ohne Plugins unterstützt: Ein Event bekommt eine VPS Zeit, und diese VPS Zeit ändert sich nicht, auch wenn sich das Event verschiebt. Bei einem VPS Timer zeichnet VDR alle Events auf, die diese VPS Zeit haben. Auch dann, wenn sich diese Events verschieben und die Startzeit der Events nichts mehr mit der VPS Zeit zu tun hat. Einziger Nachteil: Der Sender muss das unterstützen
2. Sendungskennung == "Event ID": Der Sender schickt bei jedem Event eine ID mit. Leider nicht immer die gleiche ID, d.h. wenn die ID von "Avengers" gestern noch 4567 war, kann sie heute auch 1234 sein. Manche Sender ändern diese IDs recht oft, bei anderen bleibt sie meistens stabil. Erfahrung: Wenn ein Event ganz neu in's EPG kommt, ändert sich die ID mit sehr hoher Wahrscheinlichkeit. Wenn das Event schon 1-2 Tage im EPG ist, bleibt die ID normalerweise stabil. Es gibt aber auch Sender, bei denen diese ID nie stabil bleibt ...
3. Uhrzeit: Epgsearch merkt sich Start und Dauer des Events, und versucht anhand dieser Daten ein verschobenes Event wiederzufinden. Vorteil: Funktioniert auch, wenn der Sender die Event-ID ändert. Sollte insbesondere bei kleineren Änderungen der Startzeit sehr zuverlässig funktionieren. Sender ändern normalerweise die Dauer der Events nicht.
4. VDR ohne VPS und ohne Epgsearch: VDR wählt das Event mit der größten Überdeckung. Also das Event, das möglichst vollständig im Zeitraum (Timer Start - Timer Stop) liegt. Um dies möglichst gut machen zu können, verkürzt VDR gegebenenfalls die Timer-Margin (vorne und hinten), so dass beim Anlegen des Timers der Timer nur ein Event überdeckt. Sicherlich die schlechteste Option: Durch die später nicht mehr reproduzierbare Änderung von Start und Endzeit des Timers wird es schwieriger, des original Event zu identifizieren. Ich kann später nicht einmal mehr die Länge des Events herausfinden, zu dem der Timer angelegt wurde. Dass das Event dann möglicherweise nicht mehr korrekt identifiziert wird, ist weniger schlimm: VDR zeichnet von Timer Start - Timer Stop auf, da ist das Event egal. Übel ist, dass durch die Verkürzung der Timer-Margins ein Stück der Sendung fehlen kann, obwohl sie sich nur sehr wenig verschoben hat. Siehe Vor- und Nachlauf bei Aufnahmen

~ Markus

Ich hätte jetzt angenommen, dass epgsearch die von epgsearch angelegten Suchtimer immer überwacht

Im git ist ein Update für die Timer-Überwachung. Bitte testen

Im dynamite git ist v0.3.3. In dieser Version wird MainThreadHook nicht mehr verwendet.

> dass nichts passiert.

Dann würde ich dynamite so ändern, dass nach

cPlugin::Start().

OSD Meldungen ausgegeben werden (also Skins.QueueMessage() aufgerufen wird). Wenn diese Meldungen dann einfach nicht erscheinen, ist das kein Problem. Falls es doch Probleme gibt, müssen wir dafür eben eine Lösung finden.

Was passiert denn, wenn ein Plugin

Quote

Skins.QueueMessage(mtInfo, *osdMsg);

zu früh aufruft?

Wird das dann einfach ignoriert (also es passiert nichts) oder gibt es Probleme (VDR bleibt stehen, stürzt ab, ...)?

Hi,

das Plugin dynamite wartet zur Zeit bis zum ersten Aufruf von MainThreadHook, bevor OSD Meldungen ausgegeben werden.

Kann man das anders lösen? Bzw, worauf sollte ein Plugin vor der Ausgabe der ersten OSD Meldung warten?

~Markus