Streamdev Client/Server + CI Modul = Glückspiel ?

  • Hallo Leute


    ich habe hier einen Versuchsaufbau welcher wie folgt aussieht:


    Server mit 4.14.x Kernel +dddci Plugin + VDR (aktuelle Unstable Version) + Streamdev aus dem GIT + CI (Alpha)

    RPI3 + rpihdplugin (git) + streamdevserver (git)


    Das ganze funktioniert auf den FTA Kanälen Problemlos - Zappen so wild man will ...

    Auf den Kanälen für das CI wiederum ist das eher ein Glückspiel ob der bildschirm schwarz bleibt oder ein Bild kommt - Chance 2:1


    Das seltsame: Streame ich einen Kanal der über den Raspi (Streamdev client) dunkel bleibt über VLC (http) habe ich binnen Sekunden BILD und TON


    Kann es sein dass Streamdev (client oder server) hier in einen Timeout laufen ?


    Ich hab schon im Forum gesucht aber nix gefunden (evtl falsch gesucht) - evtl gibts hier nen Patch oder andere Stellschrauben ?!?


    CU

    GTR

  • evtl gibts hier nen Patch

    Ja, ein paar Threads weiter unten in diesem Unterforum gibt es was, das helfen soll: vdr-plugin-streamdev-server/-client => mit vdr 2.3.4 nur FTA möglich

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Für beide - um das zu wissen muss man sich nur ansehen, welche Dateien vom Patch geändert werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bitte berichten ob das bei Euch funktioniert mit dem Patch.

    Bei mir gab es leider nur sporadisch Verbesserungen.

    Gruß
    Frodo

  • @Frodo du nutzt es auch mit Physik oder mit satip?

    bei mir läuft es mit den Cine S V6 an unicable schon sehr schön. Manchmal, so ca einmal die Woche krieg ich den Server allerdings beim Zappen zum Blockieren, da hilft nur noch vdr restart auf dem Server.

    Leider ist das ein Ausschlusskriterium, Client neustarten wäre noch zu verkraften aber wenns den ganzen Server VDR wegreißt ist das schwierig. Was mir auch im Vergleich zum satip nicht so gefällt ist das die Streams nach Restart des Servers ohne einmal umzuschalten nicht weiterlaufen.

     CKone: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.3.8 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

  • Der Server hat bei mir Physik, d.h. 2x DD DuoFlex S2 V4 an Jess/Unicable + Digital Devices Octopus Duo CI.


    Ich dachte ja es läuft, aber nach einem Restart des Servers konnte der Client sich gar nicht mer bzw. nur noch vereinzelt auf FTA Kanäle verbinden. Auch ein restart des Client VDRs brachte keinen erfolg.

    Gruß
    Frodo

  • Hallo


    das ist jetzt zwar OT - aber mit dem Unicable Gedöns bin ich auf Kriegsfuß - ich habe bei meinen Eltern eine Unicable Anlage von Kathrein - bei einem bekannten und einem anderen Bekannten - alles umgerüstete Anlagen die vorher klassische durchgeschleifte HF Antennen Anlagen waren.


    Die Leute verwenden ganz normale SAT Empfänger (auch weil ich nach tagelnagem Versuch die in den TV´s (Samsung Grundig und LG) integrierten Empfänger mit dem Unicable vernünftig zum laufen zu kriegen aufgegeben habe - aber selbst mit den Opticum Single Tuner Recievern ist das noch immer nicht so wie es sein soll..


    Das geht mal 1 Woche super - dann funktionieren plötzlich an einzelnen Tunern bestimmte Transponder nicht mehr - dann gehts wieder - dann muss man einen ganz trennen usw... - Bei den gepatchten Optucum gibts in der Firmware ne Option die Umschaltsignale mehrfach zu senden um die Chance zu erhöhen dass diese bei der Matrix richtig ankommen -aber selbst das zickt immer wieder mal.


    Ich hab noch nen anderen Bekannten mit ner Unicable Anlage in einem Neubau (weil der Elektriker kabel vergessen hat...) - die ist halt sauber und linear aufgebaut - da ist nix verdecktes drin - keine Zweigstränge - die läuft absolut sauber ...


    Soll jetzt keine Schimpftirade gegen Unicable sein - sondern nur ein dezenter Hinweis dass es evtl auch daran liegen könnte ...


    Ober der Patch was gebraucht hat sehe ich heute Abend

  • guten morgen,

    Der Server hat bei mir Physik, d.h. 2x DD DuoFlex S2 V4 an Jess/Unicable + Digital Devices Octopus Duo CI.


    Ich dachte ja es läuft, aber nach einem Restart des Servers konnte der Client sich gar nicht mer bzw. nur noch vereinzelt auf FTA Kanäle verbinden. Auch ein restart des Client VDRs brachte keinen erfolg.

    selbiges verhalten kenne ich, sobald der patch

    ring buffer overflows -> cDevice::Detach() blockiert...

    installiert wird.

    das haengt evtl. mit den ganzen patches zusammen, die in @frodos testing-vdr-dev fuer den vdr gezogen werden. ein vanilla-vdr 2.3.8,

    mit den beiden genannten patches fuer den vdr und streamdev, laeuft hier seit 20.12.17 ohne unterbrechung und absturz als server


    gruss

    beinhart

  • Ich probiere es mal ohne den Patch. Allerdings ist das Launchpad gerade besonders langsam... (vor 2 Stunden hochgeladen und vermutlich erst in 3 Stunden wird das bauen gestartet)

    Gruß
    Frodo

  • Als ich an den streamdev Problem gearbeitet habe, hatte ich auch immer ein vanilla-vdr 2.3.8 verwendet.


    Bei den MLD Leuten gibt es wohl auch das Problem, welches Frodo hier beschreibt.

    Die haben wohl auch eine ganze Reihe vdr-Patche integriert, wenn ich das richtig sehe. Kann schon sein, dass es daran liegt.


    Das sich der Server manchmal aufhängt, kann schon an dem "cDevice::Detach() blockiert" Problem liegen, wofür Klaus ein Patch bereit gestellt hat.

    Da sich der Server bei mir bis jetzt noch nicht aufgehangen hat und der Patch von Klaus bei mir irgendwie vorbei gegangen ist, habe ich es damit natürlich nie getestet ;-)

  • Ich hatte die Patches schon sehr reduziert, da ich noch diverse Probleme mit segfaults habe.

    Aktuell nutze ich nur noch die folgenden Patches:

    Den letzten Patch habe ich heute deaktiviert, leider scheint das Launchpad keine Lust zu haben. (Nach 10 Stunden soll ich nun weitere 8 warten) Und das obwohl noch die ganzen Plugins fehlen... ;(

    Gruß
    Frodo

  • Meine ganzen Tests bis Dezember waren allesamt auch mit einem Vanilla VDR 2.3.8 - ohne irgend welches zusätzliches Gedöns, also nur

    mit einem gepatchten streamdev (client und server). Ich habe es mit unterschiedlichsten Kombinationen über Wochen hinweg ausprobiert,

    und war zu mindestens 99,9% zufrieden.


    Beim Thema MLD sieht es leider nicht mehr ganz so spitze aus.


    In der X86-64 Variante treten sporadisch mal Probleme auf - also vllt. so 95% - warum auch immer...


    Die RPI Varianten sind derzeit leider nicht testbar, da sich scheinbar, in der MLD-5.4 Testing nach der Version vdr-2.3.8.214.42-214.43, irgend

    welche Bugs eingeschlichen haben, die jegliches Testen unmöglich machen. Außerdem ist die aktuelle streamdev client/server Variante im

    RPI Zweig vorübergehend nicht mehr gepatcht.


    Bleiben also nur die MLD -5.4 Testing Varianten für X86-xx Hardware als Testobjekte.


    Sicherheitshalber hab ichs vorhin nochmal mit vanillas probiert, und das geht immer noch einwandfrei.


    Werd's auch nochmal in Kreuzkombination probieren: MLD-Server-->Vanilla-Client und Vanilla-Server-->MLD-Client


    -Wanninger

  • Hi Frodo,

    Den letzten Patch habe ich heute deaktiviert, leider scheint das Launchpad keine Lust zu haben. (Nach 10 Stunden soll ich nun weitere 8 warten) Und das obwohl noch die ganzen Plugins fehlen...

    ...zum Thema "Launchpad"

    > https://lists.ubuntu.com/archi…/2018-January/000103.html


    Gruss

    Wolfgang

  • Hi,


    ich war heute Vormittag auf der Suche nach dem Selben Problem und konnte ebenfalls den vdr-2.3.8-fixdevicedetachlock-2 Patch von Klaus als Ursache ausmachen.


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 6TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.3 mit vdr 2.3.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • Hier noch der Backtrace der 2 Threads die anscheinend den Deadlock verursachen: