2-Sat-Positionen + Diseqc + Komische Limitationen meiner beiden DVB-S2-Geräte mit VDR 1.7.17/18

  • Hallo,


    ich möchte Euch mal ein Problem vorwerfen, bevor ich zuviel Zeit hineininvestiere. Vielleicht kennt ihr das. Ich habe zwei VDRs, auf beiden tritt es seit zwei bis drei Wochen auf, seit ich auf yaVDR-unstable-Pakete von 1.7.17/18 gegangen bin:


    Auf dem einen Rechner läuft yaVDR 0.3 mit 1.7.17 (Sachen aus unstable PPA, was sonst nicht viele nutzen) und auf dem anderen yaVDR 0.4-pre-alpha mit VDR 1.7.18 (Natty).


    Beide VDR-Cores sind mit diversen Patches gepatcht, unter denen sind relativ frisch dazugekommen: LNB-Sharing, Unicable, Livebuffer, PIN patch. Dann ist noch vdr-plugin-dynamite aktiv und eine recht aktuelle Version von s2-liplianin-dkms und vdr-plugin-eepg. (dynamite und eepg habe ich auch mal zum Testen deaktiviert, aber Fehlermöglichkeiten gibt es trotzdem genug)


    Ich hänge an die Rechner jeweils zwei DVB-S2-USB-Boxen TT 3600. Die Boxen hängen an einem Multiswitch mit 2-Sat-Positionen. (An dem Multiswitch hängt auch noch mein TV, der einen eingebauten DVB-S2-Receiver hat.)


    Auf beiden Rechnern habe ich nun folgende Probleme:


    Wenn DVB-Device A auf Diseqc-Position A einen Kanal Y von Transponder X empfängt, kann ich über DVB-Device B keinen Kanal mehr von Diseqc-Position A empfangen, außer die restlichen Kanäle auf Transponder X (wahrscheinlich geliefert von Device A). Ich kann jedoch mit DVB-Device B alle Kanäle auf Diseqc-Position B empfangen, während DVB-Device A noch auf dem Kanal Y ist. Dies fällt erst dann richtig krass auf, wenn man zwei zeitgleiche Aufnahmen auf verschiedenen Transpondern von Diseqc-Positiion A hat. eine davon fällt flach.


    Auch kann ich im femon-Menü nicht mehr mit den Pfeil-nach-links und Pfeil-nach-rechts-Tasten zwischen den DVB-Devices hin- und herspringen. Früher konnte ich damit erzwingen, dass ein Kanal Y, der von DVB-Device A geliefert wird, danach von DVB-Device B geliefert wird.


    Ansonsten kann ich mit meinen beiden DVB-S2-Boxen alle Kanäle auf beiden Diseqc-Positionen erreichen, solange ich keine Aufnahme laufen habe. Aber ich schätze, dass immer das DVB-Device gewechselt wird, wenn ich auf der gleichen Diseqc-Position zappe.


    Hat jemand so ein Problem schon gehabt? Ich habe es auch hier beschrieben: https://bugs.yavdr.com/issues/399


    Gruß
    hepi

  • Da fällt doch erstmal auf das sich LNB-Sharing und Unicable beissen. Beide gleichzeitig nutzen ergibt keinen Sinn da in ner Unicable Anlage sowas wie LNB-Sharing technisch nicht möglich ist.


    cu

  • Naja , LNB Sharing is abschaltbar, Unicable auch (bzw man brauch eine spezielle diseqc.conf) Muss doch wohl gleichzeitig einkompilierbar sein ?


    Erste Frage die sich mir stellt, kann man irgendwo Debuglog einstellen um die Geräteauswahl und Möglichkeiten transparenter zu machen ?

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Mal nochmal ein grundsätzlicher Gedanke zum LNB-Sharing-Patch (passt hier eigentlich gar nicht rein):


    Der LNB Sharing Konfigurationsdialog ist auf jeden Fall mal für Einsteiger sehr missverständlich.


    Da steht im OSD sowas wie:


    DVB-Device 1 an LNB1
    DVB-Device 2 an LNB2


    An meiner Sat-Schüssel habe ich zwar 2 LNBs hängen, aber: Wenn nun wie bei mir der Weg zu den LNB's über einen 9/8er Multiswitch läuft, bündelt der Multiswitch die LNBs zu einem ... sagen wir ... virtuellen LNB, der über Disecq Zugriff auf beide realen LNBs hat. (Klar, weil es zwei Quatro LNBs sind, die den "Schalter" nicht eingebaut haben.)


    Nun wäre es aber falsch, beim LNB-Sharing-Dialog zu sagen: Beide DVB-Devices hängen am Multiswitch, also beide am ...sagen wir... LNB1. Damit würde man ja wiederum LNB-Sharing scharfschalten, was ja wiederum von mir gar nicht gewünscht ist. Ich will ja kein LNB-Sharing betreiben.


    Also muss ich lügen: Obwohl DVB-Device 1 nicht am LNB1 hängt und DVB-Device 2 nicht an LNB2 hängt, muss ich es so konfigurieren, damit es funktioniert.


    Eigentlich müsste LNB-Sharing deaktiviert sein, sobald ein Disecq-Setup vorliegt. Ausnahme ist ein hochkomplexes Setup mit vielen Coaxkabeln und vielen DVB-Geräten und vielen Sat-Positionen, wo bei einigen mal LNB-Sharing gemacht wird, bei anderen nicht.


    Gruß
    hepi

  • Da fällt doch erstmal auf das sich LNB-Sharing und Unicable beissen. Beide gleichzeitig nutzen ergibt keinen Sinn da in ner Unicable Anlage sowas wie LNB-Sharing technisch nicht möglich ist.


    Wenn Hepi den unicable Patch nicht eigenhändig eingebaut hat, befindet sich dieser nicht in der Lucid unstable Version 1.7.17, hoplo hat als Maintainer z.Zt. andere Prioritäten.


    Der Patch ist tatsächlich nur in der Natty unstable Version 1.7.18 im Repo enthalten, was unicable als Fehlerquelle IMHO ausschließt, da das Fehlerbild augenscheinlich bei beiden Versionen, Natty 1.7.18 & Lucid 1.7.17, jeweils mit bzw. ohne (!) unicable Patch verifiziert werden kann.


    Regards
    fnu

    HowTo: APT pinning

  • Ich werde wohl nicht darum herum kommen, zum Testen einen Vanilla-VDR aufzusetzen bzw. einen VDR mit reduzierten Patches.


    Allerdings würde mich interessieren, ob es eine Möglichkeit gibt (ein Log), wo ich genau verfolgen kann, was meine DVB-Devices gerade zu tun versuchen. Im syslog finde ich zwar Einträge, die mir aber bisher nicht weiterhelfen konnten. Ich kann zwar LNB-Nutzung protokollieren lassen, aber ich sehe da nix interessantes.


    Gruß
    Henning

  • Ich werde wohl nicht darum herum kommen, zum Testen einen Vanilla-VDR aufzusetzen bzw. einen VDR mit reduzierten Patches.


    Hmm, ich denke da bist Du schneller, wenn Du Eure Sourcen nimmst, die relevanten Patches aus der 00list nimmst und den VDR daraus baust. Da Du dabei die Version nicht änderst sollte Deine Installationen seamless ohne die Patches weiterlaufen.


    Bezogen auf meinen "Harmonisierungs"-Thread fallen mir ein: lnb-sharing, subdevice, no-retune-on-tid und bei 1.7.18 noch unicable ...


    Just my 2 cents ... ;)


    Regards
    fnu

    HowTo: APT pinning


  • Hmm, ich denke da bist Du schneller, wenn Du Eure Sourcen nimmst, die relevanten Patches aus der 00list nimmst und den VDR daraus baust. Da Du dabei die Version nicht änderst sollte Deine Installationen seamless ohne die Patches weiterlaufen.


    Bezogen auf meinen "Harmonisierungs"-Thread fallen mir ein: lnb-sharing, subdevice, no-retune-on-tid und bei 1.7.18 noch unicable ...


    Ich habe schon mehrere VDR-Pakete auf die von Dir beschriebene Weise gebaut, nur harmonieren die dann nicht mehr mit den VDR-Plugins. Ich müsste dann elementare VDR-Plugins auch neu bauen, da der VDR beim Starten crasht. Das beste wäre, mir dafür ein eigenes PPA anzulegen, damit ich komfortabel die Paketstände einiger Pakete übersteuern kann.


    Gruß
    hepi

Jetzt mitmachen!

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