Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

  • Ja klar, alles was Such-/Autotimer bezogen ist geht natürlich nicht in VDR Core.
    <snip>
    Ist ein wenig wie der Spatz in der Hand oder die Taube auf dem Dach ... für die EPG Übersicht hätte man ja Wahlmöglichkeiten, Core, epgsearch, tvguide(ng) evtl. yaepghd noch ...


    Ich benutze yavdr und habe nicht den genauen Durchblick über welche Funktionalitäten vom VDR Core oder von Plugins stammen.


    Ich sitze vielleicht auf dem Schlauch, aber für mich ist es nicht so klar, warum die Such- und Autotimer Funktionalität nicht in den VDR Core gehören sollten. Für mich ist es nämlich eine der Hauptfunktionen, die den VDR kennzeichnen; auch wenn es zur Zeit vom epgsearch Plugin stammt. Gibt es vielleicht eine VDR Distribution, die das epgsearch Plugin nicht per Default benutzt?


    Wäre die Such- und Autotimer Funktion im VDR Core, hätten die Skindesigner eine feste stets gepflegte Such- und Autotimer Basis, auf die sie setzen könnten, was in langer Sicht, wahrscheinlich Resourcen sparen könnten. Aber ich habe mir jetzt den VDR git angesehen und bin überrascht, den VDR 2.3.2 nicht dort vorzufinden.
    https://projects.vdr-developer.org/git/vdr.git/


    Es sieht so aus, als würden die Commits nicht fortlaufend zum Repo gepushed (in der Annahme, dass der obige Link auch der richtige Upstream VDR Repo ist), sondern nur einige Zeit nach fertigstellung größerer Arbeiten am VDR Core. In diesem Sinne könnte es Sinn machen, den VDR Core so klein wie möglich zu halten, denn auch Klaus, dem ich sehr dankbar für das VDR Projekt bin, hat nur eine begrenzte Zeit für den VDR Projekt zur Verfügung.


    Folglich gehe ich jetzt davon aus, dass neben Argumenten der Stabilität des VDR Cores auch die Arbeitsteilung eines der Argumente ist, den Such- und Autotimer nicht in den VDR Core zu integrieren!?


    MfG


    Ludi


    PS: Ich habe dies geschrieben, da es vielleicht auch Sinn macht, darüber nachzudenken, ob es vielleicht besser wäre die Funktionalität eines ungepflegten, jedoch sehr benutzen Plugins wie epgsearch direkt ins VDR Core zu übernehmen.

  • Ich sitze vielleicht auf dem Schlauch, aber für mich ist es nicht so klar, warum die Such- und Autotimer Funktionalität nicht in den VDR Core gehören sollten.

    Weil so ein Funktionalität recht viel Aufwand zu programmieren und dann auch zu warten ist, das ist nicht "einfach mal nur undelete" im Core mit angeboten. Es spricht gar nichts dagegen dass das ein Plugin bleibt, dazu gibt es die Plugin Schnittstelle seit 15 Jahren (?), auch wenn jede Distro das immer im Portfolio hat.


    Wenn man nämlich weiter disktutiert, käme gleich die Frage auf, warum kann VDR Core nicht mit den externen EPG Anbietern umgehen, selbsttätig Werbung erkennen etc. Es gibt Aufgaben die sind in Core sinnvoller, bei anderen ist es eben so sinnvoll Grenzen zu ziehen.


    Die aktuellen Issues mit epgsearch & VDR 2.3.x kommen ja nicht daher das das ein oder andere instabil ist, es gab schlicht ein Änderung in der API, auf diese muss bei fast allen Plugin reagiert werden. Und das ist bei epgsearch durch seinen Funktionsumfang eben aufwändig ...


    Regards
    fnu


    PS.: Natürlich ist es nicht simpel undelete in VDR Core zu implemementieren, aber eben einfacher als epgsearch, markad oder was sonst fast jeder noch so als STD am laufen hat ...

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Weil so ein Funktionalität recht viel Aufwand zu programmieren und dann auch zu warten ist, das ist nicht "einfach mal nur undelete" im Core mit angeboten.


    Also unter anderem Arbeitsaufteilung.


    Wenn ich jetzt bedenke, dass in der Zwischenzeit ein mit VDR 2.3.x kompatibles epg2timer Plugin aufgetaucht ist, um die Funktionalität von epgsearch wenigstens teilweise zu reproduzieren, sehe ich ein warum die Aufteilung in Core und Plugins sinnvoll ist: Neuerungen können im Core erscheinen und die Plugins können sich nach und nach anpassen oder ersetzt werden. Die Neuerungen stehen so schon Benutzern zur Verfügung, wenn sie auf die Funktionalitäten der nicht angepassten Plugins verzichten können und müssen nicht noch warten, dass diese angepasst sind. Wären diese Funktionalitäten im Core, müssten wahrscheinlich auch diese angepasst sein bevor der Core wieder laufen könnte.

  • Echt klasse, dass ihr euch hier gerade so zusammen rauft.


    Auch wenn ich VDR "nur" noch im Backend nutze, meine Frontends laufen alle mit Kodi, benötige ich natürlich auch noch ein paar Plugins: vnsi, live und epgsearch.


    vnsi wird von fernetmenta hervorragend weiterentwickelt. Das ist wohl auch schon mit vdr2.3.2 kompatibel.


    Neuerdings kommt auch noch robotv dazu. Das wird von pipelka gepflegt.


    Was live und epgsearch betrifft muss ich mir bei Gelegenheit wohl nochmal vdradmin-am ansehen.


    Wie dem auch sei. Vielen Dank für alles, was den VDR betrifft!


    Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Ich habe im Wesentlichen das gleiche Setup. RoboTV kannte ich aber noch nicht. Kann man damit auch auf's Handy streamen?


    Solange keine Alternative zu epgsearch und live da ist bleibe ich (und das von uns gepflegt VDR4Arch Repository) auf jeden Fall noch bei 2.2.0. Danach wäre aber angebracht mal grob durchzufegen und alles rauszuhauen was ungepflegt ist. Das schließt Patches meiner Ansicht nach mit ein. Wenn schon dann zu Github oder meinetwegen projects.vdr-developer rüber und sauber weiterführen.

  • M-Reimer


    Was ist das für eine seltsame Sicht auf die Welt? Was ist an einem Patch schlecht? Nur weil es Dir nicht in den Kram passt? IMHO ist da gar nichts schlecht dran, wenn dieser an definierter Stelle zuverlässig zur Verfügung steht ...


    Kehr ruhig Euer Repo aus, dann fehlt epgsearch eben, dafür muss sich nämlich jemanden finden der es in einem GIT weiterführt. Da Du das so nachdrücklich einforderst, möchtest Du das gerne übernehmen?


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • fnu Immer schön locker bleiben. Ich lese nicht, dass irgendwas "nachdrücklich eingefordert" wird. ;)


    M-Reimer Ich nutze RoboTV bisher lediglich auf meiner Shield. Keine Ahnung, ob das auch auf einem Android Smartphone oder Tablet läuft. Kannst es ja mal ausprobieren. Ich habe neben der Shield nur Debian, Windows, Libreelec und Apple Geräte im Haus.


    Viele Grüße Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • @Hoppel


    Mach Dich selbst locker, sowas geht mir bei den gelegentlichen Auswüchsen Reimer'scher Weltanschauung locker von den Fingern ... :ausheck


    Seine Erwartungshaltung steht da ziemlich deutlich geschrieben, schön wenn man diese selbst nicht erfüllen muss ... :rolleyes:


    Regards
    fnu

    HowTo: APT pinning

  • fnu Immer schön locker bleiben. Ich lese nicht, dass irgendwas "nachdrücklich eingefordert" wird.


    Wie du das auch immer formulieren willst. Was er da schreibt mag in einem kommerziellen Projekt durchaus in Ordnung sein, aber als OpenSource-Programmierer würde ich da sofort auf Stur schalten. Da gilt für mich "friss oder stirb".
    Und ich will nicht locker sein.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Die von Petri Hintukainen http://phivdr.dyndns.org/vdr


    Von Petri Hintukainen gibt es hier eine neue lauffähige Version.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github


  • Mach Dich selbst locker, sowas geht mir bei den gelegentlichen Auswüchsen Reimer'scher Weltanschauung locker von den Fingern ... :ausheck


    Und das von dem Mod der in anderen Situationen gerne mal mit dem Besen durchfegt. Eigentlich wollte ich das ja garnicht mehr kommentieren, aber so lasse ich das nicht stehen.


    Erstmal ist vdr4arch ein Github-Projekt bei dem jeder mitwirken kann, Pull-Requests wurden in der Vergangenheit auch immer zeitnah und wohlwollend bearbeitet!


    In meinem Post steht "meiner Ansicht nach" und seine Meinung darf man immer noch frei äußern!


    Fakt ist, dass das Projekt aktuell hauptsächlich von Copperhead und meiner Wenigkeit gepflegt wird. Dazu kommen natürlich noch zahlreiche Beiträge in Form von Pull-Requests.


    Ich habe in nächster Zeit ohnehin kaum noch Zeit für meine Projekte und ich möchte mich zudem verstärkt mit der Entwicklung von Kodi-Addons befassen.


    Somit sehe ich zumindest für den Fall, dass es nicht als Pull-Request kommt, nur zwei Optionen für einen VDR größer 2.3.2 in vdr4arch:


    a) epgsearch und live werden noch angepasst. Ich werde die Zeit dafür nicht haben! In dem Fall *könnte* ich VDR auf eine Version nach 2.3.2 anheben. Alle Plugins die dann noch kompilieren können bleiben. Nein. Ich suche auch keine Patches irgendwo raus! Was nicht mehr geht fliegt erstmal raus. Wenn es noch jemand braucht soll er einen Pull-Request senden!


    b) VDR bleibt auf 2.2.0 stehen bis für den kompletten Upgrade ein Pull-Request kommt.


    Upgrade kommt allerdings überhaupt erst in Betracht wenn aus der "Developer-Version" eine neue "Stable" geworden ist. Eventuell ist die Liste der angepassten Plugins bis dahin schon deutlich länger.


  • Von Petri Hintukainen gibt es hier eine neue lauffähige Version.

    Er hat auch eine neue xineliboutput liegen.

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Er hat auch eine neue xineliboutput liegen


    Added support for HEVC


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich wünsche euch noch viel Spaß miteinander! ;)


    Mehr sage ich dazu nicht...


    Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

    2 Mal editiert, zuletzt von hoppel118 ()

  • M-Reimer


    Freie Meinungsäusserung gilt für alle, auch für mich :)


    Mich nervt das auch mit den Schnipseln, nach dem Motto ich hab hier am Polarkreis einen Patch dafür gefunden, einen anderen in Timbuktu Süd für was anderes. Aber Patches sind generell nichts Schlechtes, auch nicht für einen Distro Maintainer, ohne Patches gibt es keinen Fortschritt. Ein GIT commit ist nichts anderes als ein Patch. Deine Grundhaltung zur Pflege von VDR4arch in Ehren, aber die kannst Du nicht generell für OpenSource erwarten und vorraussetzen. Für Bezahlsoftware sicherlich, wie gda schon anmerkte. Ich möchte es im Gegenteil mal deutlicher formulieren, wir dürfen dankbar und können bei vielen Plugins und dem VDR froh sein, wenn sich überhaupt (noch) jemand in seiner Freizeit drum kümmert, egal in welcher Form, GIT (Schnippsel), Diff-Datei, Tarball ...


    Regards
    fnu

    HowTo: APT pinning

    4 Mal editiert, zuletzt von fnu ()

  • Freie Meinungsäusserung gilt für alle, auch für mich :)


    Volle Zustimmung. Und wenn ich nicht direkt und namentlich angegriffen worden wäre, hätte ich mich garnicht mehr zum Thema gemeldet.


    Um es nochmal in aller Kürze auszudrücken: Ich persönlich nutze VDR nurnoch als Backend für Kodi. Die Plugins, die ich und meine direkte Bekanntschaft benötigen, werden von mir weiterhin aktuell gehalten. Das schließt Aktualisierungen von anderen Plugins in Form von Pull-Requests natürlich nicht aus. Diese werden nach kurzem Review gerne übernommen.


    Ich erwarte von niemandem irgendwas. Im Gegenzug kann aktuell aber auch keiner von mir erwarten, dass ich mich mit Plugins befasse, die ich selber nicht benötige!


    Wenn der nächste stabile VDR auf Basis der aktuellen Codebasis kommt, werde ich, soweit es meine Zeit zulässt, natürlich versuchen ein Upgrade hinzubekommen. Allerdings gibt es im vdr4arch-Repository aktuell 85 Plugins! Ich werde definitiv nicht für alle diese Plugins nach Lösungen suchen um diese zum Laufen zu bringen! Wenn das compiliert, was ich und meine direkte Bekanntschaft benötigen, dann checke ich noch welche der anderen unverändert oder nach Update auf die neueste Version compilieren und der Rest fliegt erstmal raus! Ich sehe das auch als Chance um diese relativ große Liste mal auf das zu reduzieren, was tatsächlich genutzt wird!


    Für mich heißt es jetzt erstmal warten was in Richtung "Live" und "Epgsearch" passiert. "Live" ist übrigens bereits bei projects.vdr-developer.org. Wer hier also einen groben Überblick hat und bereits Patches geschrieben hat, könnte sich hier an die Admins wenden. Es sollte kein Problem sein hier Checkin-Rechte zu bekommen. Bei epgsearch muss sich erst noch zeigen ob man das mit dem neuen Plugin von mini73 noch braucht. Wobei dann natürlich Live angepasst werden müsste, um mit dem neuen Plugin klarzukommen.

  • Hi,

    Bei epgsearch muss sich erst noch zeigen ob man das mit dem neuen Plugin von mini73 noch braucht.


    Ich muß ja sagen, ich bin immer mehr ein PC-TV-Gucker. Vdradmin-am und Live haben den Vorteil, daß direkt aus dem Browser mit der Programmansicht am PC der VLC o.a. Programme gestartet werden können, die dann die URL für den Stream übergeben erhalten.
    Eine gleichartige Funktion ("Wünschdirwas") für epghttpd und ich könnte auch auf epgsearch+vdradmin-am verzichten.


    Meine herzlichsten Grüße an die wackeren Entwickler!

  • Hab's oben schonmal erwähnt, als funktionierende Alternative für "live" gibt es immer noch "vdradmin-am". Der hat auch noch ein paar Features die ich sehr schätze:

    • Man kann DVB EPG Einträge direkt bearbeiten, siehe Anhang.
    • Man kann Befehle aus der commands.conf aus dem WebIF direkt starten, ohne in die TV Simulation wechseln zu müssen.
    • Zeigt mir direkt in der Timer-Übersicht an das keine weiteren Transponder möglich ist, siehe Anhang.
    • Die Übersicht der Zeitleiste gefällt mir persönlich besser.
    • Läuft unabhängig vom VDR, beeinflußt diesen nicht.

    Ok, ja, es ist langsamer, vorallem auf etwas schwächeren Maschinchen, funktioniert aber jetzt und heute mit VDR 2.3.x ...


    Regards
    fnu

  • warum wird ./cache nicht einfach angelegt, statt drüber zu meckern


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Gibts nen Thrad speziell für vdradmin?


    habs mal auf die Schnelle auf meinem Testsystem installiert, das hat nur DVB-T. Der Aufruf von Channels dauert ne Weile, auf meinem System mit SAT möchte ich das nicht tun ... Sollte man das als Einstieg nicht begrenzen?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!