Sundtek SkyTV Ultimate IV am Cubietruck bleibt stehen?

  • Hallo zusammen,


    seit einer Woche teste ich gerade o.g. Kombination, finde aber den Fehler irgendwie nicht. Kurz zum Aufbau: Cubietruck mit wheezy, image von Igor Pecovnik und VDR nach dieser Anleitung installiert, Sundtek SkyTV Ultimate IV ohne USB-Hub direkt am Truck. Generell läuft das System auch prima, jedoch nach einiger Zeit (ca. 30h) finde ich plötzlich im mediaclient.log:

    Code
    2014-11-20 21:56:19 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:56:40 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:57:22 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:57:43 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:58:04 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:58:25 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)2014-11-20 21:58:46 [2694] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)

    und der Stick tut´s nicht mehr bis zum nächsten reboot, im /var/log/messages, dmesg o.ä. finde ich nix besonderes. Ich dachte erst an irgendeinen timeout vom vdr aber der einzige den ich kenne wäre im setup.conf: MinUserInactivity = 0 ... Wie kann ich dem Verhalten auf die Spur kommen? Ich habe testweise einen DVB-T Stick betrieben und hatte damit kein Problem, jetzt in diesem Moment ist das System sogar in diesem Zustand, kann also noch testen...


    Danke für Ideen! Oma

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • investiere die 3-4 € in einen aktiven usb hub und du bist einigen ärger los


    bei mir lief bisher kein usb dvb-gerät ohne aktiven hub ordentlich direkt an einem arm gerät egal ob cubieboard, himbeere oder banana-pi-router

  • Du müsstest in "dmesg" noch etwas mehr sehen.


    Das heisst nur das der Treiber "steckengeblieben" ist.
    Und der Treiber kann maximal steckenbleiben wenn die Kommunikation hängenbleibt, und das sollte dann in der Systemlog ersichtlich sein.


    Wir haben Systeme bei Kunden die schon Jahrelang laufen (und so muss das auch sein)


    Auch mit ARM oder MIPS gibt es langfristig gesehen idR keine Treiberprobleme, man muss sich aber sicher sein dass das System im Allgemeinen ordentlich arbeitet.

  • Das mit dem Hub kann ich sicher gern testen, jedoch der Hinweis das da ein 2A Netzteil am Cubietruck hängt und auch ansonsten nix am USB oder sonstwo dran hängt da z.B. Storage über NFS kommt - also ist der Stick wunderbar einsam und hat ja ebenfalls eine eigene Stromversorgung. Hier ist das dmesg mit allen Einträgen - was genau darin wäre der Hinweis das die Kommunikation steckenbleibt?
    Wie gesagt hatte ich das System vorher mit einem DVB-T Stick betrieben und da lief es ebenfalls wochenlang ohne Probleme also m.E. nach ordentlich. Sollte es echt an der Stromversorgung des USB Ports liegen besorge ich gern einen Hub, will aber gern sicher sein das es nicht doch was anderes ist...

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • "dmesg" wenn das Problem auftritt nicht wenn das Problem nicht auftritt ;)

    witzige Menschen bei SundTek :) Wie ich schon sagte: Das System befand sich zum Zeitpunkt des initialen posts in besagten Zustand, dmesg und mediaclient.log passen natürlich zusammen und m.E. nach ist dmesg sauber...


    Ich habe nun das System heruntergefahren um Moorvipers Tipp mit dem aktiven Hub zu folgen - mal sehen ob das etwas bringt. Gibt es denn eine weitere troubleshooting Möglichkeit? Spezielles debug vom Treiber das etwas mehr zur stockenden Kommunikation loggen würde?

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • /opt/bin/mediaclient --loglevel=min oder full schaltet das logging ein (min reicht aus), dann wird die Logfile geschrieben /var/log/mediasrv.log


    Oder du startest den Treiber gleich manuell


    cd /opt/bin
    ./mediaclient --shutdown # vorherige Instanz stoppen
    ./mediasrv -v # Treiber starten (Logausgabe erfolgt direkt auf der Shell)



    Die Logfile-Ausgabe in Beitrag #1 deutet darauf hin das die Kommunikation zum Treiberserver nicht mehr funktioniert hat. Das kann (wenn ich es mir überlege) durch 2 Dinge verursacht werden, 1. Treiber wurde gestoppt, 2. USB blockiert.

  • gegen 23:46 ist die Kommunikation, trotz nunmehr aktivem USB Hub, mit den üblichen Meldungen steckengeblieben:

    Code
    2014-11-23 23:46:29 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:46:50 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:47:11 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:47:32 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:47:53 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:48:14 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-23 23:48:35 [2677] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)


    laut /etc/sundtek.conf habe ich das Loglevel schon hochgedreht, kann aber nicht sehen ob das .conf File auch beim boot angezogen wird, trotzdem hier die letzten zwei Einträge - der Rest scheint ja nur für die (ungenutzte) ir zu sein:

    Code
    loglevel=maxenablenetwork=on

    dann habe ich wie beschrieben den mediaclient gestoppt, per ./opt/bin/mediasrv -v neu gestartet und versucht über VLC+streamdev einen Kanal anzuwählen - hier das logfite der Konsole:

    aber kein Bild... Ich habe dann das System neu gebootet und nun funktioniert es wieder für einige Stunden. Da ich den "network support" als auch ir eigentlich nicht brauche kann ich den auch deaktivieren, kann es damit etwas zu tun haben?

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • nichts auf den Tuner zugreift


    ??? VLC über streamdev ist doch nicht "nichts" - das sollte eigentlich schon reichen um über den VDR den Treiber zu bemühen...

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • Nein vdr hat das Gerät bei dir durch den Neustart des Treibers verloren, VDR nimmt die vorhandenen Tuner nur beim Start auf (sprich VDR hatte nur noch eine tote Session zur alten Treiberinstanz wenn überhaupt).


    Dynamite kann das auch dynamisch regeln aber das wirst du nicht konfiguriert haben nehme ich an.


    Nachdem du den Treiber manuell gestartet hast solltest du also VDR neu starten dann wird das auch mit streamdev klappen und du wirst Frequenzeinträge in der Ausgabe des Treibers finden.

  • Hallo zusammen,


    ich klinke mich mal ein, da sich mein VDR Server auch immer nach 2-3 Tagen verabschiedet.
    Möglicherweise hadern wir mit ähnlichen Problemen...
    Hier gibts den Ausschnitt aus dem syslog und das kpl. dmesg. Los gehts im Prinzip mit einem "mediasrv: page allocation failure". Die Verabschiedung des VDR fand bei mir am 23.11. um 22:54 statt - falls es jemand nicht erkennen sollte :p
    Ich denke aber, es ist relativ einfach zu erkennen, dass bei mir noch so einiges schief läuft. Schade war gestern, dass mir die letzten 5 Minuten der Aufnahme fehlen


    Am USB der Mele A2000 hängen die 2 Sundtek und eine USB Platte. Kein aktiver Hub und Stromversorgung der Sundteks aktuell vom LNB.


    Vielleicht kann mir ja jemand auf die Spur helfen. Danke!


    Gruß Andreas

  • Rell, dein Problem benötigt einen Kernelpatch. Es sind aber nur die Auswirkungen dessen das dem System der DMA fähige Speicher ausging, das passiert wenn das System (VDR und all die anderen Applikatonen) im Allgemeinen zu dem Zeitpunkt zuviel speicher benötigen.


    Wir haben soweit einen Patch für Linux damit man den Speicher vor-allokieren kann, die eigentliche Lösung ist jedoch das System vom Speicherverbrauch etwas zu optimieren. Weniger Plugins? Schauen was VDR sonst so macht.
    Es ist kein Treiberproblem, da der Treiber für den Speicher auch nicht zuständig ist. Der Kernel konnte für die USB Datenübertragung keinen Speicher reservieren (=Page allocation failure).

  • seit ich den Truck mit "enablenetwork=off" neu gestartet habe läuft er bislang zwei Tage fehlerfrei und ohne Logeinträge o.ä. mal sehen ob sich das hält... :sleep

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • Pustekuchen, seit heute 17:09 ist er wieder hängen geblieben:

    Code
    2014-11-28 17:09:14 [2669] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-28 17:09:35 [2669] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-28 17:09:56 [2669] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)
    2014-11-28 17:10:17 [2669] WARNING: could not send everything to driver 2032 Datenübergabe unterbrochen (broken pipe) (32)

    und laut dmesg bzw. kern.log gab´s kein Event seit dem reboot:

    Code
    Nov 24 05:53:08 localhost kernel: [   31.839597] Bluetooth: BNEP (Ethernet Emulation) ver 1.3Nov 24 05:53:08 localhost kernel: [   31.851066] Bluetooth: BNEP filters: protocol multicastNov 24 05:53:13 localhost kernel: [   36.735898] eth0: no IPv6 routers present

    und auch /var/log/messages ist clean:

    Code
    Nov 28 16:23:00 localhost vdr: [2721] EPGSearch: timer conflict check finishedNov 28 16:53:00 localhost vdr: [2721] EPGSearch: timer conflict check startedNov 28 16:53:00 localhost vdr: [2721] EPGSearch: timer conflict check finishedNov 28 17:23:00 localhost vdr: [2721] EPGSearch: timer conflict check startedNov 28 17:23:00 localhost vdr: [2721] EPGSearch: timer conflict check finishedNov 28 17:53:00 localhost vdr: [2721] EPGSearch: timer conflict check started

    Da ich für die nächsten zwei Tage keine Aufnahme geplant habt lasse ich das System mal in dem Zustand und hoffe jemand von Euch hat da einen guten Tipp wie ich den Fehler finden kann?

    "...ich bin Guybrush Threepwood - ein mächtiger Pirat!"


    VDR1: Shuttle SG31G, Zotac GT210 Silent, 2GB DDR3, Intel Core2d 2.4GHz, 3 TB über NFS, Tivii 464 DVB-S2, yaVDR 0.5 - VDR 2.0.2-3, Ubuntu 12.04.3 LTS, (ppa:yavdr/stable-vdr), VDR2: Cubietruck, Debian Wheezy, 2TB lokal, Sundtek SkyTV Ultimate IV, VDR 2.3.8, Client1: Raspberry Pi2 mit Kodi 17.6 auf Openelec, Client2: Nexus7

  • Starte den Treiber manuell


    cd /opt/bin
    ./mediaclient --shutdown
    ./mediasrv -v


    danach VDR neu starten.


    Dann siehst du eventuell auch ob oder warum der Treiber sich beendet.


    Die derzeitigen Logs sind jedenfalls so nicht brauchbar.
    Sollte es am Treiber liegen, könnten wir dir auch eine Debugversion geben; aber Crashes des Treiberserver (wo der Treiber schuld war) mit DVB-S/S2 wurden bis jetzt den letzten Monat über eigentlich keine von unseren Kunden mitgeteilt - und jeder verwendet den gleichen Treiber.

  • Bei mir tritt/trat genau dasselbe Problem auf meinem cuboxi-pro auf. Leider bin ich erst jetzt auf diesen Thread gestoßen, und habe die Logfiles damals noch nicht gesichert. Fehlermeldungen genau die Gleichen wie bei oma. Ich benutze ebenfalls das Image von Igor Pečovnik und bei mir hängt der Stick auch allein ohne ein weiters USB-Gerät am Port. Ich habe den Stick trotz mehrmaliges Entladen und Laden des Treibers nicht wieder zum Leben erwecken können, erst nach einem kompletten Reset lief das System dann wieder. VDR Version 2.1.6. Ich habe den Treiber mal entsprechend des Vorschlags von Sundtek mit ./mediasrv -v gestartet und schau jetzt mal was passiert...


    Sundtek
    Nach "use_hwpidfilter=on" in "/etc/sundtek.conf" lief das System nur stockend und es kam zu MPEG-Artefakten. Nehm ich das wieder raus, gibt's keine Probleme mehr. Ich dachte eigentlich, das Einschalten sollte die Last auf z.B. ARM-Rechnern reduzieren. Hab ich da irgendwas was übersehen, oder vergessen?



    Code
    cubox-i:~# uname -a
    Linux cubox-i 3.14.14-cubox #5 SMP Fri Oct 24 19:14:47 CEST 2014 armv7l GNU/Linux




  • Wenn nur ein Neustart USB wieder zum Leben bewegen kann dann gibt es auf dem System einen allgemeinen Bug im USB Controller Treiber!


    Unser Treiber kann kein Lockup verursachen, er ist ja nur eine Applikation und verwendet die generischen Linux USB Schnittstellen.


    Bugs diesbezüglich sollten wohl am Besten an die Cubietruck Entwickler geschickt werden.


    Ihr könnt noch versuchen den Transfer auf den anderen Modus umzuschalten und die Fernbedienung auszuschalten.
    Auf einigen Systemen bereiten Interrupt Transfers der Fernbedienung Probleme (auch wieder USB Controller Treiber bugs)
    /etc/sundtek.conf
    ir_disabled=1


    (danach den Treiber neu starten)
    /opt/bin/mediaclient --shutdown
    /opt/bin/mediaclient --start



    Um den Transfermodus umzuschalten:
    /opt/bin/mediaclient --transfermode=iso -d /dev/dvb/adapter0/frontend0
    oder
    /opt/bin/mediaclient --transfermode=bulk -d /dev/dvb/adapter0/frontend0


    Default ist Bulk.


    Unsere Geräte sind sehr gut zum Testen von defekten USB Controllern geeignet, da die Treiber keine Folgeprobleme im Kernel anrichten können, man sieht damit direkt die Qualität des USB Supports von einem System.

  • Sundtek
    Wow, das ging wirklich schnell! Respekt!
    Ich habe bereits die Fernbedienung von Anfang an ausgeschaltet (siehe meine Konfig), aber daran lags nicht, da der Fehler erst später aufgetreten ist. Das mit dem USB-Controller-Treiber will ich nicht ausschließen, allerdings hab ich in den Kernel-Logfiles bisher nichts finden können. Ich würde aber gern erstmal abwarten, ob ./mediasrv -v was bringt. Momentan läuft das System seit 3 Tagen stabil, schau'n wir mal... :)


    Könntest du noch was zu meiner Frage bzgl. des HWPID-Filterings sagen?


    Danke!

Jetzt mitmachen!

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