Beiträge von hannemann

  • Neues Projekt Audioplayer auf Raspberry - Welche Client Software einsetzen?

    Ein zweiter Musik Server ist sicherlich ein wenig über...
    Allerdings ist der LMS gleichzeitig auch ein UPNP Server und könnte deine Clients weiter mit Musik versorgen... Theoretisch ;)
    Zumindest klappt das mit der BubbleUPNP App auf Android.


    Ich habe schon diverse Posts gesehen, die squeezelite mit einem Display verheiratet haben, probiert habe ich es bisher aber nicht. Ich habe allerdings gerade gesehen, das Squeezelite Lirc Unterstützt.


    Hier mal ein paar Links:


    http://www.mysqueezebox.com/download
    https://github.com/ralph-irving/squeezelite
    https://www.youtube.com/watch?v=ew23-aYNbD0

  • Neues Projekt Audioplayer auf Raspberry - Welche Client Software einsetzen?

    Ich finde den Logitech Media Server und squeezelite als Client ziemlich gut. Der kann auch synchron an mehrere Clients senden und es gibt eine Vielzahl an Plugins sowie Apps (z.B. Orangesqueeze) zu Fernsteuerung.


    Ich würde mir unbedingt einen Hifiberry DAC zulegen falls der Ton nicht über HDMI abgegriffen werden soll. Wenn die Lautsprecher nicht so doll sind kann man den Ton auch mit alsaequal noch vorsichtig pimpen.

  • epgsearch für vdr 2.3.x

    Obelix drückt Nägel mit dem Finger in die Wand. Ich muss nen Hammer benutzen. ;)


    Letztendlich hab ich Restfulapi auch so debugged aber eine IDE ist doch bequemer. Breakpoints wären super.


    Nachdem ich in Eclipse für Epgsearch eingestellt habe, das *.c C++ Files sind sieht es schon besser aus. Jetzt findet er ein paar Includes nicht <vector> und <string> z.B. Mal sehen wie ich das gefixed kriege.

  • epgsearch für vdr 2.3.x

    Ist doch schon mal viel Wert. Respekt :tup


    Ich werds ASAP testen.


    Hast du eine Idee, warum mir Eclipse CDT bei dem Plugin jede Zeile als falsch markiert? Bei Restfulapi habe ich das Problem nicht, wohl aber bei fast allen anderen Plugins und auch vdr selbst.

  • [ANNOUNCE] VDR developer version 2.3.1

    Zitat von mini73

    Es wäre klasse, wenn die Plugins auch weiterhin mit vdr 2.2.0 bauen

    Ich bin ja nu noch ein Frischling was das angeht, daher die Frage:


    Um diverse ifdefs zu sparen würde ich gern Beispielsweise sowas machen:

    Code
    #if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannels& channels = *Channels;
#else
    cChannels& channels = Channels;
#endif
    const cChannel* = channels.GetByChannelID(m_channel);


    Anstatt:

    Code
    #if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannel* = Channels->GetByChannelID(m_channel);
#else
    const cChannel* = Channels.GetByChannelID(m_channel);
#endif


    Ich kann dann mit einer Referenz weiterarbeiten statt an jeder Stelle in meinem Block an denen ich etwas von den Channels will ein ifdef einzubauen nur um den Punkt gegen den Pfeil auszutauschen.
    Müffelt das für euch irgendwie komisch? Zumindest funktioniert der obere Code mit vdr-2.2.0.

  • [Announce] RESTFulApi 0.2.5.0

    Hallo,


    bevor angefangen werden kann, RESTFulApi zu vdr-2.3.1 kompatibel zu machen, musste ich noch zwei neue Services zu Ende bauen, die gerade released wurden.


    /recordings/updates und recordings/sync


    Man kann nun eine Clientseitige Datenbank aufbauen und mit diesen beiden Services aktuell halten bzw. synchronisieren ohne jedes mal die komplette Liste herunterladen zu müssen (bei mir sind das bei 1950 Aufnahmen mit Scraper Daten schlappe 7.7 MB).
    Ein Anwendungsbeispiel wäre die HTML5 IndexedDB.


    Beim Initialen Laden der gesamten Aufnahme Liste übergibt man den neuen Parameter syncId, der einen beliebigen String übermittelt. Im Cache Verzeichnis wird eine Datei mit dieser ID als Name angelegt, die die Dateinamen der Aufnahmen und jeweils einen dazu passenden Hash enthält.
    Fordert der Client nun Updates mit der selben syncId an, so wird diese Datei mit den aktuellen Aufnehmen des VDR abgeglichen und nur eine Liste der neu hinzugekommenen, gelöschten oder modifizierten Aufnahmen versendet. Das spart eine Menge Bandbreite.


    Lösche ich eine Aufnahme, so kann ich die syncId ebenfalls übergeben, so das diese Aufnahme auch aus der Datei entfernt werden kann.


    Bin ich der Meinung, das meine Clientseitige DB nicht mehr synchron ist, kann ich den recordings/sync Service nutzen. Dazu übermittele ich per Post ein Form Data Array mit allen Aufnahmen. Die Einträge des Arrays müssen Komma separiert den gesamten Dateinamen und den Hash der Aufnahme enthalten, den RESTFulApi jetzt mit der gesamten Aufnahme Liste bzw. den Updates liefert.


    So muss das aussehen:

    Code
    POST http://ip:port/recordings/sync.json?syncId=meineclientid


recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789&recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789&recordings[]=/srv/video.00/path/to/rec/timestamp.rec,abcdef0123456789

    In diesem Fall wird die übermittelte Liste mit den aktuelle Aufnahmen abgeglichen und widerum nur die Änderungen zurück übertragen.
    In beiden Fällen wird die Sync Datei aktualisiert.


    Da die Aufnahme Nummer sich jederzeit ändern kann wurde desweiteren implementiert, das alle Recording Services nicht mehr nur über die Nummer der Aufnahme sondern auch über den Dateinahmen angetriggert werden können.
    Ich Empfehle, alle Apps die folgende Services nutzen zu aktualisieren.

    Code
    GET /recordings/play
POST /recordings/play
GET /recordings/editedfile
GET /recordings
DELETE /recordings
POST /recordings/marks
DELETE /recordings/marks
GET /recordings/cut
POST /recordings/cut


    In Zukunft sollten die Anfragen den kompletten Dateinamen enthalten, damit sichergestellt ist, das man auch die richtige Aufnahme löscht, statt eines heißgeliebten Highlights der TV-Geschichte :)
    Hier ein Beispiel um eine einzelne Aufnahme zu holen bzw. zu löschen:

    Code
    GET http://<ip>:<port>/recordings/path/to/videodir/my_recording/YYYY-MM-DD.hh.mm.ss-0.rec.<format>
DELETE http://<ip>:<port>/recordings/path/to/videodir/my_recording/YYYY-MM-DD.hh.mm.ss-0.rec.<format>


    Die EPG Suche kann nun den neuen Parameter date_limit verarbeiten. Es wird ein UNIX-Timestamp erwartet bis zu dem Suchergebnisse ausgespielt werden sollen.


    Viel Spaß beim syncen

  • Restfulapi-Plugin

    Der Buildfehler hat IMO mit dem Makefile nichts zu tun.
    Da Launchpad die Pakete ohne murren baut, würde ich an deiner Stelle auf den dpkg Buildprozess verzichten, einfach die Sourcen clonen und mit sudo make-install installieren.


    Mein Github verwende ich nur für Testzwecke. Benutze bitte das Github von yavdr. Da liegt die "offizielle" Version. https://github.com/yavdr/vdr-plugin-restfulapi


    Zu der Fehlerbeschreibung:
    Ich kan so ein Fehlverhalten bei mir nicht reproduzieren.
    Möglicherweise funkt da ein anderes Plugin zwischen. Kannst du mal tvscraper deaktivieren? Da ich das schon länger gegen scraper2vdr getauscht habe, die Daten aber von restfulapi in die Events gesteckt werden könnte da ein Fehler drinstecken.
    Und bitte mal nach und nach alle Plugins deaktivieren und testen.


    Gibt es irgendwas aufälliges im Syslog?

  • [Announce] vdr-plugin-restfulapi 0.2.4.1

    Hallo,


    Restfulapi kann jetzt auch die Suchtimer Logik bei der EPG-Suche verwenden. Somit ist es jetzt möglich, eine Suche zu bauen die genauso funktioniert wie im Live Plugin. Zusätzlich wurde noch ein date_limit parameter hinzugefügt, der das Suchergebniss anhand der Startzeit des Events limitiert. Als Wert muss ein UNIX Timestamp übergeben werden.


    Die bisherige Suche kann weiterhin verwendet werden. Unterschieden wird hier anhand des Namens des Suchparameters:


    search = Suchtimer Logik
    query = Alte Logik


    Steht aber auch alles in der Doku (http://<ip-des-vdr>:<port>/info.html)


    Weiterhin viel Spaß beim Apps basteln