Dynamite und Tuner abschalten

Ohne idle ist der USB-Port ja auch unter Dauerfeuer. Sind die beiden denn am selben Host?
Hilft es, wenn du eins der Geräte an einem anderen Port betreibst?

Lars.

Eigentlich sind es verschiedene Hosts. Der Sundtek hängt am USB3 Port und der IR Empfänger an USB2. Ich habe aber auch verschiedene Ports Probiert ohne Erfolg.
Der nicht funktionierende USB IR Empfänger funktioniert sofort wenn ich ihn kurz abziehe und wieder anstecke.

Das ist schon interessant, ich weiß aber zu wenig über USB.
Kann man da debug-Meldungen vom USB-Subsystem ausgeben lassen? Vielleicht findet man dann einen Ansatz.

Lars.

Mit Debugging kenn ich mich zu wenig aus.

Die Logdateien zeigen leider gar nichts zu dem Thema. Normalerweise müsste der USB IR Empfänger funktionieren, zumindest sehen die System Informationen mit funktionierendem USB IR Empfänger genauso aus wie bei nicht funktionierendem.

Ich weiß da leider auch nichts.

Lars

Ich muss den Thread mal wieder aus der Versenkung holen. Hatte zwischenzeitlich schon jemand ne Idee, warum das mit dem aufwachen manchmal nicht klappt?

cu
Markus

Nein, leider nicht. Aktuell lege ich die devices nicht schlafen, um das Problem zu umgehen. Da Lars offensichtlich noch keine Zeit hatte sich nochmals mit diesem Thema zu beschäftigen, wollte ich auf einen aktualisierten Treiber warten. Vielleicht hat dieser ja auch einen Einfluss.

Habe nun das aktuelle media-build-experimental-dkms installiert. Leider keine Verbesserung in Bezug auf das Idle Problem. Das Aufwachen der devices ist nach wie vor Glückssache.

$ apt-cache policy media-build-experimental-dkms
media-build-experimental-dkms:
  Installiert: 0~20131204.221601-1yavdr1~precise
  Kandidat:	0~20131204.221601-1yavdr1~precise
  Versionstabelle:
 *** 0~20131204.221601-1yavdr1~precise 0
    	500 http://ppa.launchpad.net/yavdr/main/ubuntu/ precise/main amd64 Packages
    	100 /var/lib/dpkg/status

Ich greif das Thema für meine Zecke nochmals auf. Und zwar habe ich den gleichen Server wie Meikel allerdings nur mit einer Karte also 2 Tuner. Diese lassen sich über das Dynamite Plugin super schlafen legen, allerdings dauert das Aufwachen immer sehr lange ca 15-20 Sek. ist das normal? Desweiteren ist es komisch wenn ich ARD HD oder ZDF HD schauen benutz er immer Tuner 1 auf den anderen Sender meist Tuner 2. Das wäre nicht so tragisch aber wenn Tuner 1 schläft und ich auf ARD oder ZDF schalte dauert es immer ewig bis er da ist und das ist beim Zappen relativ nervig. Hab ich ne Idee wie ich entweder den Tuner schneller wach bekomme oder "verhindere" das der mit immer Auf Tuner 1 schaltet obwohl der andere Tuner ja theoretisch frei ist? Liegt das daran das der Server beim Start laut Live Plugin immer auf ARD getuned ist und der vllt den Tuner deshalb nimmt. Da der Server ja headless ist sollte der Server selbst ja eig am besten gar keinen Sender tunen oder?

LG Flo

Du kannst (und willst es eigentlich auch gar nicht) keine Device-Reihenfolge festlegen.
Ich würde eher mal das langsame Aufwachen untersuchen. Ob da wohl ein böses Plugin mit im Spiel ist? Ist es ohne evtl. schneller?
Was steht denn in dmesg, wenn ein Gerät aufgeweckt wird, wie schnell ist die Initialisierung?

Auf einem headless würde ich immer suspendoutput installieren, damit der vdr kein Live-Signal verarbeitet.

Lars

Okay danke, dann schau ich mir das mal an. Aktive sind Folgende Plugins: sc vdrmanager conflictcheckonly streamdev-server vnsiserver3 epgsearch wirbelscan xvdr quickepgsearch epgsearchonly live dynamite


Wenn morgen mal nicht geschaut wird deaktiviere ich mal alles ausser, xvdr und dynamite und schau mal ob sich was ändert.


Wie schau ich das nach mit dem dmesg? Was sollte ich da genau suchen?


Okay das Plugin suspendoutput installieren ich auf jedenfall mal.

Einfach dmesg aufrufen, da müssten Zeitstempel drin sein, anhand derer man dann sehen kann ob z.B. Eine Firmware geladen wird o.ä.. Es wird aber mit ziemlicher Sicherheit sc sein.

Lars

also an sc liegt es denke ich nicht habs grad mal raus gemommen und immer noch das gleiche Problem. Ich versuch jetzt mal alles ausser xvdr und dynamite aus zu machen und dann zu schauen. Bei dmesg finde ich nix, dass ist so vollgestopft hab keine Ahnung nach was ich da suchen sollte und en Zeitstempel gibts da ja auch net um zu schauen wie lange das laden dauert.

Dann steht's hoffentlich im syslog. Es sind auch nur die letzten Zeilen.

Lars

Also ich bekomm nicht wirklich raus was es ist, hab jetzt alles aus ausser vnsi und dynamite und das Problem ist immer noch da... Das Tunen Dauert ca. 10 Sek. Hier mal ein Auszug aus dem Systemlog:

Jan 4 19:30:59 NAS vdr: [9677] dynamite: device /dev/dvb/adapter1/frontend0 unused for 2 minutes, set to idle
Jan 4 19:30:59 NAS vdr: [9677] dynamite: set device /dev/dvb/adapter1/frontend0 to idle
Jan 4 19:31:00 NAS vdr: [9687] section handler thread ended (pid=9677, tid=9687)
Jan 4 19:31:00 NAS vdr: [9677] max. latency time 2 seconds
Jan 4 19:31:47 NAS vdr: [9688] loading /var/lib/vdr/plugins/vnsiserver3/allowed_hosts.conf
Jan 4 19:31:47 NAS vdr: [9688] VNSI: Client with ID 5 connected: 192.168.7.40:55503
Jan 4 19:31:47 NAS vdr: [9781] VNSI: Welcome client 'XBMC Media Center' with protocol version '3'
Jan 4 19:31:47 NAS vdr: [9783] section handler thread started (pid=9677, tid=9783, prio=low)
Jan 4 19:31:47 NAS vdr: [9781] VNSI: Successfully switched to channel 1 - Das Erste HD
Jan 4 19:31:47 NAS vdr: [9781] VNSI: Started streaming of channel Das Erste HD (timeout 10 seconds)
Jan 4 19:31:47 NAS vdr: [9786] cLiveStreamer stream processor thread started (pid=9677, tid=9786, prio=high)
Jan 4 19:31:47 NAS vdr: [9784] receiver on device 2 thread started (pid=9677, tid=9784, prio=high)
Jan 4 19:31:47 NAS vdr: [9787] TS buffer on device 2 thread started (pid=9677, tid=9787, prio=high)
Jan 4 19:31:52 NAS vdr: [9785] VNSI: VideoInput: no pat/pmt within timeout, falling back to channel pids
Jan 4 19:31:52 NAS vdr: [9785] VNSI: Video Input - new pmt, attaching receiver
Jan 4 19:31:56 NAS vdr: [9686] frontend 1/0 timed out while tuning to channel 1, tp 111493
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5101 and type=8
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5102 and type=2
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5103 and type=2
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5106 and type=1
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5105 and type=9
Jan 4 19:31:56 NAS vdr: [9786] VNSI: Created stream for pid=5104 and type=11
Jan 4 19:31:57 NAS vdr: [9688] VNSI: Requesting clients to reload channel list
Jan 4 19:32:01 vdr: last message repeated 3 times
Jan 4 19:32:01 NAS vdr: [9781] VNSI-Error: cxSocket::read: read() error at 0/4
Jan 4 19:32:01 NAS vdr: [9786] VNSI: exit streamer thread
Jan 4 19:32:01 NAS vdr: [9786] cLiveStreamer stream processor thread ended (pid=9677, tid=9786)
Jan 4 19:32:01 NAS vdr: [9787] TS buffer on device 2 thread ended (pid=9677, tid=9787)
Jan 4 19:32:01 NAS vdr: [9784] buffer stats: 177660 (3%) used
Jan 4 19:32:01 NAS vdr: [9784] receiver on device 2 thread ended (pid=9677, tid=9784)
Jan 4 19:32:01 NAS vdr: [9688] VNSI: Client with ID 5 seems to be disconnected, removing from client list

Es kann durchaus sein, dass es an vmsi/xvdr liegt. Mir war nicht bewusst, dass du xbmc als Frontend benutzt. Damit habe ich das nie getestet, immer nur mit softhddevice bzw. anderem vdr-Plugin. Da müsste man mal untersuchen, wie da die Aufrufe sind und wie ein Wakeup des Devices getriggert wird.
Mir fehlt da irgendwie eine Meldung von dynamite, die das "not idle" anzeigt, weiß jetzt aber aus dem Kopf auch nicht, ob da eine kommen soll.

Lars

Ich sehe gewisse Parallelen zwischen dem syslog Auszug von TXL und den von mir bereits geposteten Auszügen. Das frontend timed out, das Device wacht nicht auf. Dass im syslog keine Meldung "not idle" erscheint, hatten wir ja auch bereits recht breit getreten (da fängt die Story wieder hier an). Da es einige gibt, bei denen es zu laufen scheint, aber bei anderen nicht, muss es ja eine Ursache für das Problem geben.

mini73: Wenn Du noch eine Idee hast, will ich gerne nochmals etwas testen. Ich habe bislang auch noch keine Möglichkeit gefunden über den Treiber mehr debug Informationen zu erhalten. Vielleicht läuft ja auf Treiberseite noch etwas schief.

Ich hoffe, ich finde morgen mal Zeit...

Lars