Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Treiber => Thema gestartet von: hhbernd am März 10, 2013, 01:30:47 Vormittag
-
Hallo zusammen,
mein erster Post hier im Forum und ich hoffe, Ihr könnt mir helfen.
Ich habe eine Zotac Zbox ID41 mit XMBCbuntu 12.10 aufgesetzt. Als Backend verwende TVHeadend und als TV-Stick den Suntek MediaTV Digital Home (DVB-C/T).
Bislang hatte ich probeweise einen WinTV-Stick DVB-T am laufen und alles funktionierte ohne Probleme.
Mein XBMCbuntu ging in den Standby-Modus und nach dem Aufwachen wurde im TVHeadend Webinterface der TV-Adapter erkannt und XBMC konnte auch alle Kanäle finden.
Jetzt mit dem MediaTV Digital Home (DVB-C/T) wird nach dem Aufwachen der Adapter nicht mehr erkannt. Nach einem Reboot klappt alles wieder wie gewohnt.
Ich habe das Gefühl, dass der Suntek-Treiber nach dem Aufwachen aus dem Standby nicht erkannt wird.
Ich habe den Treiber nochmals über Netinstall nachinstalliert - ohne Erfolg.
Möchte gerne die Standby-Funktion nutzen und nicht jedes Mal wieder neu booten.
Weiss jemand Rat ?
Vielen Dank im Voraus.
-
Ist wohl das uebliche Problem das tvheadend wohl gestartet wird bevor der Stick vollkommen initialisiert wurde.
Es gibt ein Feature im Treiber, damit kann man Applikationen ausfuehren sobald das Device dem System zur Verfuegung steht.
/etc/sundtek.conf
device_attach=/etc/init.d/tvheadend restart
oder
device_attach=service tvheadend restart
je nachdem wie bei Deinem System tvheadend neu gestartet wird.
-
SUPER - hat geklappt. Das war ja einfach.
Vielen Dank für die schnelle und kompetente Hilfe.
-
Hm,
ich habe ein ganz ähnliches Problem. Auch ich benutze tvheadend zusammen mit einem Sundtek DVB-C stick. Allerdings habe ich auf meinem System bereits eine sundtek.conf Datei mit dem Inhalt
device_attach=/etc/init.d/tvheadend restart
Ohne das File funktioniert auch tvheadend nach einem Neustart nicht.
Setze ich mein System mit einem sudo pm-suspend in den Schlafmodus so findet tvheadend (meistens) den Stick nicht mehr. Selten klappt es noch 1x. Ebenso liefert mediaclient -e keine devices mehr.
System
uname -a
Linux xbmc 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 12.04
mediasrv --build
Build date: 2013-03-15 22:57:47
Rechner Zotac ad10
Hat jemand ne Idee?
Gruß
digi_joe
Edit: Hab mal noch ein bisschen experimentiert.
Wenn ich vom file sundtek.conf ein Skript mit dem Inhalt
#!/bin/bash
sleep 5
/etc/init.d/tvheadend restart
sleep 5
aufrufe klappt es zumindest 1x (Habs grad 3x probiert). Beim 2. mal geht es aber immer noch net :-\...
-
Es wird wohl in wenigen Tagen das nächste Update kommen, wir werden bis dahin das PM Skript von Suse überprüfen.
Leider gab es bei uns ein ernsthaftes Problem mit dem Entwicklungsrechner sowie (wie Murphy's Law es so schön voraussagt) dem Backupsystem. Soweit sind jedoch nach einer Woche nun die wichtigsten Daten wieder hergestellt.
-
Wird sich diese Änderung dann auch positiv auf ubuntu auswirken? Habe ja eigentlich kein Suse sondern ubuntu 12.04 LTS.
-
Also Ubuntu wurde getestet und funktioniert, der Treiber wird vor dem Standby heruntergefahren und nach dem Standby neu gestartet und sollte mit /opt/bin/mediaclient -e neu angezeigt werden.
-
Bei mir eben nicht ??? (Siehe mein Post vom 7. April). Ich weiss ja, dass standby immer ein bisschen fummelig ist. Aber irgendwie weiss ich inzwischen eben nicht mehr weiter...
-
Habe es erneut auf Ubuntu getestet und es läuft wie immer.
Standby ist überhaupt kein fummeliges Thema, es ist ganz klar gelöst. Der Treiber wird vor dem Herunterfahren/Standby gestoppt und beim Resume wieder neu gestartet.
- vor dem Standby -
9552 pts/6 S+ 0:00 \_ grep --color=auto mediasrv
9166 ? Sl 0:00 /opt/bin/mediasrv -d --pluginpath=/opt/bin
9168 ? S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
- nach dem Standby, hier hat sich die ProzessID geändert da der Prozess neu gestartet wurde -
root@UL80VT:~# ps fax | grep mediasrv
10211 pts/6 S+ 0:00 \_ grep --color=auto mediasrv
9950 ? Sl 0:00 /opt/bin/mediasrv -d --pluginpath=/opt/bin
9951 ? S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
root@UL80VT:~# /opt/bin/mediaclient -e
**** List of Media Hardware Devices ****
device 0: [Sundtek MediaTV Digital Home (USB 2.0)] DVB-C, DVB-T, REMOTE-CONTROL
[BUS]:
ID: 2-5
[SERIAL]:
ID: 0110202071512
[DVB-C]:
FRONTEND: /dev/dvb/adapter0/frontend0
DVR: /dev/dvb/adapter0/dvr0
DMX: /dev/dvb/adapter0/demux0
[DVB-T]:
FRONTEND: /dev/dvb/adapter0/frontend0
DVR: /dev/dvb/adapter0/dvr0
DMX: /dev/dvb/adapter0/demux0
[REMOTECONTROL]:
INPUT0: /dev/mediainput0
Dieser Vorgang wird von den pm-utils gesteuert, das Skript liegt in /usr/lib/pm-utils/sleep.d/ und heißt 10mediasrv.
Tvheadend muss nachdem der Adapter neu gefunden wurde danach neu gestartet werden, dies lässt sich über die sundtek.conf Konfiguration erledigen.
/etc/sundtek.conf
device_attach=service tvheadend restart
Dieser Befehl wird nur dann ausgeführt wenn der Adapter vollständig initialisiert wurde.
Solange sich das Problem, wie ihr es beschreibt, nicht nachvollziehen können, können wir daran auch nichts ändern.
-
Hier auch mittels tvheadend:
Vor dem Standby:
root@UL80VT:~# /opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
11197 ... tvheadend
/dev/dvb/adapter0/dvr0:
No client connected
/dev/dvb/adapter0/demux0:
No client connected
/dev/mediainput0:
No client connected
root@UL80VT:~# ps fax | grep mediasrv
11218 pts/8 S+ 0:00 \_ grep --color=auto mediasrv
9950 ? Sl 0:00 /opt/bin/mediasrv -d --pluginpath=/opt/bin
9951 ? S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
Nach dem Standby:
root@UL80VT:~# ps fax | grep mediasrv
11982 pts/8 S+ 0:00 \_ grep --color=auto mediasrv
11714 ? Sl 0:00 /opt/bin/mediasrv -d --pluginpath=/opt/bin
11721 ? S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
root@UL80VT:~# /opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
11923 ... tvheadend
/dev/dvb/adapter0/dvr0:
No client connected
/dev/dvb/adapter0/demux0:
No client connected
/dev/mediainput0:
No client connected
Nach dem Standby wurden der Treiber und tvheadend automatisch neu gestartet.
-
Hm habt ihr auch einen client mal vor dem Standby zum TvHeadend connecten lassen. Bei mir macht auch das einen Unterschied. Habt ihr es auch mal 2-3x hintereinander ausprobiert (jeweils mit einem client connect).
In meinem System läuft der TvHeadend Server und der client auf dem gleichen Rechner.
All dies scheint bei mir einen Einfluss zu haben....
Wenn ich das bei mir richtig überblicke ist die Config bei mit gleich wie bei Euch...
Manchmal klappt es ja auch. Aber eben nicht immer :(. Und das sind bekanntlich die schwierigsten Fehler.
Off-Topic:
Wie dem auch sei: Ich bin wirklich sehr zufrieden mit Eurem Produkt. Habe es gerade erst am Pi mit TVheadend zum laufen gebracht. Leider ist der Pi etwas schwachbrüstig für HD...
Hab grad noch mal gekuckt bei mir sieht die Ausgabe nach dem Hochfahren so aus
/opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
2142 ... tvheadend
/dev/dvb/adapter0/dvr0:
2142 ... tvheadend
/dev/dvb/adapter0/demux0:
2142 ... tvheadend (2000)
/dev/mediainput0:
No client connected
Ist das der Grund? Nutze Tvheadend 3.3.491~g6990005~precise
Hab grad noch mal den Fehlerfall durchgespielt
/opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
2142 ... tvheadend
/dev/dvb/adapter0/dvr0:
2142 ... tvheadend
/dev/dvb/adapter0/demux0:
2142 ... tvheadend (2000)
/dev/mediainput0:
No client connected
ps fax | grep mediasrv
2202 pts/0 S+ 0:00 \_ grep --color=auto mediasrv
1542 ? Sl 0:01 /opt/bin/mediasrv -d --pluginpath=/opt/bin
1543 ? S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
/opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
2153 ... tvheadend
/dev/dvb/adapter0/dvr0:
2153 ... tvheadend
/dev/dvb/adapter0/demux0:
2153 ... tvheadend (2000)
/dev/mediainput0:
No client connected
sudo pm-suspend
Nach Standby
3036 pts/0 S+ 0:00 \_ grep --color=auto mediasrv
2743 pts/0 Sl 0:00 /opt/bin/mediasrv -d --pluginpath=/opt/bin
2746 pts/0 S 0:00 \_ /opt/bin/mediasrv -d --pluginpath=/opt/bin
/opt/bin/mediaclient --lc
**** List of Media Clients ****
Nix :-(
-
Melde dich eventuell mal via Skype (sundtek).
Dieser Mechanismus funktioniert bei uns zuverlässig, es scheint eher so zu sein als ob ein anderes Gerät/Treiber bei dir eventuell den USB Stack crashen lässt (unser Treiber kann das nicht da dieser ja nur eine Applikation ist).
Es wird hier zwar jetzt Ubuntu 12.10 verwendet aber an diesem Mechanismus hat sich auch schon sehr lange nichts mehr geändert.
Man kann hier wohl nur die Logfiles überprüfen und sich den Status des Sticks ansehen.
Der Treiber versucht alle möglichen Wege das Gerät nach dem Start zu erkennen (10 Sekunden parsen der Device Nodes nach dem Start ob sich etwas verändert hat und das abhören der udev Messages ob der Stick registriert wurde)
Es gibt soweit also keine Möglichkeit das Gerät zufälligerweise nicht zu finden.
-
So langsam komme ich dem Problem auf die Spur. Der Hinweis mit dem anderen USB Device war net schlecht...
Also habe ich mal alle anderen usb devices abgesteckt und siehe da es ging. Dann wieder alle angesteckt und es ging immer noch ??? komisch!!!
Doch dann ging mir ein Licht auf. Bei meinen vorigen Tests habe ich den Zotac immer per Fernbedienung (wird mitgeliefert) und externem USB Receiver aufgeweckt. Jetzt habe ich immer den Einschalter am Zotac genutzt. Noch mal mit der Fernbedienung getestet und siehe das da Sundtek Stick wird nicht mehr gefunden.
Fazit: Aufwecken mit dem Einschalter geht mit der Fernbedienung dagegen nicht.
Wer ist da jetzt schuld. Der Sundtek Treiber oder der USB IR Empfänger... Eigentlich ja auch egal. Hat jemand vielleicht eine Idee.u
Edit: Habe mal in die sundtek.conf ir_disable = 1 eingefügt. Dachte vielleicht beeinflusst die Fernbedienung ja den Stick. Geht leider immer noch nicht.
-
Wenn du den Stick mittels /opt/bin/mediaclient -e nach dem Aufwecken nicht siehst dann hängt etwas bei der USB Stack Device Enumeration. Das ist schon sehr low level, der Treiber wird an dieser Stelle nicht mal mehr erreicht - also auch theoretisch würde hier kein Update helfen.
Folglich kann es sein das irgendein anderes Device während der Enumeration (der Durchnummerierung aller USB Geräte) hängen bleibt.
Eventuell gibt dmesg weitere Informationen aus.
Vielleicht lässt es sich auch mit einem aktiven USB Hub lösen.
-
Aber warum hängt das ganze davon ab ob ich den Rechner mittels Power Button oder Fernbedienung aufwecke. Wie soll da ein Aktive Hub helfen? ???
Resultat nach Aufwecken mittels Fernbedienung
mediaclient -e
**** List of Media Hardware Devices ****
nix...
-
Na gib mal "dmesg" ein nach dem Starten und "lsusb".
-
Also wenn ich mit der Fernbedienung neu starte bekomme ich als Ausgabe in dmesg
[ 241.516302] INFO: task mediasrv:2796 blocked for more than 120 seconds.
[ 241.516317] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 241.516326] mediasrv D 0000000000000001 0 2796 1 0x00000000
[ 241.516342] ffff880143551b68 0000000000000082 0000000000000268 ffff88014effbe00
[ 241.516357] ffff880143551fd8 ffff880143551fd8 ffff880143551fd8 00000000000137c0
[ 241.516370] ffff88014799dc00 ffff88014799c500 ffff880143551b58 7fffffffffffffff
[ 241.516383] Call Trace:
[ 241.516409] [<ffffffff8165c58f>] schedule+0x3f/0x60
[ 241.516421] [<ffffffff8165cbd5>] schedule_timeout+0x2a5/0x320
[ 241.516437] [<ffffffff814abd16>] ? ehci_qtd_alloc.isra.76+0x16/0x110
[ 241.516449] [<ffffffff8165e49e>] ? _raw_spin_lock+0xe/0x20
[ 241.516462] [<ffffffff81494a5c>] ? usb_hcd_link_urb_to_ep+0x8c/0xc0
[ 241.516473] [<ffffffff8165c3cf>] wait_for_common+0xdf/0x180
[ 241.516487] [<ffffffff81060640>] ? try_to_wake_up+0x200/0x200
[ 241.516498] [<ffffffff8165c523>] wait_for_completion_timeout+0x13/0x20
[ 241.516509] [<ffffffff81498501>] usb_start_wait_urb+0x81/0xf0
[ 241.516520] [<ffffffff81497525>] ? usb_init_urb+0x55/0xf0
[ 241.516530] [<ffffffff814987f6>] usb_control_msg+0xe6/0x120
[ 241.516542] [<ffffffff814a196c>] proc_control+0x2fc/0x3a0
[ 241.516552] [<ffffffff814a3045>] usbdev_do_ioctl+0x815/0xc90
[ 241.516562] [<ffffffff8165e49e>] ? _raw_spin_lock+0xe/0x20
[ 241.516575] [<ffffffff8119715e>] ? vfsmount_lock_local_unlock+0x1e/0x30
[ 241.516587] [<ffffffff81198f70>] ? mntput_no_expire+0x30/0xf0
[ 241.516597] [<ffffffff814a34ee>] usbdev_ioctl+0xe/0x20
[ 241.516609] [<ffffffff8118ba9a>] do_vfs_ioctl+0x8a/0x340
[ 241.516619] [<ffffffff8118bde1>] sys_ioctl+0x91/0xa0
[ 241.516631] [<ffffffff81666a82>] system_call_fastpath+0x16/0x1b
Reicht das?
lsusb ergibt:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID eb1a:51b2 eMPIA Technology, Inc.
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 005 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 009 Device 002: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3
Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 0471:20cc Philips (or NXP)
Nach einem Neustart bekomme ich
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID eb1a:51b2 eMPIA Technology, Inc.
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 005 Device 002: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 009 Device 002: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3
Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 0471:20cc Philips (or NXP)
-
Also hierbei handelt es sich eindeutig um einen Kernelbug.
Als einen Workaround kannst du folgendes versuchen, einen USB Reset absetzen, dann wird das Geraet erneut am Controller registriert und der Controller sollte dann auch in einem 'frischen' Zustand sein sofern das ueberhaupt klappt:
Folgendes in der Suspend/Resume Datei (/usr/lib/pm-utils/sleep.d/10mediasrv ) oberhalb von mediaclient --start hinzufuegen
/opt/bin/mediaclient --reset `/opt/bin/mediaclient --lsusb | grep eb1a | awk '{ print $1 }'`
Als zweiten Versuch kannst du den Start eventuell auch versuchen hinauszuzögern, mit mediaclient --start=N (N=Sekunden) versuche das mit dem Timeout eventuell zuerst, nimm einfach mal 5 Sekunden
-
Habe beide Änderungen mal gemacht zuerst das mit dem Delay (hat nicht geklappt) dann beide.
Jetzt bekomme ich auf lsusb nach einem Suspend mit anschliessendem Neustart
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 005 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 009 Device 002: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3
Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 0471:20cc Philips (or NXP)
Ich denke das fehlt jetzt der Stick...
Und auf dmesg am Ende
[ 62.516189] usb 1-1: device firmware changed
[ 62.516954] usb 1-1: USB disconnect, device number 2
[ 62.628095] usb 1-1: new high-speed USB device number 6 using ehci_hcd
[ 62.764361] usb 1-1: device descriptor read/64, error -71
[ 63.004119] usb 1-1: device descriptor read/64, error -71
[ 63.221891] usb 1-1: new high-speed USB device number 7 using ehci_hcd
[ 63.356112] usb 1-1: device descriptor read/64, error -71
[ 63.596092] usb 1-1: device descriptor read/64, error -71
[ 63.812082] usb 1-1: new high-speed USB device number 8 using ehci_hcd
[ 64.236073] usb 1-1: device not accepting address 8, error -71
[ 64.348164] usb 1-1: new high-speed USB device number 9 using ehci_hcd
[ 64.772104] usb 1-1: device not accepting address 9, error -71
[ 64.772141] hub 1-0:1.0: unable to enumerate USB device on port 1
[ 65.112125] usb 4-1: new full-speed USB device number 2 using ohci_hcd
[ 65.256076] usb 4-1: device descriptor read/64, error -62
[ 65.500150] usb 4-1: device descriptor read/64, error -62
[ 65.740152] usb 4-1: new full-speed USB device number 3 using ohci_hcd
[ 65.880159] usb 4-1: device descriptor read/64, error -62
[ 66.128167] usb 4-1: device descriptor read/64, error -62
[ 66.372117] usb 4-1: new full-speed USB device number 4 using ohci_hcd
[ 66.780129] usb 4-1: device not accepting address 4, error -62
[ 66.920154] usb 4-1: new full-speed USB device number 5 using ohci_hcd
[ 67.328137] usb 4-1: device not accepting address 5, error -62
[ 67.328220] hub 4-0:1.0: unable to enumerate USB device on port 1
mediaclient -e gibt leere Liste
Mit der Power Taste aufwachen geht weiterhin.
P.S.: Nur Interesse halber. Wieso schließt du auf einen Kernel Bug?
-
[ 241.516487] [<ffffffff81060640>] ? try_to_wake_up+0x200/0x200
Das ist auf einer unteren USB Controller Schicht, versuche mal die Kernelversion zu wechseln (bei Ubuntu ohnehin nicht so schwierig).
Vom Treiber her haben wir darauf keinen Einfluss. Egal was von uns geschickt wird das Wakeup vom Controller Treiber bleibt anscheinend haengen bzw. timed aus und verwirft die Anfrage.
Eventuell gibt's bei dir im BIOS USB Einstellungen? (enhanced / compatible?)
-
Versuche mal das (und mache die anderen Aenderungen rueckgaengig):
echo 0 > /sys/power/pm_async
Eine weitere Möglichkeit, ir_disabled=1 in /etc/sundtek.conf dann werden vor dem Standby weniger Anfragen ueber den USB Controller geschickt.
Das ist alles sehr spezifisch entweder fuer den USB Controller Treiber bzw. Dein System.
-
echo 0 > /sys/power/pm_async
Wo soll ich das hinzufügen. Das ir_disable habe ich schon gestern hinzugefügt...
-
Auf der Shell als Administrator/root ausfuehren.
-
sudo echo 0 > /sys/power/pm_async
-bash: /sys/power/pm_async: Keine Berechtigung
ebenso ohne sudo
echo 0 | sudo tee /sys/power/pm_async geht hilft aber auch nicht....
-
sudo -s
echo 0 > /sys/power/pm_async
-
Wiegesagt wenn das nicht klappt Kernelversion wechseln, es gab so einige USB Patches in der 3.x Serie welche das Ganze beeinflussen können.
Eventuell auch Ubuntu 12.10 verwenden.
Vielleicht kannst du Testweise den Treiber vor dem Standby stoppen "chmod 0 /opt/bin/mediasrv"
Nach dem Standby, nach 10 Sekunden "chmod 744 /opt/bin/mediasrv" (alles jeweils nach "sudo -s") und danach den Treiber manuell starten "/opt/bin/mediaclient --start"
-
Hast du den Stick schon mal an dem Genesys Logic 4Port Hub angeschlossen?
-
Ich denke ich mach mal schluss für heut. Um das Bios zu checken muss ich erst mal ein keyboard anschliessen.
Bezüglich kernel kann man ja einfach auf den kernel 3.5 mittels
sudo apt-get install linux-image-generic-lts-quantal
kommen. Vielleicht hilft das ja. Will mir jetzt aber nicht mitten in der Nacht noch das System zerschiessen...
-
Hast du den Stick schon mal an dem Genesys Logic 4Port Hub angeschlossen?
Nein. Das hätte ich auch schon geändert. An dem hängen nur der IR Empfänger und der Logitech Keyboard dongle.
Der Sundtek stick hängt direkt an einem USB 2.0 port des PC. Am USB 3.0 hängt eine externe 2.5 Zoll USB 3.0 Platte.
P.S.: Echt klasse wie du dich in mein Problem reinhängst... Das habe ich bisher noch nirgends erlebt.
-
haette oder hatte? Tausche mal den IR Empfaenger mit dem USB Stick.
Wird langsam spaet hier und somit Schluss fuer heute.
-
haette oder hatte? Tausche mal den IR Empfaenger mit dem USB Stick.
Wird langsam spaet hier und somit Schluss fuer heute.
So nach dem Fussballspiel konnte ich noch mal ein bisschen testen.
Dieser Tipp hat den Erfolg gebracht. Jetzt klappt es auch mit der Fernbedienung. Nun hängt der IR Empfänger direkt am USB und der DVB Stick zusammen mit dem Tastatur dongle am HUB...
Habe es gerade 10x hintereinander erfolgreich getestet. :)
Vielen Dank nochmal.
-
So...
Zur Info:
hab jetzt noch mittels
sudo apt-get install linux-image-generic-lts-quantal auf den 3.5er Kernel upgedatet. Jetzt kann ich wieder die default Skripte (ohne sleep oder ähnliches) verwenden. Auch scheint das ganze nun stabil zu laufen.
Also auch der Hinweis mit dem neueren Kernel war absolut richtig... :)
-
Na ich denke eher dass das Umstecken Dein Problem gelöst hat?
Das mit dem sleep war ja nur ein "Test".
-
Beides. Ich brauchte den sleep vor allem beim stoppen/neustarten des Grafikkartentreibers. Ohne den ging der Rechner gar nicht in den Standby. Auch hatte ich mit dem alten Kernel immer mal wieder das Problem (selbst nach dem Umstecken), dass der Graka Treiber nicht mehr richtig startete (kein Bild). Das ist jetzt vorbei. Wenn ich mal wieder an den htpc komme (aktuell wird gerade Germany's .... gekuckt ;) ) werde ich die usb devices noch mal durchtauschen ob der Platz auch mit dem neuen Kernel noch eine Auswirkung hat.
Ich gebe dann noch mal Feedback. Vielleicht hilft es ja dem einen oder anderen.