Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Treiber => Thema gestartet von: Sundtek am Januar 23, 2010, 12:31:54 Vormittag
-
Version: http://www.sundtek.de/support/empia_installer_100125.sh
* Option hinzugefuegt um den CRC Check fuer DVB auszuschalten 1)
* Option hinzugefuegt um Logging auszuschalten 2)
* Numerierung der Devicenodes fuer mehrere angeschlossene Sundtek Geraete wurde nachgebessert
* DVB PSI Filtermaske korrigiert, dies wird besonders von VDR benutzt und hatte ab 1.7.9 Probleme mit EPG bereitet
* mediaclient -e, API Aenderung (net_device_enum) um USB-CI bzw CAM Module darzustellen
* Viele weitere interne Updates welche beim naechsten Update erlaeutert werden und Auswirkungen haben werden
Hotfixes:
* Installer ueberprueft libc Systemvoraussetzungen (2010-01-25)
* 32bit/libc2.3 Treiber hinzugefuegt (z.B.: fuer easyVDR) (2010-01-25)
1)
on .. CRC weiter nach Aufforderung der Applikation durchfuehren (default)
off .. CRC Check ausschalten
/opt/bin/mediaclient --crc=[on|off]
2)
off .. logging ausschalten
min .. minimales logging
max .. maximales logging (min/max haben zZ. den gleichen Effekt)
/opt/bin/mediaclient --loglevel=[off|min|max]
-
Nach dem ersten Test sieht das bei mir sehr gut aus: sowohl mit QAM64- als auch QAM256-Sendern Top-Bild, obwohl sich an der Signalstärke nichts geändert hat. Dabei habe ich auch den CRC-Check nicht deaktiviert, sondern nutze die Default-Einstellungen. Gute Arbeit!
-
Das einzige was sich geaendert hat waren die oben angegebenen Punkte. Es gab keine versteckten Verbesserungen bei DVB. Eventuell hat die Filtermaske bei Ihnen etwas verbessert.
-
Hallo,
mit der neuen Version gibt es hier keine EPG-Probleme mehr.
Der Betrieb mit 2 Eurer Sticks ist etwas besser, als mit der Beta-Version aus dieser Woche. Leider haengt sich das OSD bei wechseln von Kanaelen sehr schnell auf. Z.B.
2 Aufnahmen von 2 verschieden Anbietern (ARD/Pro7) und wechseln von ARD auf Pro7 oder SAT1
1 Aufnahme (ARD) und wechsel auf Pro 7
Aufruf Plugin Gerätestatus
....
Im Plugin Signalinformation gibt es !!!3!!! Suntek Devices (war mit der Beta-Version auch schon so): DVB-C #1, C #2 und DVB-C #8???? Wenn auf 8 umgeschaltet wird, hängt das OSD und nur ein reboot hilft. Mit der Version vom 09.11.09 gab es nach meiner Erinnerung nur #0 und #1. Auch sonst hilft nur ein Reboot. Auch bei gestopptem vdr laueft das Bild weiter und der vdr laesst sich nicht neu starten.
cu
Hergorn
vdr 1.7.9 vpau xineliboutout - asrock 330 Pro (ION) 2x Sundtek Media DVB-C Lirc per USB-Lirc-Empfänger
-
Die Plugins und Aufnahmen mit 2 Geraeten werden naechste Woche umgehend ueberprueft. Die derzeitigen Tests mit 2 USB Adaptern waren leider eher rudimentaer. Dies sollte aber auch kein allzugrosses Problem darstellen.
-
Hallo,
habe versucht die Treiber zu installieren - danach ist kein Reboot mehr möglich: "Kernel Panic".
Installation im frisch installierten "easyVDR"
http://ftp.gwdg.de/pub/linux/easyvdr/beta/07/easyvdr-0.7.14-k2.6.28.9-HD-Edition.iso
auf Zotac ION ITX A (Atom) Mainboard.
Bildschirmausgabe beim Installieren: siehe unten.
Danach kann man das System nicht mehr booten: Kernel Panic und "GLIBC_2.4"-Fehlermeldung wie unten.
Was mache ich falsch?
Danke im Voraus.
easyVDR:/tmp# sudo sh ./empia_installer_100123.sh
Welcome to the EETI em28xx linux driver setup
Legal notice:
This software comes without any warranty, use it at your own risk
Do you want to continue [Y/N]:
Nutzungsbedingungen:
Sundtek übernimmt keinerlei Haftung für Schäden welche eventuell durch
das System oder die angebotenen Dateien entstehen können.
Wollen Sie fortfahren [J/N]:
j
adding /opt/bin to environment paths
adding administrator to audio group for playback...
installing em28xx driver to /opt
unpacking...
checking system... 32Bit System detected
installing...
finalizing configuration... (can take a few seconds)
chmod: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/lib/libmediaclient.so)
rm: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/lib/libmediaclient.so)
Starting driver...
/opt/bin/udevsrv: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/bin/udevsrv)
/opt/bin/udevsrv: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/lib/libmediaclient.so)
sleep: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/lib/libmediaclient.so)
rm: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /opt/lib/libmediaclient.so)
done.
easyVDR:/tmp#
-
Das einzige was sich geaendert hat waren die oben angegebenen Punkte. Es gab keine versteckten Verbesserungen bei DVB. Eventuell hat die Filtermaske bei Ihnen etwas verbessert.
Wahrscheinlich. Habe inwischen auch einen einzigen QAM256-Sender ohne Verschlüsselung entdeckt. Dieser funktioniert auch schon mit der alten Treiberversion. Die Probleme gab es also wohl im Zusammenspiel mit dem entsprechenden VDR-Plugin.
Sind im ARM-Treiber auch alle Änderungen drin? Da hat sich nämlich leider nichts verbessert...
-
Hallo,
habe versucht die Treiber zu installieren - danach ist kein Reboot mehr möglich: "Kernel Panic".
Installation im frisch installierten "easyVDR"
http://ftp.gwdg.de/pub/linux/easyvdr/beta/07/easyvdr-0.7.14-k2.6.28.9-HD-Edition.iso
auf Zotac ION ITX A (Atom) Mainboard.
EasyVDR ist eine merkwuerdige Distribution, libc ist aelter als 4 Jahre (Linux 2.6.15 ist auch ca. 4 Jahre alt), wobei alles andere etwas neuer zu sein scheint. Wir werden hierfuer umgehend einen Check einbauen. Fuer EasyVDR koennen wir lediglich ein eigenes Treiberpaket bereitstellen (fuer libc<2.4) In so einem Fall kann man mit einer Bootcd hochfahren und /etc/ld.so.preload entfernen. Ein kerneloops sollte jedoch dennoch nicht passieren, das zeigt das es hierbei noch andere Probleme mit dieser Distribution gibt.
-
Wahrscheinlich. Habe inwischen auch einen einzigen QAM256-Sender ohne Verschlüsselung entdeckt. Dieser funktioniert auch schon mit der alten Treiberversion. Die Probleme gab es also wohl im Zusammenspiel mit dem entsprechenden VDR-Plugin.
Sind im ARM-Treiber auch alle Änderungen drin? Da hat sich nämlich leider nichts verbessert...
Es sollten alle Treiber das selbe Build Datum haben, auch wurden alle vom gleichen Source gebaut.
/opt/bin/mediaclient --build
Build date: Jan 23 2010
/opt/bin/mediasrv --build
Build date: Jan 23 2010
Koennen Sie /var/log/mediasrv.log bereitstellen? Falls es zu Performance Problemen kommt, koennen Sie folgenden Patch auf ARM ausprobieren (dieser Patch ist bereits Bestandteil neuerer Linuxversionen):
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.31/usb-increase-usbdevfs-max-isoc-buffer-size.patch
-
Es sollten alle Treiber das selbe Build Datum haben, auch wurden alle vom gleichen Source gebaut.
Schade, dann ist das doch noch etwas anderes...
/opt/bin/mediaclient --build
Build date: Jan 23 2010
/opt/bin/mediasrv --build
Build date: Jan 23 2010
Das sieht bei mir auch so aus.
Koennen Sie /var/log/mediasrv.log bereitstellen?
Im Folgenden habe ich das mit verschiedenen empfangenen Sendern mal zusammengestellt:
Nach dem Start:
Starting up Multimedia Framework (Jan 23 2010 04:59:51)
Detected DVB version.h
API Version: 5.0
Running on Linux (2.6.32-flatty-ocf-1)
scanning devices
scanning for plugins
disconnecting kernel driver
attaching Videodecoder
attaching DVB-T, DVB-C
demodulator successfully attached (DVB_C)!
requesting to attach tuner(s) now
registering: adapter0
registered virtual: /dev/dvb/adapter0/frontend0
registered virtual: /dev/dvb/adapter0/demux0
registered virtual: /dev/dvb/adapter0/dvr0
registered virtual: /dev/video0
registered virtual: /dev/radio0
registered virtual: /dev/rds0
registered virtual: /dev/vbi0
registered virtual: /dev/mediainput0
Registering OSS emulation
registered virtual: /dev/dsp0
Sundtek MediaTV Driver loaded. This driver is licensed for non-commercial use
with Sundtek MediaTV only
Contact: kontakt@sundtek.de
scanning devices done
attached devices:
0 .. Sundtek MediaTV Pro
attached devices:
0 .. Sundtek MediaTV Pro
RC: IR Event /dev/input/event0
Nach dem Start des VDR, Sender "Das Erste" (QAM64, unverschlüsselt, Bild okay):
Channel found (410000000)
=============
Symbol rate: 6899795
Constellation: QAM64
Mirroring: Normal
Das wird mit leicht veränderter Symbolrate immer wiederholt.
Nach dem Umschalten auf "France24" (QAM256, unverschlüsselt, Bild okay):
Channel found (338000000)
=============
Symbol rate: 6899964
Constellation: QAM256
Mirroring: Mirrored
Auch das wird immer wiederholt. Was bedeutet eigentlich das Mirroring?
Nach dem Umschalten auf "RTL" (QAM256, CONAX, starke Artefakte):
Channel found (330000000)
=============
Symbol rate: 6899940
Constellation: QAM256
Mirroring: Mirrored
CRC invalid of requested section (0001 01)
CRC invalid of requested section (0001 01)
Nach "mediaclient --crc=off" fehlt dann "CRC invalid of requested section (0001 01)", das Bild wird aber nicht besser.
Falls es zu Performance Problemen kommt, koennen Sie folgenden Patch auf ARM ausprobieren (dieser Patch ist bereits Bestandteil neuerer Linuxversionen):
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.31/usb-increase-usbdevfs-max-isoc-buffer-size.patch
Der Patch ist bei mir schon drin (Kernel 2.6.32).
-
Auch das wird immer wiederholt. Was bedeutet eigentlich das Mirroring?
Dies zeigt lediglich die Information an ob das Senderspektrum gespiegelt ist oder nicht.
Das wiederholen wird dadurch verursacht das VDR wiederholt versucht den Kanalstatus auszulesen (was auch in Ordnung ist).
Das ganze zeigt das ihr Signal sehr grenzwertig zu sein scheint, besteht die Moeglichkeit Ihre Leitung von Telecolumbus ausmessen zu lassen?
In sehr seltenen Faellen (von 200 Stueck sind eventuell 2-3 Geraete idR. nicht in Ordnung) aber das 2 Geraete nebeneinander das gleiche anzeigen und dies dann nicht zutrifft waere hoechst unwarscheinlich.
QAM256 funktioniert ansonsten auch bei praktisch allen Kunden, und auch mit 100% Signalqualitaet (ansonsten wuerde es hier auch sehr viel mehr Anfragen diesbezueglich geben).
Zusaetzlich koennen Sie das Windows Testtool auch verwenden um die Signalqualitaet im Windows mit dem anderen Treiber zu ueberpruefen.
-
Das ganze zeigt das ihr Signal sehr grenzwertig zu sein scheint, besteht die Moeglichkeit Ihre Leitung von Telecolumbus ausmessen zu lassen?
Sicher, wenn es dann aber in Ordnung ist, kostet es sicher nicht zuwenig Geld...
Komischerweise ist ja das Bild nun auf x86-Hardware mit dem aktuellen Treiber völlig in Ordnung.
Ich denke mal, wir suchen da in die falsche Richtung. Nach weiteren Tests sieht es nun so aus, daß ohne das gewisse VDR-Plugin keine CRC-Fehler auftreten. Natürlich habe ich dann gar kein Bild ;)
Komisch ist nur, wie ein VDR-Plugin dazu führen kann, daß im Treiber CRC-Fehler auftreten. Die CPU-Last liegt um die 50%.
-
40% Signalqualitaet ist auf jeden Fall grenzwertig. ARM wurde bereits getestet ebenfalls mit QAM256, die Signalstaerke wird nicht beeinflusst von VDR.
Es wird demnaechst auch eine Applikation geben mit der man die verschiedenen Bit Error Ratios auslesen kann (das Geraet unterstuetzt 3 verschiedene BER Werte welche derzeit programmtechnisch nur ueber einen eigenen Befehl ausgelesen werden koennen).
Die CRC Fehler kommen daher das VDR besonders viele Nodes aufmacht und jeder Node fuer sich selber einen CRC Check macht. Hierbei kann natuerlich auch hinzukommen falls IO auf dem Rechner zu langsam ist IO ebenfalls zusaetzlich Last verursacht. Ueber Videodaten kann kein CRC Check gemacht werden, lediglich ueber PSI Daten wie EPG/EIT(Kanalinformationen)/etc (dies ist laut DVB/MPEG Spezifikationen festgelegt)
Wie schon erwaehnt QAM256 funktioniert bei praktisch jedem auch mit 100% Signalqualitaet, eventuell koennen Sie das Geraet auch bei Freunden testen?
Dies ist absolut der einzige Fall in dem es so gravierende Probleme mit einigen QAM256 Sendern gibt, wobei wir aber auch die 40% Signalqualitaet beruecksichtigen.
http://support.sundtek.com/index.php/topic,158.0.html in diesem Fall gehen wir derzeit tatsaechlich von einem defekten Geraet aus.
Sie koennen uns auch gerne ein Geraet zuruecksenden zur Ueberpruefung, eine Loesung fuer Ihr Problem muss irgendwie moeglich sein.
-
Hallo,
habe versucht die Treiber zu installieren - danach ist kein Reboot mehr möglich: "Kernel Panic".
Installation im frisch installierten "easyVDR"
http://ftp.gwdg.de/pub/linux/easyvdr/beta/07/easyvdr-0.7.14-k2.6.28.9-HD-Edition.iso
auf Zotac ION ITX A (Atom) Mainboard.
Bildschirmausgabe beim Installieren: siehe unten.
Danach kann man das System nicht mehr booten: Kernel Panic und "GLIBC_2.4"-Fehlermeldung wie unten.
Was mache ich falsch?
Wir haben den Installer aktualisiert, easyVDR sollte ab jetzt auch damit funktionieren. Der Installer ueberprueft ab sofort die Systemvoraussetzungen (hauptsaechlich die libc Version) damit es zu keinen inkompatibilitaeten kommen kann.
-
In dem Zusammenhang würde mich interessieren, ob mittlerweile die Möglichkeit besteht, die Installationsdateien als tar.gz Archiv zu erhalten. Das würde mir die Arbeit an dem Arch Linux PKGBUILD erleichtern.
Vielen Dank
-
Ist wie schon erwähnt möglich, wir haben dies lediglich etwas nach hinten geschoben da wir unser internes Releasesystem vorab noch etwas vorantreiben. Als ETA hierfür können Sie ca. 1-2 Wochen annehmen.
-
Hallo,
habe versucht die Treiber zu installieren - danach ist kein Reboot mehr möglich: "Kernel Panic".
Installation im frisch installierten "easyVDR"
http://ftp.gwdg.de/pub/linux/easyvdr/beta/07/easyvdr-0.7.14-k2.6.28.9-HD-Edition.iso
auf Zotac ION ITX A (Atom) Mainboard.
EasyVDR ist eine merkwuerdige Distribution, libc ist aelter als 4 Jahre (Linux 2.6.15 ist auch ca. 4 Jahre alt), wobei alles andere etwas neuer zu sein scheint. Wir werden hierfuer umgehend einen Check einbauen. Fuer EasyVDR koennen wir lediglich ein eigenes Treiberpaket bereitstellen (fuer libc<2.4) In so einem Fall kann man mit einer Bootcd hochfahren und /etc/ld.so.preload entfernen. Ein kerneloops sollte jedoch dennoch nicht passieren, das zeigt das es hierbei noch andere Probleme mit dieser Distribution gibt.
Vielen Dank und ein großes Lob für die schnelle Reaktion. Hab's auch gleich ausprobiert:
Leider hat der Fix immer noch nicht ganz zum Ziel geführt. Vielleicht ist es ja nur noch eine Kleinigkeit und wieder eine EasyVDR-Spezialität (EasyVDR scheint das die am besten vorkonfigurierte Distribution zu sein - deshalb würde ich sie gerne verwenden). Die Installation läuft jetzt ohne Fehlermeldung durch. Jedoch konnte ich die MediaTV Pro immer noch nicht zur Zusammenarbeit bewegen. Nach einiger Recherche ist mir folgendes aufgefallen:
Bei gestopptem VDR:
easyVDR:/var# /opt/bin/mediaclient -D DVBC
Using device: /dev/dvb/adapter0/frontend0
unable to open device node: /dev/dvb/adapter0/frontend0
easyVDR:/var# /opt/bin/mediaclient -e
**** List of Media Hardware Devices ****
easyVDR:/var# ls /dev/dv*
/dev/dvd /dev/dvdpc0 /dev/dvdpc2 /dev/dvdrw
/dev/dvd1 /dev/dvdpc1 /dev/dvdpc3 /dev/dvdrw1
easyVDR:/var# cat /var/log/mediasrv.log
Starting up Multimedia Framework (Jan 25 2010 06:04:54)
Detected DVB version.h
API Version: 5.1
Running on Linux (2.6.28.9)
Detected: GenuineIntel
This CPU supports: MMX and SSE
scanning devices
scanning for plugins
found lib: libdrv_em28xx.so
found lib: libdrv_net.so
scanning devices done
attached devices:
there are currently no devices attached
easyVDR:~# lsusb -t
Bus# 4
`-Dev# 1 Vendor 0x1d6b Product 0x0001
`-Dev# 2 Vendor 0x046d Product 0x0b04
|-Dev# 3 Vendor 0x046d Product 0xc713
`-Dev# 4 Vendor 0x046d Product 0xc714
Bus# 3
`-Dev# 1 Vendor 0x1d6b Product 0x0001
`-Dev# 2 Vendor 0x0471 Product 0x060c
Bus# 2
`-Dev# 1 Vendor 0x1d6b Product 0x0002
`-Dev# 2 Vendor 0xeb1a Product 0x51b2
Bus# 1
`-Dev# 1 Vendor 0x1d6b Product 0x0002
`-Dev# 3 Vendor 0x0409 Product 0x0840
easyVDR:~# lsusb -v -d eb1a:51b2
easyVDR:~#
Diese Ausgabe ist nicht normal, oder? Werden bei der Installation die Devices nicht richtig angelegt?
-
Der Standard Kernel von diesem System ist defekt, es gibt die Moeglichkeit das Geraet ueber ein aktiv USB Hub mit 2.6.28 zu betreiben oder eventuell den zweiten Kernel des Systems (2.6.22) zu verwenden.
2.6.28 von diesem System hat die maximale Stromversorgung von USB Sticks mit 2 mA festgelegt, was auf jeden Fall zu wenig ist, ein USB Bus muss bis zu 500mA bereitstellen. Wir haben hierfür einen Bugreport bei EasyVDR angelegt (die Kernel Konfiguration CONFIG_USB_GADGET_VBUS_DRAW=2 sollte =500 sein).
-
Der Standard Kernel von diesem System ist defekt, es gibt die Moeglichkeit das Geraet ueber ein aktiv USB Hub mit 2.6.28 zu betreiben oder eventuell den zweiten Kernel des Systems (2.6.22) zu verwenden.
2.6.28 von diesem System hat die maximale Stromversorgung von USB Sticks mit 2 mA festgelegt, was auf jeden Fall zu wenig ist, ein USB Bus muss bis zu 500mA bereitstellen. Wir haben hierfür einen Bugreport bei EasyVDR angelegt (die Kernel Konfiguration CONFIG_USB_GADGET_VBUS_DRAW=2 sollte =500 sein).
Super, vielen Dank. Respekt, auf diese - nicht triviale - Fehlerquelle muss man erst mal kommen! Mit einem Hub habe ich es probiert, leider schaltet das OS den Stick gar nicht erst ein.
Hoffe jetzt, dass einer der EasyVDR-Entwickler erbarmen mit mir hat, da ich das leider nicht selbst gelöst bekomme.
-
Versuchen Sie 2.6.22 aus dem Startmenue zu booten, diese Version unterstuetzt das Feature der Powerlimitierung normalerweise noch nicht.
-
40% Signalqualitaet ist auf jeden Fall grenzwertig. ARM wurde bereits getestet ebenfalls mit QAM256, die Signalstaerke wird nicht beeinflusst von VDR.
Ich glaube das mit den 40% noch nicht. Ich hatte jetzt testweise mal eine Technisat CableStar HD 2 hier, die zeigt auf allen Kanälen eine Signalstärke zwischen 90 und 100%, die auch immer leicht schwankt. Auch erkennt man genau einen geringeren Wert, wenn man zur Dämpfung mal einen 2fach-Verteiler zwischenschaltet. Beim MediaTV Pro habe ich immer konstant 40% bei QAM256 Sendern und 100% bei QAM64 Sendern.
Die CRC Fehler kommen daher das VDR besonders viele Nodes aufmacht und jeder Node fuer sich selber einen CRC Check macht.
Bei allen unverschlüsselten Sendern (QAM64 und QAM256) habe ich ja mit den aktuellen Treibern, wie geschrieben, keine CRC-Fehler mehr und ein Top Bild. Und unter ReelVDR auf x86 gehen jetzt auch die Conax-verschlüsselten Sender.
Probleme gibts nur noch auf dem ARM-basierenden OpenRD mit verschlüsselten Sendern. Da glaube ich aber nun den Fehler auch gefunden zu haben - das zum Decodieren des Streams verwendete FFDeCsa zeigt beim integrierten Test Fehler, hat also wohl unter ARM ein Problem. Ich bin mir ziemlich sicher, daß das die eigentliche Ursache ist und nicht die "angeblichen" 40% Signalstärke.
Im Prinzip kann ich damit für den Sundtek-Treiber Entwarnung geben. Da stört mich im Moment nur noch das instabile Verhalten mit mehreren Sticks an einem Rechner. Aber das wurde ja an anderer Stelle schon erwähnt und ist wohl in Arbeit.
-
Wie schon erwaehnt wir vermuten das dies ebenfalls einen Zusammenhang zwischen ihrem Anschluss gibt, Q256 wurde bei uns ausgiebig getestet, und zeigt mit dem Signalgenerator sowie Kabeldeutschland (gegenuebergestellt mit einer STB von Thomson bei schwachen Sendern ziemlich das gleiche an). Jedoch schwankt z.b bei KDG hier bei den normalen Sendern auch nichts zwischen 90-100%, sondern ist permanent auf 100%.
* http://www.dwcom.eu/images/product_images/popup_images/128_0.png
Das naechste Update wird es in 1-2 Wochen bereits mit neuen Applikationen geben.