vdr-pluign-mcli, vdr-addon-mcli-tool nur für 1.7.20?

  • Hallo liebe Gemeinde,
    mein endgültiges Ziel ist meinen Server auf Ubuntu / yavdr 0.4 umzustellen.
    Da meine Holde aber auf keinen Fall ihre Soaps verpassen darf, muss erstmal die Bastelkiste für Trockenübungen herhalten.


    Hab auf die Möhre also Lucid 32bit (server) draufgeschmissen, und folgende Paketquellen aufgenommen:


    deb http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu lucid main
    deb-src http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu lucid main


    Das Installieren des VDR´s war dementsprechend kein Prob.


    Nur die beiden Pakete: vdr-pluign-mcli, vdr-addon-mcli-tool machen Probleme.


    Die Pakete erwarten vdr 1.7.20 in den Paketquellen vorhandene Version des VDR´s ist allerdings 1.7.22.


    Daraus erwachsen nu ein paar Fragen:


    1.) Mache ich hier einen Fehler?


    2.) Wenn !1 dann: Wurden die Pakete schlicht weg vergessen oder gibt es einen Grund das sie nur für 1.7.20 vorhanden sind.


    3.) Ist dieses Problem bei anderen Ubuntuversionen bzw. bei anderen Architekturen auch zu erwarten?


    4.) Da eigentlich dvbloop + mcli und nicht das vdr-mcli-plugin betreiben möchte brauche
    ich afaik die beiden Pakete nur um das dvbloop Kernelmodul zu regeln. (?) Könnte ich die installation nicht forcen, da
    dem Kenelmodul ja die VDR Version schnuppe sein sollte und ich den VDR Spezifischen Krempel, also das plugin, selber nicht
    nutze? Oder habe ich hier einfach was falsch verstanden?



    Dank & Gruß


    der Martin

    Kopfstation: 1 netceiver; 2x Dual-DVB-S2


    VDR-Server: Supermicro X7SPA-H-D525; 4GB RAM; 5x2TB (Raid5), @ squeeze + e-tobi


    Client1: Zotac Zbox nd22 @ openelec (xvdr)
    Client2: Zotac Zbox nd22 @ openelec (xvdr)
    Client3: n oller eeePC 900a @ openelec (xvdr)


    Bastelkiste: 0815 Shuttle P4 Barebone; 512mb; 120gb @ lucid

  • Sorry, aber das yaVDR-Forum ist nur für die Verwender der yaVDR-Distribution, nicht für die "nur" Paket-Benutzer.


    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

    Einmal editiert, zuletzt von gda ()

  • Nur die beiden Pakete: vdr-pluign-mcli, vdr-addon-mcli-tool machen Probleme.


    Ich beantworte die Frage trotzdem, weil diese recht einfach ist und bestimmt auch native yaVDR 0.3.2 User interessiert.


    Mit der Umstellung auf 1.7.22 habe ich nicht alle Pakete für Lucid LTS neu bauen lassen, um herauszufinden was wirklich bis 2013 gepflegt werden muss, da gehörten auch die Sachen für den Netceiver Betrieb dazu. Alle Plugins in den PPA Repositories müssen gegen den VDR darin gebaut sein, es gibt einige Plugins die das aus o.a. Gründen nicht sind. Die liegen noch im PPA, aber gebaut gegen eine alte VDR Version.


    Wenn ich weiß das jemand die Netceiver Sachen benötigt schaue ich, das sie reinkommen, aber in diesem speziellen Fall muß ich erstmal sehen, ob das alles noch passt, gibt es was neueres etc. Wird ein paar Tage dauern, bis dahin kannst Du die Plugin einfach selbst lokal bauen.


    Regards
    fnu

    HowTo: APT pinning

  • Danke für die Antwort. Das bestätigt meine Vermutung.


    Dann ist wohl bauen angesagt :)


    Gruß
    der Martin

    Kopfstation: 1 netceiver; 2x Dual-DVB-S2


    VDR-Server: Supermicro X7SPA-H-D525; 4GB RAM; 5x2TB (Raid5), @ squeeze + e-tobi


    Client1: Zotac Zbox nd22 @ openelec (xvdr)
    Client2: Zotac Zbox nd22 @ openelec (xvdr)
    Client3: n oller eeePC 900a @ openelec (xvdr)


    Bastelkiste: 0815 Shuttle P4 Barebone; 512mb; 120gb @ lucid

  • Dann ist wohl bauen angesagt :)


    Aber nur das Plugin, das Addon sollte IMHO laufen ...

    HowTo: APT pinning

  • Habe heute nichtsahnend ein dist-upgrade gemacht - ups Bild schwarz. Eine kurze Suche nach dem mcli-Plugin bestätigte den Verdacht - gibts nicht mehr.
    Wäre eine solche tiefgreifende Änderung (Features entfernen halte ich für eine solche) nicht eher im Rahmen von einem größeren Versionssprung sinnvoll?


    Grüße
    Holger


    PS: mcli-addon gibts auf den ersten Blick auch nicht mehr.

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    2 Mal editiert, zuletzt von hsteinhaus ()

  • Habe heute nichtsahnend ein dist-upgrade gemacht - ups Bild schwarz. Eine kurze Suche nach dem mcli-Plugin bestätigte den Verdacht - gibts nicht mehr. Wäre eine solche tiefgreifende Änderung (Features entfernen halte ich für eine solche) nicht eher im Rahmen von einem größeren Versionssprung sinnvoll?


    Das mcli-Plugin ist kein Feature von yaVDR.


    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

  • Und leider bauen die aktuellen bits nicht unter Lucid, wie auch unter Precise ...


    Regards
    fnu


    PS.: Hab die älteren Bits ins PPA geschossen ...

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Der anliegende Mini-Patch macht das Plugin bei mir wieder kompilierbar und lauffähig. Wenn ich die Release Notes vom vdr 1.7.26 korrekt verstehe, sollte dieser Fix auch inhaltlich in Ordnung sein. Allerdings habe ich kein CAM im Rechner, sodass jemand mit PayTV den Patch mal gegentesten müsste.


    Grüße,
    Holger

  • Wenn ich die Release Notes vom vdr 1.7.26 korrekt verstehe,


    In "stable-vdr" findest Du in Kürze das Plugin und die AddOns. Wenn Du es für 1.7.26 (testing-vdr) benötigst müsstest Du es erstmal für Dich lokal bauen.


    Regards
    fnu

    HowTo: APT pinning

  • Ich schätze mal der Patch ist falsch rum.


    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

  • Habe gestern Abend mal wieder einen Blick auf die Sache geworfen und dabei folgende Erkenntnisse gewonnen:
    - die gesamte MLD-Kanalbelegungunslogik sieht recht verbuggt aus, es gibt zig Registrierungen und Deregistrierungen für jede PID pro Sekunde (der alte VDR macht das aber auch schon so, ist also nicht das Problem)
    - Reel hat eine aktuellere Version des mcli-Plugins im testing-Repo (einige Bugfixes klingen sinnvoll, Problem ist aber nicht gelöst)
    - Reel arbeitet in testing mit 1.7.21, wird also erst beim nächsten Update des VDRs selbst darüber stolpern ;)
    - ab VDR 1.7.22 tunt der Netceiver um ein paar MHz daneben, das führt dann folgerichtig zum NO LOCK (je nach Modulation kann es auch zufällig einen Lock geben)
    - ein 1.7.21 kann einen verhungerten 1.7.27 auf dem gleichen Kanal wiederbeleben, indem er diesen "richtig" tuned


    korrektes Tuning von 3sat HD (1.7.21)

    Code
    UUID <fe80::208:54ff:fe52:d7f1>:
          slot 1.0, type DVB-S2, used:  12
          LOCK   , frequency 11347000kHz (1597.0MHz), position <19.2E>
          strength ffff, snr 789c, ber 0002, unc 0000
          NIMCurrent 108
          RotorStatus 0, RotorDiff 0.0


    fehlgeschlagenes Tuning von 3sat HD (1.7.27)

    Code
    UUID <fe80::208:54ff:fe52:d7f1>:
          slot 2.1, type DVB-S2, used:   7
          NO LOCK, frequency 11347000kHz (1598.3MHz), position <19.2E>
          strength ffff, snr 0000, ber 0000, unc 0000
          NIMCurrent 96
          RotorStatus 0, RotorDiff 0.0


    Leider bin ich noch nicht besonders fit im DVB-API, werde mir die Sache in den nächsten Tagen aber mal vornehmen. Insbesondere ist mir noch nicht ganz klar, wie sich die MHz der ZF ( in Klammern) aus den kHz der Transponderfrequenz errechnet und warum gleicher Input zu offensichtlich unterschiedlichem Output führt. Bin für jegliche Tipps dankbar.


    Grüße
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    4 Mal editiert, zuletzt von hsteinhaus ()

  • Ich bin mir da nicht ganz sicher, ob dieser Versatz hier wirklich die Ursache für das Problem ist. Was, wenn der übliche Workflow ist, dass der Netceiver bei Erhalt des "Lock-Befehls" selber noch auf maximale Feldstärke nachtunt?


    An der Stelle, an der die Probleme angefangen haben, ist im VDR die Unterstützung für SCR/LNB-Share reingekommen. Meine Vermutung ist, dass hier "irgendwas" das Device-Handling so verändert hat, dass das mcli-Plugin nun massive Probleme hat. Was mich nur in dem Zusammenhang gewundert hat: Bei Streamdev, was ja mit seinem Client-Plugin etwas ähnliches tut, hat es hier wohl keinerlei Probleme gegeben...


    Fakt ist, dass das Problem nur bei einigen (wohl vorzugsweise HD-) Sendern auftritt. Was steht denn bei dir für 3sat HD in der channels.conf?


    Letztlich wird man wohl nicht drumrumkommen, dass jemand mal den kompletten Ablauf von Umschalten bis "Sender läuft" oder eben "Sender läuft nicht" mitloggt.


    Ich könnte mir als Testaufbau hier vorstellen, das mcli-Plugin mit etlichen printfs zu spicken. Dann zweimal VDR (1.7.21 und 1.7.22) die jeweils eine Channels.conf mit nur einem Sender (einem, der nicht getunt wird) ausgestattet werden. Jeweils EPG-Scan und Channelsuche verbieten und mcli so konfigurieren, dass der VDR nur einen einzigen Tuner zu sehen bekommt. Die Ausgabe von dem ganzen dann mal vergleichen. Vielleicht fällt der Groschen dann... Irgendwo muss der VDR doch an entscheidender Stelle plötzlich irgendwie anders reagieren...


    Ich würde bewusst die zwei VDR-Versionen vergleichen, bei denen das Problem erstmals aufgetreten ist, um möglichst wenig Unterschiede zu haben.


    Grund, warum ich das bisher noch nicht gemacht habe: a) Habe selber keinen Netceiver. Betrifft den VDR eines Kumpels, der gute 30km von mir entfernt wohnt und b) habe ich selber nichtmal HD. Weder im VDR noch im TV. VDR für so einen Test ausleihen fällt flach, da das Ding im Einsatz ist. Halt leider mit grottig alter Software, weil kein Update möglich...


    Rein von der Theorie her sollte es aber möglich sein, das Problem "in der Community" zu lösen, da der entscheidende Teil ja (lobenswerterweise) Open Source ist.


    Mangels Alternative zum Netceiver wird es wohl im Worst-Case irgendwann darauf hinaus laufen, dass ich bei meinem Kumpel einen Rechner abstelle und mir darauf via SSH einen Remote-Zugriff einrichte...

  • Ich bin mir da nicht ganz sicher, ob dieser Versatz hier wirklich die Ursache für das Problem ist. Was, wenn der übliche Workflow ist, dass der Netceiver bei Erhalt des "Lock-Befehls" selber noch auf maximale Feldstärke nachtunt?


    Davon gehe ich aus. Je nachdem, ob das klappt, gibt es einen Lock oder nicht (zu weit weg?).


    Meine Idee wäre, erst mal ein paar MLD-Pakete des 1.7.21 mit Wireshark zu capturen und einfach ein Replay zu machen. Damit müsste der Netceiver wieder tunen und der hängende 1.7.22 sollte plötzlich ein Bild bringen. Schließlich würde ich die von 1,7.22 und 1.7.21 generierten MLD-Pakete vergleichen und rückwärts nach der Ursache der Differenzen fahnden. Der Aufwand wäre gering und man sucht nicht völlig blind durch zig Changes (es sind eine Menge, wie der Diff zeigt).


    Zitat


    Grund, warum ich das bisher noch nicht gemacht habe: a) Habe selber keinen Netceiver. Betrifft den VDR eines Kumpels, der gute 30km von mir entfernt wohnt und b) habe ich selber nichtmal HD. Weder im VDR noch im TV. VDR für so einen Test ausleihen fällt flach, da das Ding im Einsatz ist. Halt leider mit grottig alter Software, weil kein Update möglich...


    Rein von der Theorie her sollte es aber möglich sein, das Problem "in der Community" zu lösen, da der entscheidende Teil ja (lobenswerterweise) Open Source ist.


    Mangels Alternative zum Netceiver wird es wohl im Worst-Case irgendwann darauf hinaus laufen, dass ich bei meinem Kumpel einen Rechner abstelle und mir darauf via SSH einen Remote-Zugriff einrichte...


    Das können wir eventuell einfacher angehen. Ich habe zwei Netceiver und werde heute abend durch Umsortieren der Emfpangskarten einen mal vorübergehend aus dem "Produktivbetrieb" nehmen. KVM-Virtualisierer ist ebenfalls vorhanden. Ich werde heute abend mal zwei minimale Konfigurationen in je einer VM aufsetzen (1.7.21 und 1.7.22), Remotezugriff darauf könnte ich mir ohne weiteres vorstellen.


    So langsam nervt das mcli-Problem und gehört gelöst ;)


    Grüße
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]


  • Davon gehe ich aus. Je nachdem, ob das klappt, gibt es einen Lock oder nicht (zu weit weg?).


    Wenn dem so ist, dann wäre die Ursache möglicherweise noch einfacher zu finden als ich befürchtet hätte, denn der Wert, der da zum Netceiver gesendet wird, muss ja von irgendwoher kommen. Und den Weg dieses Werts innerhalb vom VDR dann zurückzuverfolgen sollte kein Hexenwerk sein.


    Ich kenne die DVB-Hintergründe aber nicht so gut, dass ich hier genaue Aussagen machen kann. Was bedeutet denn "LOCK"? Ist das ein Feedback vom Tuner zum VDR oder doch eher ein Befehl vom VDR zum Tuner?


    Zitat


    Das können wir eventuell einfacher angehen. Ich habe zwei Netceiver und werde heute abend durch Umsortieren der Emfpangskarten einen mal vorübergehend aus dem "Produktivbetrieb" nehmen. KVM-Virtualisierer ist ebenfalls vorhanden. Ich werde heute abend mal zwei minimale Konfigurationen in je einer VM aufsetzen (1.7.21 und 1.7.22), Remotezugriff darauf könnte ich mir ohne weiteres vorstellen.


    Da sprechen wir uns ggf. nochmal vie PN ab. Ich kann aber nicht versprechen, dass ich mich kurzfristig darum kümmern werde. Bevor du dir den Aufwand mit dem Aufsetzen machst, mache erstmal deine Tests.


    Zitat


    So langsam nervt das mcli-Problem und gehört gelöst ;)


    Mich nerven eher die regelmäßigen Rückfragen von meinem Bekannten. Noch ist er vom VDR an sich überzeugt und wollte eigentlich noch mehr VDR-System aufstellen und an den Netceiver hängen. Er hat seinen Netceiver bis auf Anschlag mit Dual-DVB-S2-Tunern aufgerüstet. Dementsprechend ist auch das Argernis über die Probleme groß. Anschaffen einer anderen Lösung wäre ja auch nicht gerade billig. Und den Netceiver wird er auch nicht mehr ohne großen Verlust verkaufen können.

  • Zitat


    Ich kenne die DVB-Hintergründe aber nicht so gut, dass ich hier genaue Aussagen machen kann. Was bedeutet denn "LOCK"? Ist das ein Feedback vom Tuner zum VDR oder doch eher ein Befehl vom VDR zum Tuner?


    Das ist ein Statusflag des Tuners, zeigt meines Wissens, dass das Tunen geklappt hat (siehe netcvdig.c:346)


    Zitat


    Mich nerven eher die regelmäßigen Rückfragen von meinem Bekannten. Noch ist er vom VDR an sich überzeugt und wollte eigentlich noch mehr VDR-System aufstellen und an den Netceiver hängen. Er hat seinen Netceiver bis auf Anschlag mit Dual-DVB-S2-Tunern aufgerüstet. Dementsprechend ist auch das Argernis über die Probleme groß. Anschaffen einer anderen Lösung wäre ja auch nicht gerade billig. Und den Netceiver wird er auch nicht mehr ohne großen Verlust verkaufen können.


    Hier siehts so ähnlich aus - 4 doppelte DVB-S2-Karten in zwei Netceivern. Prinzipell lief alles gut mit yavdr 0.4 - bis zum Tag X, an dem yavdr 0.4 quasi im vollen Galopp auf den 1.7.22 gewechselt ist...
    Nach einem Salto Rückwärts zum Backup ist das jetzt der neue Status quo, jegliche apt-gets sind nun verboten. Das ist aber wirklich keine tragfähige Dauerlösung, zumal neue/defekte Systeme auf dem Stand nicht ohne weiteres aufsetzbar sind.


    Anschaffen einer anderen Lösung: gibts sowas? Habe noch nichts annähernd vergleichbares gesehen. Die USB-Stick-/Dockstar-Lösung kanns jedenfalls m.E. nicht sein, wenn ein stabiler (!!!) Dauerbetrieb mit mehreren Haushalten das Ziel ist...


    Grüße
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • bis zum Tag X, an dem yavdr 0.4 quasi im vollen Galopp auf den 1.7.22 gewechselt ist...


    Ja, aber die Zeit bleibt nicht stehen und die Welt dreht sich nicht nur um die Netceiver Nutzer. Wir können nicht für ein paar wenige einen ur-alten Stand einfrieren ... ?


    Ich kann nicht sagen ob Netceiver überhaupt zum avisierten Zielpublikum gehörten, aber solange es tat war es ja gut. Aber das das Zeug ab VDR >= 1.7.21 nicht mehr nutzbar ist, ist nicht unser Fehler oder unsere Verantwortung. Wie auch etliche Plugins rausgeflogen sind, weil sich keiner um die Pflege kümmert, schade ...


    Wir sind inzwischen nach ca. 6 monatiger Test-Zeit auf VDR 1.7.27 "galoppiert", das abschließende Announcement steht noch aus, wir arbeiten noch den Repositories.


    Wenn uns jemand ein Patch für den Stand bringt, damit die Netceiver wieder nutzbar werden, können wir den einbauen und zum Test zur Verfügung stellen und zwar sowohl für 0.3, 0.4 und 0.5-beta das ebenfalls VDR 1.7.27 enthält.


    Regards
    fnu

    HowTo: APT pinning

Jetzt mitmachen!

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