RFC: Striktes Locking für Timer etc.

Mein Skin ist auch betroffen und ich bin auch für Variante 2.
Dies ist einfach sauberer auch für die Zukunft!

Grüße
Martin

Zitat von kls

Vorerst noch nicht konkret, aber das kann noch kommen...

Prima, ich hab Zeit und kann warten.

Lars.

Zitat

Erstmal werden die Timer remote
verwaltbar, dann sehen wir weiter.

Klaus

Ich kann nicht warten

Hi,

was mir in dem Zusammenhang einfällt: Bisher klappt der Zugriff auf die svdrpsend Schnittstelle per netcat (nc) leider nicht vollständig, bzw. nur nach Patchen des VDRs. Kannst Du bei Deinen Umbauten mal schauen ob sich das ändern lässt? Ich würde die Schnittstelle gerne so nutzen:
Beispiel:

echo -e "HITK menu\nQUIT" | nc 127.0.0.1 6419

Ich bin gerade leider nicht sicher, ob es ohne meinen Patch http://www.minidvblinux.de/git/?a=viewblob&p=vdr&h=5fa142688ca00e948d21ec72ec89fa9acfeeb9eb&hb=3ea186d2edd9d08f9238ce7ea17aab3b30f2f202&f=src/25_vdr_svdrp.patch ein grundlegendes Problem mit nc gibt, oder ob der Patch nur nötig war, um per nc auch eine Frage stellen zu können, und die Antwort zurück zu bekommen.

Claus

In was für ein Problem läufst du da ohne Patch? Ich bekomme auf meinem yaVDR mit VDR 2.2.0 ohne diesen Patch eine Antwort zurück.

$ echo -e "HITK menu\nQUIT" | nc 127.0.0.1 6419
220 VDR SVDRP VideoDiskRecorder 2.2.0; Wed Jun 10 13:59:41 2015; UTF-8
250 Key "menu" accepted
221 VDR closing connection

Wenn ich das richtig verstehe blockierst du die Verarbeitung weiterer SVDRP-Befehle, bis der aktuelle Befehl ausgeführt wurde.

Dito mit easyVDR

easyvdr@easyVDR:~$ echo -e "HITK menu\nQUIT" | nc 127.0.0.1 6419
220 easyVDR SVDRP VideoDiskRecorder 2.0.6; Wed Jun 10 16:44:08 2015; UTF-8
250 Key "menu" accepted
221 easyVDR closing connection

Restfulapi freut sich auf den StateKey
Planst du den auch in die Aufnahmen einzubauen?

xvdr und vnsi sind auch betroffen.

Zitat von hannemann

Restfulapi freut sich auf den StateKey
Planst du den auch in die Aufnahmen einzubauen?

Die haben sowas schon, wenn auch nicht ganz so schön: http://projects.vdr-developer.…git/tree/recording.h#n250
Aber ich denke mal, das neue Interface wird es auch für die Aufnahmen geben. Insgesamt also Timer, Aufnahmen, Kanäle und EPG. Und irgendwann später mal die Geräte...
Hab ich was vergessen?

Lars.

Aaaahh... Danke

Ich denke schon länger darüber nache, restfulapi beizubringen Antworten zu cachen bzw. dem Client mitzuteilen, ob er überhaupt eine neue Liste braucht.

Zitat von mini73

Hab ich was vergessen?

Möglicherweise die Liste von VDRs, die Remote Timer anlegen dürfen

Wird das anlegen und auslesen von Timern auf einem Remote VDR transparent sein?
Ich frage mich, ob das z.B. auch mit Kodi funktionieren wird, was mir mit dem Remotetimers Plugin nicht gelingen wollte. Ich meine mich zu erinnern, das ich in Kodi bzw. damals XBMC die Timerliste des Servers auch nicht sehen konnte.

Das wird sich zeigen, wenn es die nächste Version gibt.

Lars.

Zitat von hannemann

Ich meine mich zu erinnern, das ich in Kodi bzw. damals XBMC die Timerliste des Servers auch nicht sehen konnte.

vnsi und xvdr sollten die Timer des VDR auf dem das Plugin läuft eigentlich anzeigen.

Ich weiss es nicht mehr genau. Zumindest konnte ich keine Timer auf dem Server anlegen.

Dann wird ja jedes Plugin in der Lage sein einen Timer auf dem default Host anzulegen.

Super Sache

Und die remote Timer sind auf jedem vernetzten VDR sichtbar?

Zitat von seahawk1986

In was für ein Problem läufst du da ohne Patch? Ich bekomme auf meinem yaVDR mit VDR 2.2.0 ohne diesen Patch eine Antwort zurück.

Code

$ echo -e "HITK menu\nQUIT" | nc 127.0.0.1 6419
220 VDR SVDRP VideoDiskRecorder 2.2.0; Wed Jun 10 13:59:41 2015; UTF-8
250 Key "menu" accepted
221 VDR closing connection

Wenn ich das richtig verstehe blockierst du die Verarbeitung weiterer SVDRP-Befehle, bis der aktuelle Befehl ausgeführt wurde.

Ich hab das nun noch mal getestet. War ja schon ein wenig länger her, dass ich den Patch erstellt hatte.
Das Problem besteht nur, wenn per svdrp eine Frage gestellt werden soll, und das Script dann auf die Antwort des Users warten muss. Ohne den Patch, wird die Verbindung nicht mehr geschlossen, und obendrein, wird die Liste der Plugins zurück gegeben.
Ich habe nun also ein Plugin, welches u.A. dies enthält:

cString cPluginPackages::SVDRPCommand(const char *Command, const char *Option, int &ReplyCode)
{
    if (strcasecmp(Command, "ASK") == 0) {
        if (Interface->Confirm(Option)) {
            ReplyCode = 901;
            return cString::sprintf("yes");
        } else {
            ReplyCode = 900;
            return cString::sprintf("no");
        }
    }
    return NULL;
}

Wenn ich nun diesen Befehl absetze:

$ echo -e "PLUG myplugin ASK Alles OK?\nQUIT" | nc 127.0.0.1 6419

bekomme ich mit Patch diese Antwort:

220 nightbuild-64 SVDRP VideoDiskRecorder 2.2.0; Thu Jun 11 12:30:42 2015; UTF-8
901 yes
221 nightbuild-64 closing connection

ohne Patch sieht die Antwort so aus:

220 nightbuild-64 SVDRP VideoDiskRecorder 2.2.0; Thu Jun 11 12:39:17 2015; UTF-8
214-Available plugins:
214-dummydevice v1.0.2 - Output device that does nothing
214-skincurses v2.2.0 - A text only skin
214-myplugin v0.1.0 - Only a test
214 End of plugin list
901 yes

und die Verbindung wird nicht geschlossen nachdem der User OK gedrückt hat.
Verwende ich hingegen das svdrpsend Perl Script, so funktioniert das auch ohne meinen Patch. Wieso das mit dem Perl svdrpsend funktioniert, mit dem nc jedoch nicht, ist mir allerdings nicht klar.

Claus