Unklares Problem mit MythTV - Partial Lock

[raivan10]

Liebe Sundtek Community,

ich habe ein Problem und bin schon etwas frustriert. Ich möchte kurz skizzieren welche Hard- und Software ich im Einsatz habe und um welches Problem es sich handelt.

Hardware: Zotac ZBOX CI320 nano und Sundtek MediaTV Pro III
Fernsehanbieter: DVB-C
Software: Ubuntu 14.04.2 LTS und MythTV 0.27.4

Grundsätzlich funktioniert alles perfekt, leider nur nicht dauerhaft. Ich weiß nicht welcher Teil des Systems das Problem verursacht.

Folgendes passiert:

Das System funktioniert einwandfrei, aber nach einer gewissen Zeit, meistens einige Stunden bekommt MythTV keine "Daten" mehr vom Stick oder kann nicht mehr darauf zugreifen.

MythTV legt bei den Aufnahmen alles in der Datenbank an und "nimmt auch auf" das zugehörige MPEG-File gibt es aber am Ende nicht.

Wenn ich normalerweise auf MythTV auf Live-TV zugreife, dann steht TLMS Lock da, wenn das Problem auftritt steht nur mehr TM__ Partial Lock da.

Folgendes konnte ich mit den Mittels des Sundtek-Treibers herausfinden:

Wenn ich mit tail -f /var/log/mediasrv.log bei vollem Error-Level mitlese, sehe ich genau wie die beim umschalten die Kanäle gewechselt werden. Sieht sowohl im Normal- als auch im Fehlerfall alles normal aus.

Im Logfile von MythTV finde ich auch bei voll aufgedrehtem Loglevel keine Errors. Wie oben beschrieben, MythTV tut ja auch so, als würde alles normal aufgenommen werden. Das Problem tritt bei allen Sendern auf. Treiber habe ich den von Anfang März installiert.

Mein Problem ist, ich weiß nicht mal was genau das Problem ist.

/opt/bin/mediaclient --lc zeigt mehr(viel)fach mythbackend an.

/dev/dvb/adapter0/frontend0:
  2323 ... mythbackend
/dev/dvb/adapter0/dvr0:
  2323 ... mythbackend
/dev/dvb/adapter0/demux0:
  2323 ... mythbackend (0000)
  2323 ... mythbackend (0001)
  2323 ... mythbackend (0010)
  2323 ... mythbackend (0011)
  2323 ... mythbackend (0012)
  2323 ... mythbackend (0014)
  2323 ... mythbackend (0029)
  2323 ... mythbackend (0035)
  2323 ... mythbackend (0054)
  2323 ... mythbackend (0055)
  2323 ... mythbackend (0092)
  2323 ... mythbackend (00ad)
  2323 ... mythbackend (044d)
  2323 ... mythbackend (044e)
  2323 ... mythbackend (0452)
  2323 ... mythbackend (0461)
  2323 ... mythbackend (0462)
  2323 ... mythbackend (0463)
  2323 ... mythbackend (0464)
  2323 ... mythbackend (0465)
  2323 ... mythbackend (0466)
  2323 ... mythbackend (0467)
  2323 ... mythbackend (0468)
  2323 ... mythbackend (0469)
  2323 ... mythbackend (046a)
  2323 ... mythbackend (046b)
  2323 ... mythbackend (046d)
  2323 ... mythbackend (046e)
  2323 ... mythbackend (0470)
  2323 ... mythbackend (0474)
  2323 ... mythbackend (04ba)
  2323 ... mythbackend (04bb)
  2323 ... mythbackend (04d9)
  2323 ... mythbackend (0f02)
  2323 ... mythbackend (1100)
/dev/video0:
  No client connected
/dev/vbi0:
  No client connected
/dev/radio0:
  No client connected
/dev/rds0:
  No client connected
/dev/mediainput0:
  No client connected
/dev/dsp0:
  No client connected

/opt/bin/mediaclient --readsignal=2 -d /dev/dvb/adapter0/frontend0 zeigt:

SIGNAL: [...............................  ] ( 93%)  BER:      0 FREQ: 442000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [...............................  ] ( 93%)  BER:      0 FREQ: 442000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256

Hier hatte jemand ein sehr ähnliches Problem, aber leider keine Lösung: http://support.sundtek.com/index.php/topic,1417.0

Für neue Lösungsansätze wäre ich sehr dankbar!

Lukas

Editiert von Sundtek // Wap Link durch richtigen Link ersetzt

[Sundtek]

Was zeigt lsusb -t an?

Der Tuner sollte ausschließlich unter EHCI gelistet sein, wenn er unter XHCI gelistet wird müsste ein Fehlerbericht im Linux Kernel Bugzilla erstellt werden bezüglich USB 3.0

Laut der Spezifikation des Systems unterstützt das System USB 3.0 -- diese Ports sollten nicht verwendet werden.

Du kannst ja mal im Hintergrund versuchen folgendes laufen zu lassen:

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000

mediaclient --lc zeigt in der Tat an wie ineffizient MythTV aufgebaut ist.. es ist nicht wirklich für DVB-C optimiert...

[raivan10]

Vorab, vielen Dank für den superfast response!

Also lsusb -t zeigt:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
        |__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 4, If 2, Class=Vendor Specific Class, Driver=usbfs, 480M
        |__ Port 1: Dev 4, If 3, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 4, If 4, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 4, If 5, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 4, If 6, Class=Vendor Specific Class, Driver=, 480M

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000 zeigte während eine Aufnahme lief:

[2015-05-01 13:38:34]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:35]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:36]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:37]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:38]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:39]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:40]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:41]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:42]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:43]          0 bytes |       0.00 kb |       0.00 mb transferred
[2015-05-01 13:38:44]          0 bytes |       0.00 kb |       0.00 mb transferred

Ich stecke jetzt mal auf einen USB2 Port um!

[Sundtek]

Melde dich eventuell via Skype (sundtek) damit man hier einen Linux Bugreport zusammenfassen kann.

Linux und USB 3.0 Controller sind eine Welt für sich, kein Betriebssystem unterstützt diese derzeit so schlecht wie Linux.

[raivan10]

Ich habe bei meinem letzten Post auf einen der USB2 Ports umgesteckt. Das System funktioniert soweit, aber es ist noch zu früh um eine Aussage treffen zu können. Es hat ja bis dato auch immer einige Stunden funktioniert. Ich werde es weiter beobachten und hier berichten. Vielen Dank nochmals für den guten Service, bezüglich des Bugreports würde ich mich nächste Woche melden. Lukas

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000

[2015-05-02 02:29:09]    2058240 bytes |    2010.00 kb |       1.96 mb transferred
[2015-05-02 02:29:10]    2058240 bytes |    2010.00 kb |       1.96 mb transferred
[2015-05-02 02:29:11]    2058240 bytes |    2010.00 kb |       1.96 mb transferred
[2015-05-02 02:29:12]    2048000 bytes |    2000.00 kb |       1.95 mb transferred
[2015-05-02 02:29:13]    2068480 bytes |    2020.00 kb |       1.97 mb transferred
[2015-05-02 02:29:14]    2007040 bytes |    1960.00 kb |       1.91 mb transferred
[2015-05-02 02:29:15]    1792000 bytes |    1750.00 kb |       1.71 mb transferred
[2015-05-02 02:29:16]    1843200 bytes |    1800.00 kb |       1.76 mb transferred

lsusb -t hier scheint noch immer xhci auf, woran kann das liegen?

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
    |__ Port 4: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 4: Dev 4, If 2, Class=Vendor Specific Class, Driver=usbfs, 480M
    |__ Port 4: Dev 4, If 3, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 4: Dev 4, If 4, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 4: Dev 4, If 5, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 4: Dev 4, If 6, Class=Vendor Specific Class, Driver=, 480M

[Sundtek]

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000

Ich denke wenn du das laufen lässt sollte es das Problem bei dir übergehen.
Ich denke die Controller haben ein Problem mit dem USB Transfer Reset welches indirekt beim Stoppen des Transfers durchgeführt wird. Während funktionierende Controller damit kein Problem haben - haben Linux inkompatible USB Controller damit sehr wohl ein Problem.

[raivan10]

Also das Umstecken auf USB2 alleine hat nichts gebracht. Ich lasse nun seit gestern /opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000 mitlaufen, seither funktioniert das System soweit, wobei ich noch nicht sicher bin ob das auch dauerhaft so bleiben wird. Ich verändere jetzt noch nichts an dem Setup und lasse es so weiterlaufen.

Ein Kollege gab mir den Tipp, dass es evtl. auch mit dem USB Autosuspend von Linux zu tun haben könnte. Ich habe folgendes gefunden, könnte das vll. das Problem verursachen? Anders gefragt, könnte man mit usbcore.autosuspend=-1 das Problem beheben (siehe Antwort in dem Post)?

http://askubuntu.com/questions/526082/2-usb-ports-stopped-working

[Sundtek]

Ich denke wir haben hier schon mal einen guten Ansatz - auch für einen offiziellen Linux Bugreport für USB 3.0, melde dich ggf. via Skype (sundtek).

Welche Linux Kernel Version verwendest du?

[raivan10]

Kernel 3.16.0-33-generic, ich melde mich diese Woche per Skype.