Tester gesucht: Konfliktanzeige für Remotetimers

schmirl · 15. Juli 2013

Hallo zusammen,

auf Anregung von Manfred Heindl habe ich remotetimers um eine auf epgsearch basierende Konfliktanzeige erweitert. Bevor ich eine neue Version veröffentliche, wäre es mir ganz recht, wenn es noch der eine oder andere Testen könnte. Anbei ein Patch für remotetimers-1.0.0.

Der Patch lässt sich auch fast problemlos auf remotetimers-0.1.7 anwenden. Lediglich das patchen der Übersetzungsdateien und des Makefiles schlagen fehl. Im Makefile muss die OBJS= Zeile um conflict.o erweitert werden und bei Bedarf die zusätzliche Übersetzung in das po-Fiile eintragen - schon läuft's auch mit VDRs vor 1.7.36.

Für die Konfliktanzeige muss auf dem Server (wenn der Client selbst auch aufnehmen kann dann ggf. auch auf dem Client) das epgsearch-Plugin installiert sein.

Als zweiter Buchstabe in der Remotetimers Timer-Liste erscheint ein Ausrufezeichen, wenn ein Timer nicht komplett aufgenommen werden kann. In den Details des betroffenen Timers werden dann die am Konflikt beteiligten Timer angezeigt.

louis · 15. Juli 2013

Hallo schmirl,

ich benutze remotetimers zwar nicht selbst, aber Kollege Saman ist gerade dabei, das search&recordings Menü vom TVGuide (siehe meine Signatur) per remotetimers auch Client Server fähig zu machen (siehe dieser Thread). Deshalb die Frage: kann man die Timerkonflikte auch per Serviceinterface vom remotetimers Plugin abfragen? Wenn nicht, dann wäre das noch ein Feature Request Optimal wäre es, wenn das Ergebnis für die Abfrage der Timerkonflikte per remotetimers auf dem Client das analoge Format hätte wie wenn ich es von epgsearch per Serviceschnittstelle abfrage...

Ciao Louis

Saman · 16. Juli 2013

Moin,

habe den Patch angewendet, patchen und übersetzen mit remotetimers-1.0.0 ging ohne Probleme.
Timer-Konfilikte werden am Client angezeigt.

Gruß S.

Saman · 16. Juli 2013

Hi nochmal,

Zitat

Als zweiter Buchstabe in der Remotetimers Timer-Liste erscheint ein Ausrufezeichen, wenn ein Timer nicht komplett aufgenommen werden kann. In den Details des betroffenen Timers werden dann die am Konflikt beteiligten Timer angezeigt.

bei Serientimern wird ja auch ein Ausrufezeichen angezeigt, könnte das dann geändert werden?

Gruß S.

schmirl · 17. Juli 2013

Erstmal Danke für's testen und das Feedback!

Zitat

bei Serientimern wird ja auch ein Ausrufezeichen angezeigt, könnte das dann geändert werden?

Hm - letzlich zeige ich bei all den Timern ein Ausrufezeichen an, von denen epgsearch behauptet, es gäbe einen Konflikt. Nun muss ich dazu sagen, dass ich epgsearch nicht nutze und mich daher mit dessen Features nicht wirklich auskenne. Reden wir bei "Serientimern" über normale VDR Timer die an bestimmten Wochentagen laufen oder ist das etwas Spezielles von epgsearch?

Zitat

Deshalb die Frage: kann man die Timerkonflikte auch per Serviceinterface vom remotetimers Plugin abfragen?

Prinzipiell ja, ist allerdings nicht ganz so trivial wie es auf den ersten Blick aussieht. Das Problem ist, dass ggf. remotetimers einzelne Timer vom Server nicht einlesen kann. Das ist dann der Fall, wenn der zugehörige Kanal auf dem Client nicht bekannt ist. Somit stimmt der timer->Index() auf dem Client unter Umständen nicht mit dem auf dem Server überein. Aus diesem Grund führe ich bei den Remote-Timern auch immer den serverseitigen Index mit. Dazu habe ich eine Subklasse von cTimer gebildet, die ich aber ungern in der Service-Schnittstelle exportieren möchte. Am symphatischsten wäre mir da eine Erweiterung der Service-Aufrufe, so dass diese zusätzlich den serverseitigen Index zurückgeliefern. Um welche Service-Aufrufe geht es denn? Genügt ForEach oder sind auch GetTimer, GetMatch, GetTimerByEvent, NewTimerByEvent, NewTimer oder ModTimer relevant?

Zitat

Optimal wäre es, wenn das Ergebnis für die Abfrage der Timerkonflikte per remotetimers auf dem Client das analoge Format hätte wie wenn ich es von epgsearch per Serviceschnittstelle abfrage...

Ich gehe davon aus, es muss keine std::list<std::string> sein, sondern es genügt, wenn die einzelnen Zeilen das selbe Format haben? Ich könnte mir einen Service-Aufruf vergleichbar zu ForEach vorstellen.

louis · 17. Juli 2013

Hi,

hm...wie kann es denn sein dass es Kanäle vom Server nicht auf dem Client gibt, wenn der Client per streamdev mit dem Server verbunden ist? Nicht dass ich deine Aussage bezweifeln will, das ist rein interessehalber, denn das muss dann im TVGuide natürlich auch berücksichtigt werden und macht das ganze ein gutes Stück komplizierter.

Ich benutze im TVGuide den folgenden Code, um mir die Timerkonflikte von epgsearch zu holen:

Code

Epgsearch_services_v1_1 *epgSearch = new Epgsearch_services_v1_1;
if (epgSearchPlugin->Service("Epgsearch-services-v1.1", epgSearch)) {
    std::list<std::string> conflicts = epgSearch->handler->TimerConflictList();
    ....
}

std::list<std::string> muss es sicherlich nicht sein, wichtig wäre, dass das Format erhalten bleibt:

Code

/* TIMERCONFLICT FORMAT:
    The result list looks like this for example when we have 2 timer conflicts at one time:
    1190232780:152|30|50#152#45:45|10|50#152#45
    '1190232780' is the time of the conflict in seconds since 1970-01-01. 
    It's followed by list of timers that have a conflict at this time:
    '152|30|50#1    int editTimer(cTimer *timer, bool active, int prio, int start, int stop);
    52#45' is the description of the first conflicting timer. Here:
    '152' is VDR's timer id of this timer as returned from VDR's LSTT command
    '30' is the percentage of recording that would be done (0...100)
    '50#152#45' is the list of concurrent timers at this conflict
    '45|10|50#152#45' describes the next conflict
    */

Alles anzeigen

Ciao Louis

mini73 · 17. Juli 2013

Moin!

Zitat von louis

hm...wie kann es denn sein dass es Kanäle vom Server nicht auf dem Client gibt, wenn der Client per streamdev mit dem Server verbunden ist?

Indem man einfach ein paar Kanäle auf dem Client weglässt. Die Kanallisten werden doch nicht automatisch abgeglichen, oder?

Lars.

Saman · 20. Juli 2013

Zitat von schmirl

Hm - letzlich zeige ich bei all den Timern ein Ausrufezeichen an, von denen epgsearch behauptet, es gäbe einen Konflikt. Nun muss ich dazu sagen, dass ich epgsearch nicht nutze und mich daher mit dessen Features nicht wirklich auskenne. Reden wir bei "Serientimern" über normale VDR Timer die an bestimmten Wochentagen laufen oder ist das etwas Spezielles von epgsearch?

Ich nutze selber keine Serientimer und kenne mich da auch nicht richtig aus. Mir ist beim rumprobieren nur aufgefallen, das bei einem Serientimer mit Konflikt jetzt zwei Ausrufezeichen angezeigt werden. Eines für den Serientimer und eines für den Konflikt. Gemischt mit Serientimern ohne Konflikt und normalen Timern mit Konflikt wirkt die Ansicht dann ein bisschen unübersichtlich.

Gruß S.

schmirl · 23. Juli 2013

Saman: Jetzt hab' ich's kapiert. Werde das Ausrufezeichen durch Prozent ersetzen.

louis: Kämpfe noch mit der Service-Schnittstelle. Könntest Du genauer beschreiben, wie Du mit den Timer-IDs aus epgsearch weiter vorgehst?

* Du hast die epgsearch Timer-ID und willst den dazu gehörigen Timer - also im Prinzip ein Timers.Get(index);. Das wäre recht einfach.
* Du hast den Timer (genauer den Timer->Index()) und suchst in den epgsearch-Zeilen danach - in diesem Fall dürfte ich Dir nicht die Original-Zeilen von epgsearch liefern sondern die mit umgerechneter ID

Oder brauchst Du sogar beide Varianten?

louis · 23. Juli 2013

Hi Schmirl,

ich denke, wir müssten erst mal generell definieren, was in einer Client-Server Umgebung der Client alles "können soll". Deine Anmerkung, dass es auf den Clients z.B. nicht alle Kanäle des Servers geben muss, habe mich ein bisschen nachdenklich gemacht

Läuft der tvguide auf einem VDR mit eigenen DVB Karten, dann ist es eigentlich relativ einfach. Nur User an diesem VDR legen Timer an, und der der den Timer angelegt hat, muss sich auch um die auftretenden Timerkonflikte kümmern. Einen Eindruck, wie das im tvguide realisiert ist, siehst du auf diesem Screenshot. Bei einem akuten Timerkonflikt kann direkt der entsprechende Timer gelöscht oder so angepasst werden, dass der Konflikt aufgelöst ist.

Bei einer Client / Server Umgebung ist die Lage natürlich ein bisschen anders. I.d.r. gibt es mehrere Clients, alle angelegten Timer landen aber auf dem Server, somit entstehen da auch die Timerkonflikte. Auf der anderen Seite ist die Frage, ob jemand am Client 1 das Recht haben soll, Timer, die von einem anderen Client 2 angelegt worden sind, womöglich noch auf einem Kanal, den es am Client 1 gar nicht gibt, zu bearbeitet bzw. zu löschen?!

Nun aber zu deiner eigentlichen Frage: ich beschreibe am besten kurz, was ich genau mache: nach dem Anlegen eines neuen Timers hole ich mir von epgsearch per Service Call die Liste aller vorhandenen Timerkonflikte als std::list<std::string>. Diese Zeilen parse ich, extrahiere die Timer IDs und hole mir über die IDs die pro Konflikt involvierten Timer Objekte per Timers.Get(ID). Mittels dieser Timer Objekte berechne ich dann die Zeit, in der der Konflikt auftritt. Ich würde jetzt also mal vorsichtig behaupten, ich benötige deine Variante 1

Ciao Louis

louis · 23. Juli 2013

PS: ich hole mir zur Anzeige über den jeweiligen Timer per timer->Channel() und timer->Event() den zugehörigen Kanal bzw. Event. Würde das bei remotetimern auch funktionieren? Wohl definitiv nicht, wenn der Kanal auf dem Client gar nicht verfügbar ist oder?!

schmirl · 24. Juli 2013

Danke louis, jetzt kann ich mir das auch genauer vorstellen wo es hingehen soll.

Bei den Timern die Du von remotetimers bekommst, kannst Du natürlich Channel und Event abrufen. Timer für Kanäle, die auf dem Client nicht exisiteren, lassen sich auf dem Client nicht erstellen. Remotetimers muss diese ignorieren. Wenn ich Dir per Service-Schnittstelle die Konflikte liefere und Du dann den Timer zu einer ID holst, wirst Du in diesem Fall NULL zurückbekommen. Erkennen kannst Du das Problem also, falls Du das in irgendeiner Form auch anzeigen willst.

Das mit den Berechtigungen würde ich momentan nicht überbewerten. In Remotetimers gibt es seit Jahren die Möglichkeit, Timer und Aufnahmen per Benutzer-ID nicht für jedermann sichtbar zu machen. Über Nummern-Taste kann die sichtbare ID einfach umgeschaltet werden. Es hat noch niemand nachgefragt, ob man die ID fest vorgeben kann (z.B. über Plugin Parameter), so dass die Benutzer-ID über OSD nicht umgeschaltet werden kann. Von daher glaube ich, spielt die Berechtigungs-Geschichte auf Client-Ebene keine große Rolle. Und wenn es um Zugriffsschutz geht, dürfte das PIN-Plugin besser geeignet sein, da es das Objekt um das es geht als solches schützt - egal auf welchem Client.

schmirl · 3. August 2013

Habe im ersten Post eine neue Version des Patches angehängt. Neben kleinen kosmetischen Änderungen in den Menüs gibt es nun auch die zwei gewünschten Service-Calls: "RemoteTimers::ForEachConflict-v1.0" und "RemoteTimers::GetTimerById-v1.0".

mane77 · 26. April 2014

Hallo Community,

vermelde nach längerer Abwesenheit Erfolg !

Einen herzlichen Dank an Schmirl zum Umsetzen meiner Anregung im Remotetimers-Plugin.
Aktuell laufen Client(s) und Server auf vdr-2.0.6 mit den jeweiligen heute aktuellen Plugin-Versionen und die Funktionalität ist wie erwartet. Klasse !

Lg, Mane77

Tester gesucht: Konfliktanzeige für Remotetimers

Jetzt mitmachen!

Teilen