epgsearchdone wurde nicht angelegt und timersdone war leer
Hmm, weiß gar nicht ob die sofort geschrieben werden. timersdone m.E. auch erst dann wenn der Timer wirklich erledigt, also aufgenommen wurde.
Regards
fnu
epgsearchdone wurde nicht angelegt und timersdone war leer
Hmm, weiß gar nicht ob die sofort geschrieben werden. timersdone m.E. auch erst dann wenn der Timer wirklich erledigt, also aufgenommen wurde.
Regards
fnu
Hier mal das ganze setup.conf
Irgendwie passt die setup.conf nicht zur vdr.log vom 3.6.
Ich verstehe nicht, warum da der SVDRPClientHandler gestartet wird, wenn Peering ausgeschaltet ist.
Funktioniert das manuelle Anlegen von Timern über die Programmübersicht?
Funktioniert das, wenn im epgsearch-Setup unter Timer-Programmierung VDR-Edit-Menü verwenden auf ja gestellt wird?
Hab jetzt nochmal ein neues Logpaket erstellt.
Einzeltimer über live oder Programmführer erstellen war kein Problem.
Noch eine Frage:
gehen denn an dem Rechner einfache Kommandos "svdrpsend lstt" oder "svdrpsend chan" ?
Ich habe gerade festgestellt, dass sich epgsearch nicht mehr bauen lässt:
vdr01_64 epgsearch # make
c++ -Werror=overloaded-virtual -Wno-parentheses -march=core-avx2 -O2 -pipe -g -ggdb -O0 -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fPIC -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/linux/dvb -c -DSENDMAIL='"/usr/sbin/sendmail"' -DHAVE_PCREPOSIX -DUSE_GRAPHTFT -DMAX_SUBTITLE_LENGTH='255' -DPLUGIN_NAME_I18N='"epgsearch"' -o menu_event.o menu_event.c
menu_event.c: In Elementfunktion »virtual void cMenuEventSearch::Display()«:
menu_event.c:133:3: Fehler: »MsgOsdSetEvent« ist kein Element von »cStatus«
cStatus::MsgOsdSetEvent(event);
^
make: *** [Makefile:193: menu_event.o] Fehler 1
vdr01_64 epgsearch #
VDR ist 2.3.6, aber seltsame ist, dass es gestern noch ging. Woran könnte denn das liegen?
Ist das nicht wieder das Problem von oben mit USE_GRAPHTFT?
Doch, das wars.
Ich muss mir wohl doch in Zukunft etwas mehr Mühe geben, wenn irgendwelche Sourcen kopiere.
"svdrpsend lstt" oder "svdrpsend chan"
root@datenserver:~# svdrpsend lstt
220 datenserver SVDRP VideoDiskRecorder 2.3.5; Mon Jun 5 16:31:36 2017; UTF-8
250-1 1:1:2017-06-05:2013:2155:50:99:Tatort| Amour fou:
250 2 9:1:2017-06-05:1613:1755:50:99:Niete zieht Hauptgewinn:<epgsearch><channel>1 - Das Erste</channel><update>0</update><eventid>23555</eventid><bstart>120</bstart><bstop>600</bstop></epgsearch>
221 datenserver closing connection
Cool, hatte schon selbst mal in das Makefile geschaut gehabt, mich aber nicht getraut die Änderungen zu pushen ...
Aber das "Q-Macro" hatte ich in text2skin auch reingemacht, dann aber wieder rausgenommen, nach einem "Chat" mit Klaus, auch auf seine Eingabe im Changelog zu VDR 2.3.6.
Folgender Hintergrund, wird VDR auf klassische Weise mit make gebaut, existiert ein und dasselbe Q-Macro sowohl im VDR als auch in den Plugins darunter, nicht ganz glücklich, VDR vererbt ja seines. Wir Paketbauer können hingegen "Q=@" als "MAKE_OPTIONS" (debian/rules o.ä.) relativ einfach abstrakt übergeben und erreichen das Gleiche ... ?
Ich nehme das Q-Macro aus dem Patch jetzt mal nicht auf, wenn aber eine Mehrheit streng dafür ist, schiebe ich es Upstream nach.
Gruß
Frank
Ich weiss jetzt nicht, ob überhaupt jemand hier was dazu sagt, wo dann eine Mehrheit herkommt. Bei mir führt das nur dazu, wenn ich das Plugin einzeln baue, muss ich für die nicht-geschwätzige Form
make Q=@ -C PLUGINS/src/epgsearch
aufrufen (etwas weniger intuitiv, aber ich kann mich auch daran gewöhnen)
make Q=@ -C PLUGINS/src/epgsearch
Wird das in dem Zusammenhang nicht vom VDR veerbt?
Nein, damit ruft man ja direkt das Makefile des Plugins auf.
Vererbt wird das nur, wenn man das Makefile von VDR aufruft.
Klaus
Ich habe mal noch den "vdr.epgsearch-exttimeredit" Patch an vdr-2.3.5 angepasst. Ich mal, dass das so passt.
Hi Jungs,
die MLD hat diesen patch per default drin. Nun ist mir als nicht epgsearch Nutzer aufgefallen, dass es komische Effekte gibt.
Wenn epgsearch nicht als plugin geladen ist:
1. Timer erstellen (egal wie - ob über Programme oder Timer(neu))
2. Menu - Timer - Diesen Timer auswählen mit OK (kbd oder Remote)
- der Timer wird als "neuer" Timer erstellt - neue Uhrzeiten (Anfang/Ende) stehen drin
- erneutes OK erstellt einen zweiten Timer ABER ändert nicht den ausgewählten Timer
Kann das jemand bestätigen?
Gruß
MarMic
Hi,
ich habe mal einen Blick auf den vdr.epgsearch-exttimeredit.diff geworfen. Ab der Version 2.3.1 des Diffs werden da beim edit aktionen ausgeführt, die in den original VDR Sourcen nur bei neuen Timern ausgeführt werden.
Ohne mich da jetzt näher mit zu befassen, kann ich mir gut vorstellen, das dies die von MarMic beschriebenen Probleme hervorrufen kann.
für mein Empfinden gehört der Block
cTimer *Timer = new cTimer;
if (Setup.SVDRPPeering && *Setup.SVDRPDefaultHost)
Timer->SetRemote(Setup.SVDRPDefaultHost);
in ein "if (New)" gekapselt.
Und die Zeile "return AddSubMenu(new cMenuEditTimer(Timer, true));" smüsste auch so lauten: "return AddSubMenu(new cMenuEditTimer(exttimeredit.timer, New));"
Claus
Nur mal so interessehalber: was macht eigentlich das epgsearch Timer-Menü so toll anders als VDR, daß es den ganzen Aufwand wert ist?
Klaus
Der epgsearch Diff muss so geändert werden, damit es wieder funktioniert:
--- a/vdr.epgsearch-exttimeredit-2.3.5.diff
+++ b/vdr.epgsearch-exttimeredit-2.3.5.diff
@@ -66,7 +66,8 @@ diff -Naur vdr-2.3.5.orig/menu.c vdr-2.3.5/menu.c
+ if (HasSubMenu() || Count() == 0 && !New)
return osContinue;
cTimer *Timer = new cTimer;
- if (Setup.SVDRPPeering && *Setup.SVDRPDefaultHost)
+- if (Setup.SVDRPPeering && *Setup.SVDRPDefaultHost)
++ if (New && Setup.SVDRPPeering && *Setup.SVDRPDefaultHost)
Timer->SetRemote(Setup.SVDRPDefaultHost);
+ // Data structure for service "Epgsearch-exttimeredit-v1.0"
+ struct Epgsearch_exttimeredit_v1_0
@@ -78,13 +79,14 @@ diff -Naur vdr-2.3.5.orig/menu.c vdr-2.3.5/menu.c
+ // out
+ cOsdMenu* pTimerMenu; // pointer to the menu of results
+ } exttimeredit;
-+ exttimeredit.timer = New ? (new cTimer) : GetTimer();
++ exttimeredit.timer = New ? Timer : GetTimer();
+ exttimeredit.bNew = New;
+ exttimeredit.event = exttimeredit.timer->Event();
+ if (cPluginManager::CallFirstService("Epgsearch-exttimeredit-v1.0", &exttimeredit))
+ return AddSubMenu(exttimeredit.pTimerMenu);
+
- return AddSubMenu(new cMenuEditTimer(Timer, true));
+- return AddSubMenu(new cMenuEditTimer(Timer, true));
++ return AddSubMenu(new cMenuEditTimer(exttimeredit.timer, New));
}
Alles anzeigen
Das betrifft alle Diffs ab der Version 2.3.1.
Claus
Nur mal so interessehalber: was macht eigentlich das epgsearch Timer-Menü so toll anders als VDR, daß es den ganzen Aufwand wert ist?
Klaus
naja, wenn ich weiß, was ich programmieren will (z.B. etwas im epg gefunden, was es wert ist aufgenommen zu werden) dann reicht sicherlich der Klick auf den entsprechenden Button im VDR Menu (rot?). Wenn ich aber Serien programmieren möchte oder einfach mal Sherlock nicht verpassen will, kann ich hier beliebig nach keywords aus dem EPG automatisch suchen und programmieren lassen. Speziell als Anhängsel zum VDRAdmin - Webtool möchte ich es nicht missen. Das ist ein riesiger Komfortgewinn für mich und eines der "must have" Plugins. Ein Update des VDR kann für mich immer nur funktionieren wenn auch EPGSearch die neue Version unterstützt.
Aber laß dich nicht kirre machen. Auch das Timermenu im VDR benutze ich oft. Es hat einfach beides seine Berechtigung.
mfg
msv
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!