Beiträge von schmirl

  • [Announce] Neues Plugin: peer-0.0.1

    Hallo nochmal,


    seit vielen Jahren in Planung habe ich es nun endlich geschafft, eine erste Version dieses neuen Plugins zu veröffentlichen. Es richtet sich in erster Linie an die, die kein Client/Server haben (also alle Aufnahmen erledigt ein Server) sondern eher Peer-to-Peer (mehrere VDRs, alle mit eigener DVB-Karte). Aber auch für die Client/Server-Gemeinde ist vielleicht das eine oder andere nützliche Feature enthalten. Download unter http://vdr.schmirler.de.


    Hier die aktuelle Feature-Liste:


    * Timer anlegen/bearbeiten/löschen auf lokalem VDR und Peer-VDR sowie verschieben zwischen lokal und Peer (nutzt remotetimers-Plugin)
    * Zugriff auf Menü des Peer-VDR (nutzt remoteosd-Plugin)
    * OSD-Nachricht an Peer schicken
    * Device-Status des Peers anzeigen
    * Benachrichtigt werden, wenn auf dem Peer die Wiedergabe beendet wird
    * Wake-on-LAN Paket an Peer senden


    Manches ist sicherlich noch ausbaufähig (wie der Device-Status) oder ist eher eine Machbarkeits-Studie (Benachrichtigung wenn Peer-Wiedergabe beendet).


    Die Abhängigkeiten von anderen Plugins unterscheiden sich stark - je nach gewünschten Features. Details sind im README zum Plugin zu finden. Wer die volle Funktion will, muss auf allen Peers die Plugins peer, remotetimers, remoteosd, svdrposd und svdrpservice installieren sowie den SVDRP-Zugriff für alle Peers erlauben.


    Um remotetimers und remoteosd nutzen zu können, ist jeweils mind. Version 1.0.0 dieser Plugins erforderlich. Patches für ältere remotetimers/remoteosd-Versionen kann ich auf Anfrage bereitstellen.


    In den peer-Quellen ist ein Makefile für VDR < 1.7.36 enthalten. Wie weit nach unten peer kompatibel ist, habe ich jedoch nicht getestet.


    Viel Spaß!
    Frank

  • [Announce] remotetimers-1.0.1

    Hallo zusammen,


    unter http://vdr.schmirler.de habe ich Version 1.0.1 von remotetimers veröffentlicht. In erster Linie gibt es zwei Neuerungen:


    In der Timer-Liste werden Konflikte aus epgsearch angezeigt. Dazu muss natürlich epgsearch installiert sein - auf dem Server um serverseitige Konflikte anzuzeigen, auf dem Client sofern der Client auch lokal aufnimmt. In der Timer-Liste wird bei einem Konflikt an zweiter Stelle ein "%" angezeigt. Wechselt man in den Timer zum Bearbeiten, werden Details zum Konflikt angezeigt.


    Neu sind auch die benutzerdefinierten EPG-Zeiten, wie sie epgsearch enthält. Im Setup von remotetimers können bis zu 4 Uhrzeiten festgelegt werden. Zusätzlich zu "Was läuft jetzt/als nächstes?" wird im "Programm" Menü das EPG zu den konfigurierten Zeiten angezeigt. Einfach wiederholt die Taste "Grün" drücken. Die Uhrzeit 00:00 deaktiviert die Funktion. Wer gerne das EPG für Mitternacht hätte, muss auf 00:01 oder 23:59 ausweichen ;)


    Changelog:

    Zitat

    - Fixed channel name width in schedule menus (reported by hummel99@vdrportal)
    - Added custom schedule times in addition to "Now" and "Next" as in epgsearch (suggested by hummel99@vdrportal)
    - Show timer conflicts reported by epgsearch in timers menu (suggested by Manfred Heindl)

  • Remotetimers & Benutzerdefinierte Zeiten

    Zitat

    Zum einen ist mir aufgefallen das sich das ersetzte timermenu viel langsamer öffnet als das eigene des vdr, ist das einfach so oder kann man da was machen?


    Das liegt daran, dass beim Aufruf von remotetimers erstmal die Verbindung zum Server aufgebaut werden muss, um die aktuelle Timerliste abzurufen. Ist also prinzipbedingt.

    Zitat

    Dazu werden die neuen Menüs von graphtft nicht sauber erkannt so dass hier die hinterlegte timeransicht nicht greift. Horchi wollte sich das nach seinem Urlaub anschauen und gfs ein Patch ähnlich dem bei epgsearch liefern! Wäre das ok mit dir?


    Da kann ich mir jetzt nichts drunter vorstellen. Hast Du ggf. ein Bild dazu? Aber wenn ich einen fertigen Patch bekomme, ist das nie verkehrt ;)

  • Streamdev-Client und lokale TV-Karten

    Streamdev-Client Option "Empfangssysteme / Kosten". Aus dem README:


  • Tester gesucht: Konfliktanzeige für Remotetimers

    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.

  • Tester gesucht: Konfliktanzeige für Remotetimers

    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?

  • [GELÖST] Zusammenspiel Server - Client beim Schneiden von Aufnahmen

    Was hast Du im remotetimers-Setup in der Sektion "Server Aufzeichungen" als "Unterverzeichnis" eingestellt? Da gehört bei Dir "Server" rein.


    Den Schnitt darfst Du nicht aus der laufenden Wiedergabe heraus starten. Gehe bitte im Aufnahmen-Menü von Remotetimers auf die gewünschte Aufnahme. Dort drückst Du Taste Rot (Editieren) und dann Taste Grün (Schneiden).

  • Tester gesucht: Konfliktanzeige für Remotetimers

    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.

  • streamdev-server-plugin 0.5.2: Lange Umschaltzeiten

    Vielen Dank für's Debuggen des Problems mit dem SuspendCtl. Habe die Hidden-Anpassung gleich eingecheckt :tup. Jetzt ist mir auch klar, warum neulich beim Rumspielen mit einem neuen Plugin der Server nicht mehr heruntergefahren ist :]


    Ich werde mir mal über eine saubere, im Setup konfigurierbare "Suspend beim Starten"-Lösung Gedanken machen.


    Warum das Umschalten vom LiveTV bei Dir volle 5 Sekunden braucht, ist mir allerdings ein Rätsel. Könnte sich da ein anderes Plugin oder ein Patch einmischen? Naja - ich denke, mit dem always-suspend-Patch sollte es nun auch so gehen. Und in aktuellen streamdev-Versionen läuft die Geschichte ohnehin anders.

  • streamdev-server-plugin 0.5.2: Lange Umschaltzeiten

    VDR hat immer ein Primary-Device - das ist auch mit 2.0 noch so. Wenn es kein Ausgabedevice gibt, wird einfach das erstbeste Eingabedevice dazu deklariert - also die erste DVB-Karte.


    Das Dummydevice auf dem Server ist nur dann erforderlich, wenn ein Client-Server-Plugin darauf angewiesen ist, dass der Server gerade den selben Kanal anschaut wie der Client (z.B. um mit femon auf dem Client die zum Stream passenden Signalinformationen anzuzeigen). Das Client-Plugin muss dazu den Live-Kanal auf dem Server umschalten. Ist die erste DVB-Karte das primäre Device, kann evtl. nicht umgeschaltet werden (weil z.B. auf dieser Karte gerade eine Aufnahme auf einem anderen Transponder läuft). Ist dummydevice installiert, wird stattdessen dummydevice umgeschaltet und das wiederum holt sich die Daten von der "passenden" DVB-Karte.


    Hat Dein Server nur eine DVB-Karte? In diesem Fall wäre es egal, ob er mit oder ohne dummydevice läuft.


    Zum Umschaltproblem: Wenn bei streamdev-0.5.2 keine Karte für Streaming frei ist und somit Live-TV umgeschaltet werden müsste, wird zunächst versucht, Live-TV auf eine andere Karte zu verlagern. Daher das "switching to channel 8". Erst wenn das fehlschlägt wird Live-TV auf den neuen Kanal umgeschaltet. Die Verzögerung kommt dann wohl von der "Kanal nicht verfügbar"-Meldung. Setze die Anzeigedauer für Meldungen auf dem Server doch mal auf 0 (OSDMessageTime in der setup.conf). Zur Not könntest Du den ersten Umschaltversuch aber auch aus streamdev rauspatchen.

  • Tester gesucht: Konfliktanzeige für Remotetimers

    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.

  • [Announce] remotetimers / remoteosd / svdrposd / epgsync/ svdrpservice Version 1.0.0

    Zitat von DLX

    Ich binde das Aufnahmeverzeichnis in dem auch die epg-daten liegen am Client per NFS ein. Der Client hat immer den vollen EPG. Mir ist jedenfalls noch nicht aufgefallen, dass etwas gefehlt hat. Kann es da Probleme geben? Bisher läufts ohne Probleme bei mir. Bzw. welchen vorteil bringt epgsync?


    Die epg.data wird im Normalfall nur beim Starten des VDR gelesen und beim Stoppen sowie alle 10 Minuten geschrieben. Ist zwar nicht ganz sauber, die Datei gemeinsam zu nutzen, kann aber nicht viel schief gehen.
    Auf meinen Clients landet das EPG in der RAM-Disk. Dann muss ich nicht warten bis das NFS soweit ist, wenn der Server per WoL geweckt wird. Hab damit auch keinen Ärger mit Berechtigungen auf dem Familien-Laptop und auf dem Spielsystem wird das NFS nur bei Bedarf gestartet. Sicher lässt sich das alles auch irgendwie anders lösen, mit epgsync geht's aber bequemer.

  • [Announce] remotetimers / remoteosd / svdrposd / epgsync/ svdrpservice Version 1.0.0

    Hallo zusammen,


    unter http://vdr.schmirler.de liegen die 1.0.0 Versionen der folgenden Client-Server-Plugins bereit:

    • remotetimers (Timer auf Server anlegen oder verschieben, Multi-User Timer- und Aufnahmen-Menü, erweitertes Aufnahmen-Menü mit serverseitigem Schneiden, Umbenennen, Verschieben, ...)
    • remoteosd (Zugriff auf OSD des Servers)
    • svdrposd (muss auf Server installiert werden, damit remoteosd das Menü auslesen kann)
    • epgsync (EPG des Servers importieren)
    • svdrpservice (wird von den obigen Plugins benötigt, um sich mit dem Server zu verbinden)


    Alle Plugins enthalten keine großartigen Neuerungen. Sie wurden im großen und ganzen lediglich für den aktuellen VDR angepasst (API-Änderungen, neue Makefiles). Ferner wurde die Kompatibilität zu VDR vor 1.7.36 entfernt. Mehr Details in den HISTORY-Dateien auf meiner Webseite.


    Frohes Streamen,
    Frank

  • [STREAMDEV] - Streaming von Aufnahmen via HTTP-Menü funktioniert nicht

    Hm - kannst Du die Änderungen in der menuHTTP.c schrittweise wieder rückgängig machen, bis Du wieder beim Original bist?


    * esyslog-Zeile raus
    * geschweifte Klammern raus
    * (unsigned long) casts raus


    Der entscheidende Schritt müsste eigentlich der letzte sein. Vielleicht ist am Montag beim manuellen Patchen etwas schief gegangen.


    Über das mit den Endungen bin ich gestern auch gestolpert. Schau ich mir bei Gelegenheit an. Danke!

  • [STREAMDEV] - Streaming von Aufnahmen via HTTP-Menü funktioniert nicht

    Steh da leider völlig auf dem Schlauch. Könntest Du den angehängten Patch anwenden (auf die original menuHTTP.c ohne die (unsigned long) casts), dann einmal die Aufnahmeliste abrufen und einmal eine Wiedergabe mit der manuell ermittelten inode-Nummer aus dem stat-Befehl starten? Wie unterscheiden sich die Meldungen zur gewählten Aufnahme im Log? Die eine Meldung beginnt mit "XX Linklist stat", die andere mit "XX SearchRec stat".