[ANNOUNCE] vdr-epgsearch-0.9.16

rdnzl · 21. April 2006

Hallo winni,

ich fand gut das man sehen konnte, welcher Suchbegriff ür den enstandenen Timer
verantwortlich war (bevor KS da was geändert hatte). Die Infos schreibst Du zwar in die timers.conf und die jew. indo.vdr, aber am Bildschirm kann man die Info nicht mehr so einfach abrufen.
Zusätzlich (oder als Alternative) fände ich einen Sprung aus dem Timer-Menü heraus ins
edit des entspr. Suchbegriffs klasse. Ich habe mehr als 200 Suchbegriffe (169/266 aktiv), das wäre eine große Erleichterung.

MfG

winni · 21. April 2006

Zitat

ich fand gut das man sehen konnte, welcher Suchbegriff ür den enstandenen Timer

das vermisse ich auch! Oft sucht man sich dämlich, wenn man rausbekommen will, welcher Suchtimer einen Timer verursacht hat. Ich hätte dazu aber vielleicht eine Idee: Ich liefere ja den timercmds-Patch mit aus. Damit sollte es eigentlich möglich sein, ein kleines Skript auf den Timer loszulassen, der einem die Bezeichnung des Suchtimers zurückgibt. Gleiches könnte man bei den Aufnahmen machen (zumindest der soppa???-Skin zeigt die Infos ja bereits so an). Da Skripten nicht meine Stärke ist (vejoun weiß das :D), Freiwillige vor.

Tschüss,

winni

vejoun · 21. April 2006

Stimmt, timercmds-Patch dafür zu verwenden, darauf bin ich gar nicht gekommen. Ich probier das mal aus, dann gibts nachher evtl. ein Script.

winni · 21. April 2006

super!
Du kommst wahrscheinlich auch selber drauf, aber nur so zur Hilfe:

Code

+//Parameter format TimerNumber 'ChannelId' Start Stop 'Titel' 'Subtitel' 'file' RecNumer
+//                 1           2           3     4    5       6          7      8

über die TimerNumber müßte man eigentlich auf die richtige Zeile in der timers.conf kommen. Eleganter wäre es vielleicht sogar, über die TimerNumber+1 per SVDRP den Timer-Eintrag vom VDR zu holen.

Danke,

winni

vejoun · 21. April 2006

Leider compiliert er hier mit dem Patch nicht mehr... Hast Du eine Idee?

Code

g++ -fPIC -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video1.0\" -DPLUGINDIR=\"./PLUGINS/lib\"  menu.c
menu.c:1055: error: no 'eOSState cMenuTimers::Commands(eKeys)' member function declared in class 'cMenuTimers'
menu.c: In member function 'virtual eOSState cMenuTimers::ProcessKey(eKeys)':
menu.c:1116: error: no matching function for call to 'cMenuTimers::Commands()'
menu.c:1055: note: candidates are: eOSState cMenuTimers::Commands(eKeys)
make: *** [menu.o] Fehler 1

winni · 21. April 2006

komisch. Nach dem Patch sieht das bei mir so aus:

Code

// --- cMenuTimers -----------------------------------------------------------


class cMenuTimers : public cOsdMenu {
private:
  int helpKeys;
  eOSState Edit(void);
  eOSState New(void);
  eOSState Delete(void);
  eOSState OnOff(void);
  eOSState Info(void);
  cTimer *CurrentTimer(void);
  eOSState Commands(eKeys Key = kNone);
  void SetHelpKeys(void);
public:
  cMenuTimers(void);
  virtual ~cMenuTimers();
  virtual eOSState ProcessKey(eKeys Key);
  };

Alles anzeigen

bei Dir nicht? Wichtig ist also die Zeile mit "eOSState Commands(eKeys Key = kNone);"

Richtig testen kann ich es hier leider nicht, weil ich keinen Compiler da hab.

/Edit: doch noch Compiler gefunden Also hier kompiliert er problemlos, wenn ich den patch gegen 1.3.47-vanilla laufen lasse

winni

vejoun · 21. April 2006

Jetzt geht's. Der Patch hat wohl nicht genug Context-Zeilen. Bei mir wurde
"eOSState Commands(eKeys Key = kNone);"
an eine ganz andere Stelle in den Code gesetzt.

gestein · 21. April 2006

vejoun:
Das wäre eine Möglichkeit. Probier ich heute mal.

winni:
Eigentlich möchte ich, dass automatisch eine der Wiederholungen genommen wird, wenn sich um 20:15 2 Sendungen überschneiden.
Es nervt nämlich auch ziemlich, dass immer die Meldung "Timer-Konflikte gefunden" angezeigt wird.

Aber mit dem Hinweis von vejoun sollte es vielleicht gehen.

Danke, lg, Gerhard

vejoun · 21. April 2006

So, hier das Script timercmds-auxinfo.sh v0.1.

SVDRP geht nicht, aus den CMDs heraus reagiert VDR ja nicht drauf. Aber die timers.conf lesen sollte immer gehen, da VDR ja sofort nach einer Timeränderung die Datei schreibt.

winni
Dauert es bei dir auch so lange bis das Menü kommt wenn man die 0 drückt? Etwa 4s bei mir.

gestein
Eine Konfliktverwaltung war angedacht, aber das ist ziemlich komplex. Aber das kommt bestimmt irgendwann in der Zukunft, oder winni?

EDIT: v0.2 weiter unten.

winni · 21. April 2006

vielen Dank!

(ausprobieren kann ich es leider erst heut abend/morgen). Kommt dann mit in die nächste Version. Endlich nicht mehr suchen müssen.

Zitat

Dauert es bei dir auch so lange bis das Menü kommt wenn man die 0 drückt? Etwa 4s bei mir.

meinst Du im gepatchten Timermenu oder bei epgsearch?

Zitat

Eine Konfliktverwaltung war angedacht, aber das ist ziemlich komplex. Aber das kommt bestimmt irgendwann in der Zukunft, oder winni? großes Grinsen

Du weißt ja, dass daran schon jemand anderes bastelt. Er ist mittlerweile auch schon weiter. Fraglich ist, ob ich das dann auch so verwenden kann, dass es innerhalb einer Suche funktioniert. Aber erstmal sehen, was kommt.

Tschüss,

winni

vejoun · 21. April 2006

Ich meine das gepatchte Timermenü.. Dort 0 drücken und dauert recht lang bis was kommt...

Ich weiss das jemand am Timermenü-Plugin bastelt, ich warte schon ganz ungeduldig drauf.

winni · 21. April 2006

vejoun:
Script funktioniert wunderbar! Danke nochmal.
Hab übrigens keine Wartezeiten bei '0'.

Tschüss,

winni

vejoun · 21. April 2006

Ich habe den Patch bei mir gepatcht, jetzt habe ich auch keine Wartezeit mehr. Der Patch scheint die Aufnahmen nochmal zu laden? Das braucht bei mir über NFS einige Sekunden.
Ich habe jetzt den 8. Parameter entsorgt. a) brauche ich ihn nicht und b) weiss ich auch gar nicht wofür der gut ist...

Code

if(pEvent) {  
// create a dummy recording to get the real filename
        cRecording *rc_dummy = new cRecording(ti, pEvent);
//        Recordings.Load();
//        cRecording *rc = Recordings.GetByName(rc_dummy->FileName());

        delete rc_dummy;
//        if(rc)
//           iRecNumber=rc->Index() + 1;
     }


//Parameter format TimerNumber 'ChannelId' Start Stop 'Titel' 'Subtitel' 'file' RecNumer
//                 1           2           3     4    5       6          7      8
//     asprintf(&parameter, "%d '%s' %d %d '%s' '%s' '%s' %d", ti->Index(), 
     asprintf(&parameter, "%d '%s' %d %d '%s' '%s' '%s'", ti->Index(), 
                                                             *ti->Channel()->GetChannelID().ToString(),
                                                             (int)ti->StartTime(),
                                                             (int)ti->StopTime(),
                                                             CHECK_2PTR_NULL(pEvent, pEvent->Title()),
                                                             CHECK_2PTR_NULL(pEvent, pEvent->ShortText()),
                                                             ti->File()); //,
//                                                             iRecNumber);

Alles anzeigen

gestein · 21. April 2006

Vielleicht ist es jetzt nicht mehr notwendig die Recordings neu zu laden.
Der Parameter hat aber seinen Sinn.

So funktioniert die Verknüpfung von Timer zur Aufnahme.
Damit kann man im Timermenü die Wiedergabe eines gerade laufenden Timers starten ohne ins Aufnahmemenü zu wechseln und suchen zu müssen.

Das war der eigentliche Sinn des Patches.

lg, Gerhard

vejoun · 21. April 2006

Das der 8. Parameter eigentlich einen Sinn hat ist klar. Jetzt verstehe ich auch welchen. Ich war nicht so ganz schlau draus geworden. Dann probier ich das mal nur ohne Recordings.Load(); Das sollte VDR ja inzwischen immer intern aktuell haben.

Danke Gerhard

ravemax · 21. April 2006

Zitat

Original von winni..sicher nicht vor vdr-1.5.

Kann ja nicht mehr lange dauern. 1.4. scheint ja vor der Tür zu stehen.

Zitat

geht schon länger. Du kannst einen Suchtimer anlegen und dort einstellen 'nur ankündigen'. Es wird also dann kein Timer programmiert, sondern nur per OSD angekündigt.

Sehe schon, muss ich nochmal "README" wälzen. Wunderbar - Danke

rdnzl · 22. April 2006

Danke Ihr beiden, nehme das Script natürlich dankbar an !

Taste mich gerade an VPS heran, da KS das forciert.

Sehe ich das richtig, Autotimer werden nur nach Prüfung mit den EPG-Daten erstellt ?
(Das Flag wird aber nicht gesetzt)

Wie ist das mit manuellen Timern ?

Vielleicht kommt VPS in Mode, evtl. einen globalen Seup-Parameter spendieren ?

MfG

winni · 23. April 2006

Zitat

Sehe ich das richtig, Autotimer werden nur nach Prüfung mit den EPG-Daten erstellt ?
(Das Flag wird aber nicht gesetzt)

Wie ist das mit manuellen Timern ?

sowohl beim Suchtimer wie bei manuellen Timern (genauso wie im 'normalen' VDR-Timer-Edit-Menü) mußt Du VPS explizit einschalten. Sollte eigentlich funktionieren, auch wenn ich es schon ewig nicht mehr benutzt habe.

VPS ist immer so eine Sache. Die paar Sender, die es unterstützen, senden oft auch Mist, weshalb mir die normalen Timer lieber sind.

Tschüss,

winni

vejoun · 23. April 2006

Hi,

Hier timercmds-auxinfo.sh v0.2. Der passende Timer wird jetzt anders aus der timers.conf gefischt.

VDR schreibt zwar bei einer Timeränderung die timers.conf, abgelaufene Timer werden aber erst bei einem Neustart (oder evtl. bei einer Timeränderung) aus der timers.conf entfernt. v0.1 kam dann durcheinander.

EDIT: Neue v0.4 weiter unten.

winni · 23. April 2006

vejoun: Danke für die neue Skript-Version, aber entweder steh ich auf'm Schlauch oder irgendwas stimmt nicht. Bekomme bei allen Timer 'No AUX data found'.

winni

[ANNOUNCE] vdr-epgsearch-0.9.16

Jetzt mitmachen!

Teilen