Sundtek Support Forum

Hallo,

ich habe ein schwer reproduzierbares Problem, das aber doch alle paar Stunden bei Nutzung von Analog TV auftritt:

Der mplayer/mplayer2/mencoder bleibt "hängen" mit der Meldung
v4l2: ioctl dequeue buffer failed: Success, idx = 0
v4l2: ioctl query buffer failed: Broken pipe, idx = 0Im mplayer werden dann die letzten beiden Bilder endlos wiederholt.

Neustart nach kurzer Pause funktioniert häufig, aber nicht immer: Manchmal kommen die selben Hänger nach 3-4 Sekunden nach Neustart wieder, manchmal auch sofort; falls ja, ist das minutenlang reproduzierbar, und selbst Neueinstecken des Sticks, ja sogar Abschalten des Stroms des Rechners ändert daran nichts. Merkwürdigerweise geht es nach etlichen Minuten dann meist aber doch wieder, und zwar für etliche Stunden zuverlässig, bis der Stick irgendwann wieder in diesen schlechten "Modus" fällt.

In den Logs sehe ich im günstigen Fall (falls es danach gleich wieder geht):
[...] lange nichts [...]
12:24:09 18.05.14 [kernel] usb 3-7: USB disconnect, device number 9
12:24:10 18.05.14 [kernel] usb 3-7: new high-speed USB device number 10 using xhci_hcd
12:24:10 18.05.14 [mtp-probe] checking bus 3, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
12:24:10 18.05.14 [mtp-probe] bus: 3, device: 10 was not an MTP device_
12:24:11 18.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input13
12:24:29 18.05.14 [kernel] usb 3-7: usbfs: process 1594 (mediasrv) did not claim interface 0 before useIm ungünstigen Fall sehe ich Kaskaden von solchen Meldungen:19:42:27 14.05.14 [kernel] usb 3-7: USB disconnect, device number 6
19:42:27 14.05.14 [kernel] usb 3-7: new high-speed USB device number 7 using xhci_hcd
19:42:27 14.05.14 [mtp-probe] checking bus 3, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:42:27 14.05.14 [mtp-probe] bus: 3, device: 7 was not an MTP device_
19:42:28 14.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input11
19:42:47 14.05.14 [kernel] usb 3-7: usbfs: process 1643 (mediasrv) did not claim interface 0 before use
19:44:58 14.05.14 [kernel] usb 3-7: USB disconnect, device number 7
19:44:58 14.05.14 [kernel] usb 3-7: new high-speed USB device number 8 using xhci_hcd
19:44:59 14.05.14 [mtp-probe] checking bus 3, device 8: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:44:59 14.05.14 [mtp-probe] bus: 3, device: 8 was not an MTP device_
19:44:59 14.05.14 [kernel] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input12
19:45:18 14.05.14 [kernel] usb 3-7: usbfs: process 1643 (mediasrv) did not claim interface 0 before use
19:46:06 14.05.14 [kernel] usb 3-7: USB disconnect, device number 8
19:46:07 14.05.14 [kernel] usb 3-7: new high-speed USB device number 9 using xhci_hcd
19:46:07 14.05.14 [mtp-probe] checking bus 3, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-7"_
19:46:07 14.05.14 [mtp-probe] bus: 3, device: 9 was not an MTP device_Auffallend für mich ist in der "schlechten" Phase das systematische Durchlaufen der Device-Nummern.

mtp-probe scheint übrigens mit dem Problem nichts zu tun zu haben: Wenn der Stick seine schlechte "Phase" hatte, habe ich die entsprechende udev-Regel auch schon entfernt, ohne eine wesentliche Änderung zu erzielen.

Der Erstauslöser ist aus den Logs aber vermutlich nicht sichtbar, denn die "USB disconnect" Meldung sollte ja vermutlich nicht aus heiterem Himmel auftreten...

Vielleicht ist das ein klassisches PEBCAK, aber ich bin unter Gentoo Linux nicht in der Lage, die Fernbedienung anzusprechen. Dazu muss man wissen, dass man unter Gentoo den Kernel selbst baut, und auch den lirc-Treiber selbst auswählen muss. Vielleicht fehlt also nur eine triviale Kernel-Option, oder ich habe lirc mit den falschen Treibern gebaut. (Vielleicht ist aber auch das ebuild buggy, das den Treiber installiert...)

Entsprechend http://support.sundtek.com/index.php?topic=46.0 habe ich meine Fernbedienung (#2) mit /opt/bin/mediaclient --updaterc=2 -d /dev/mediainput0 konfiguriert, aber ich fürchte, ich bin gar nicht so weit gekommen, dass das relevant wäre...

Was bislang funktioniert: TV einwandfrei, von der Fernbedienung scheint der Kernel gar nichts zu wissen: Keine logmeldung, kein /dev/lirc* wird generiert, /proc/bus/input/devices enthält nichts bzgl. sundtek (lsusb zeigt aber, dass der Stick da ist, und TV geht ja auch). Wenn nicht eine Fernbedienung mitgeliefert worden wäre, hätte ich vermutet, dass der Stick gar keine unterstützt...

Nachdem ich zunächst die grsecurity-Patches im Verdacht hatte, habe ich jetzt einen Vanilla-Kernel 3.14.3 neu kompiliert, mit dem gleichen Problem. CONFIG_LIRC=m und CONFIG_IR_LIRC_CODEC=m sind gesetzt, und auch sonst alle CONFIG_IR_* ausgewählt.

Beim lirc-Programm habe ich das Problem, dass nur ein Treiber geladen werden kann, und ich habe keine Idee, welcher: Die Auswahl ist riesig: accent act200l act220l adaptec all alsa_usb animax asusdh atilibusb atiusb audio audio_alsa avermedia avermedia98 avermedia_vdomate awlibusb bestbuy bestbuy2 breakoutbox bte bw6130 caraca chronos commandir cph06x creative creative_infracd devinput digimatrix dsp dvico ea65 ene0100 exaudio flyvideo ftdi gvbctv5pci hauppauge hauppauge_dvb hercules_smarttv_stereo i2cuser igorplugusb iguanaIR imon imon_24g imon_knob imon_lcd imon_pad imon_rsc inputlirc irdeo irdeo_remote irlink irman irreal it87 ite8709 knc_one kworld leadtek_0007 leadtek_0010 leadtek_pvr2000 livedrive_midi livedrive_seq logitech macmini mediafocusI mouseremote mouseremote_ps2 mp3anywhere mplay nslu2 packard_bell parallel pcmak pcmak_usb pctv pixelview_bt878 pixelview_pak pixelview_pro provideo realmagic remote_wonder_plus remotemaster sa1100 samsung sasem sb0540 serial serial_igor_cesko silitek sir slinke streamzap tekram tekram_bt829 tira ttusbir tuxbox tvbox udp uirt2 uirt2_raw usb_uirt_raw usbirboy usbx userspace wpc8769l xboxusb zotac
("all" bedeutet, dass man trotzdem den richtigen Treiber manuell einstellen muss...)

Versucht habe ich bislang usbx, userspace, inputlirc. inputlirc benötigt einen separaten Daemon inputlircd, dem ein passendes /dev/input/event* übergeben werden muss, aber ohne irgendwelche Logmeldungen, weiss ich natürlich nicht, welches; Default scheint /dev/input/event2 zu sein, was bei mir das erste freie ist, aber damit scheint es nicht zu gehen.

Die Reaktionen auf "irw" waren immer entweder (meist) "connect: No such file or directory" oder einfach ein Hängen. Bei usbx kam eine Logmeldung, dass /dev/lirc0 nicht existiert und die Hardware nicht initialisiert werden könne.

Ja, genau das hatte ich gesucht. Ich melde mich, sobald der Overlay entsprechend "gefixt" wurde.

Benutzer von Gentoo-Linux haben es wahrscheinlich schon gefunden. Dennoch will ich hier ankündigen, dass der mv overlay (der einfach mit layman installiert werden kann) ein inoffizielles(!) Ebuild für die Treiber enthält.

Für Benutzer anderer Linux-Distributionen ist vielleicht das _mediaclient zsh-completion file interessant, das für zsh-Nutzer Vervollständigung der Optionen des mediaclient-Kommandos erlaubt: einfach in den $fpath (i.d.R. /usr/share/zsh/site-functions) legen. Desweiteren gibt es ein mediaclient.{video,radio,dvb} script, das die Option -d von mediaclient automatisch passend ergänzt, wenn man nur ein Sundtek-Device hat. Beides kann man unmittelbar hier herunterladen:
http://git.overlays.gentoo.org/gitweb/?p=user/mv.git;a=tree;f=media-tv/sundtek-tv/files
(für mediaclient.{radio,dvb} tun es Symlinks auf mediaclient.video).

Wohlgemerkt, das Ebuild und beide Skripte sind inoffiziell, und es wird natürlich keine Haftung übernommen.

Die Vorteile, wenn man über ein Ebuild installiert, sind klar: Der Paketmanager kennt die installierten Files, passt auf Kollisionen auf, kann selbst deinstallieren, usw. Für hardened-Nutzer (mit PAX-Kernel) von Gentoo werden bei der Installation die notwendigen Rechte vergeben, wenn das entsprechende USE-Flag gesetzt ist.

Edit: Eine Bemerkung zur Handhabung des Ebuilds wurde aus diesem Posting gelöscht, da nach der Diskussion in diesem Thread ein "reguläres" Ebuild möglich ist.

Edit 2: Problembeschreibungen entfernt, da diese in getrennte Threads gehören.