Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Thema gestartet von: hjt am Januar 04, 2011, 11:26:30 Vormittag
-
Hallo,
würde nur gern wissen ob es zu meinem Artefakte Problem (es wird kein Netzwerk verwendet) schon eine Lösung bzw. Verdacht gibt?
Ubuntu 10.10. Stick der 2. Generation direkt am HP Laptop, lenovo X301 Thinkpad und lenovo Thinkcenter Desktop.
Ausgelöst werden die Artefakte bei DVB-T QAM64 bei etwas schlechteren Empfang obwohl der WinTV HVR900 hier keine Probleme hat.
Ausgelöst werden die Artefakte auch bei DVB-C QAM256. Bei einigen Sendern eher z.B. Phonix.
http://www.bnet.at/uploads/tx_mddownloadbox/B061-0610_Programmliste_kabelDigitalTV_04.pdf
Wurden die Artefakte ausgelöst, treten Sie bei allen Sendern auf.
Ein mehrmaliges hinschalten auf z.B. Phonix kann das Problem wieder lösen.
Dann läuft alles stabil.
Zusätzlich besitze ich noch einen WNDR3700. Aber auch hier ist es sicher nicht das Netzwerkproblem. Gleiches Verhalten wie direkt am PC.
Ich fasse kurz zusammen:
- Auf 3 PC's getestet
- Jeweils kaffeine und VDR
- Mit DVB-T QAM64 und DVB-C QAM256 getestet
Es kann nicht das Netzwerkproblem sein.
Es kann nicht das QAM256 Problem sein.
Es wird eher ausgelöst bei schechterem Signal.
Bei DVB-T wenn die Antenne liegt, obwohl der HVR900 kein Problem hat.
Bei DVB-C der Sender Phoenix (als Beispiel).
Mehrmaliges hinschalten zu Phoenix kann das Problem aber auch lösen und dann läuft alles bis zum nächsten Umschalten stabil.
lg
Horst
-
Was für ein Programm wird denn verwendet?
Mit z.B Kaffeine kann dies hier nicht nachvollzogen werden
Was zeigt "lsusb -d eb1a:51b2 -vv" an?
Zusätzlich eventuell /var/log/mediasrv.log löschen und das ganze bei Ihnen nocheinmal reproduzieren und anschließend die Logfile hier anhängen.
-
Hi
verwendet wurde kaffeine oder vdr.
-
Bitte die benötigten Informationen anhängen, besonders die Logfile.
Es muss einmal herausgefunden werden woran es liegt
1. USB Datenübertragung
oder
2. Signalproblem
Der Stick bietet verschiedene Möglichkeiten Systemprobleme in den Griff zu bekommen jedoch müssten die zuerst identifiziert werden.
Während der Sender läuft bitte auch
/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 ausführen
-
Die alten log files habe ich gefunden, werde aber Heute noch welche machen.
2010-12-21 09:29:16 [2123] Running on Linux (2.6.35-22-generic)
kein USB Hub
-
Setze das ganze bitte auf ISO zurück
/opt/bin/mediaclient --dtvtransfermode=iso -d /dev/dvb/adapter0/frontend0
Die Errors haben nichts zu bedeuten, da der Stick dort abgesteckt wurde
freeing and deinitializing driver instance
Bitte auch noch das readsignal ausführen bei betroffenen Sendern.
Das ganze bitte mit dem aktuellen Treiber testen.
http://www.sundtek.de/media/sundtek_installer.sh
-
Stick ist schon lange wieder auf iso, habe ich aber trotzdem nochmal gemacht.
Treiber von Heute installiert.
Aptosid amd64 (Debian Sid) heute neu installiert, kernel 2.6.36.
Beim umschalten von ORF1 FREQ: 314000000 auf Phoenix FREQ: 370000000 kamen sofort die Artefakte.
SIGNAL: [.............................. ] ( 90%) BER: 41248 FREQ: 314000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [ ] ( 0%) BER: 58 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 92%) BER: 58 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 92%) BER: 58 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 90%) BER: 74 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 90%) BER: 74 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............................. ] ( 88%) BER: 88 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............................. ] ( 88%) BER: 88 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............................. ] ( 89%) BER: 80 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............................. ] ( 89%) BER: 80 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [........................ ] ( 73%) BER: 192 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.......... ] ( 32%) BER: 41248 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.......... ] ( 32%) BER: 4888 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.......... ] ( 32%) BER: 4888 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............ ] ( 37%) BER: 635 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............ ] ( 37%) BER: 635 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 91%) BER: 63 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 91%) BER: 63 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................. ] ( 91%) BER: 104 FREQ: 370000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
[Edit]
aha, also wie hier, nur ist die Frequenz hier kleiner und das Betriebssystem ist 64bit
http://support.sundtek.com/index.php/topic,450.0.html
-
Ok, das ist ausreichend, morgen werden 2 weitere Sticks an Sie geschickt (einen weiteren aktuellen sowie einen aus der 1. Generation). Weitere Informationen folgen morgen per Email.
Danke für die ganzen Informationen!
-
Hallo,
nur falls es schon abgeschickt wurde,
bis jetzt hab ich kein mail bekommen.
-
Ok, das ist ausreichend, morgen werden 2 weitere Sticks an Sie geschickt (einen weiteren aktuellen sowie einen aus der 1. Generation). Weitere Informationen folgen morgen per Email.
Hallo,
das war wohl ein Versehn mit mir. Habe wirklich kein Problem damit wenn wer anders gemeint war.
Es gibt ja noch einen Thread mit diesem Problem.
Nur will ich nicht, daß es heißt ich habe 2 Sticks zum Testen bekommen und hab sie nicht bekommen.
Wirklich nicht bös gemeint. Will das nur klarstellen.
Liebe Grüße und hoffe das Beste mit dem Problem
Horst
-
Werden wohl noch diese Woche ankommen.
Wir haben mittlerweile eine mögliche Fehlerquelle ausfindig gemacht, ein zu starkes Signal könnte das ganze beeinflussen (dies ist eher selten der Fall kann aber durchaus auch vorkommen).
Die Sticks aus der ersten Produktionsreihe haben das Signal etwas stärker gedämpft bevor es in den Tuner eingespeist wurde, aus dem Grund werden 2 Sticks verschickt, einen weiteren neuen um sicherzustellen das der aktuelle Stick nicht defekt ist und ein älterer.
Das ganze hat nun Vor und Nachteile, bei schwächeren Signalen funktioniert es besser laut HW Ingenieur bei sehr starken jedoch etwas schlechter.
Mit einem durchschnittlichen Signal wie es bei uns in Berlin vorhanden ist kommt überall 100% Signalstärke, mit dem Signalgenerator (mit sehr starkem Signal) können wir dies soweit nachvollziehen. Das ganze wird aber auch noch etwas weiter überprüft.
Diesbezüglich sind uns derzeit 3 Fälle bekannt wo dieses Problem aufgetreten ist, in einem gelösten Fall hat der Stick mit der größeren Dämfpung aus der ersten Generation das Problem behoben.
-
Hi,
wenn die Dämpfung das Problem ist, schick mir keine Sticks. Das wird nichts bringen.
Ich hab einen regelbaren Verstärker und von ca. 55-65dB an der Dose getestet.
Sogar an verschiedenen Dosen im Haus.
Das wirds ziehmlich sicher nicht sein.
lg
Horst
-
Mal bis Do-Sa abwarten bis die Sticks angekommen sind, bei Problemfällen hat bis jetzt immernoch einer von den 3 Stickversionen die wir nun haben funktioniert.
-
@suntek,
habe exact die selben probleme wie horst.
habe auch einen sticj der ersten generation.
koennen siemirbitte auch einen neuen stick senden??
gruss
gwaag
-
Es handelt sich hierbei um ein Problem mit seinem Gerät, und nicht mit Geräten aus der ersten Generation.
Was zeigt folgender Befehl an wenn die Artefakte auftreten?
/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0
-
Mit dem Befehl /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter1/frontend0
zeigt es immer 100% an.
gruss
gwaag
-
womit wird der Stick verwendet? PC, embedded Linux, Netzwerk, welche Linux version?
Das Problem liegt nicht am Signal/Stick, eher vielleicht an einem defekten oder überlastetem System. Eventuell besprechen Sie kurz mit unserem Support via Skype Chat (-> Username "Sundtek")
-
Hallo,
ich möchte ein riesiges Dankeschön an das Sundtek-Team für seinen Support ausrichten.
Der Sample läuft 1A, habe jetzt immer
SIGNAL: [.................................] (100%) BER: 0 FREQ: 362000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
Das Zitat von 106060 unterstreiche ich gern
Solch einen genialen Support habe ich noch nie erlebt - Bravo!
Ich bin beeindruckt von Sundtek und kann die Produkte nur jedem empfehlen!
So, das Lob musste einfach mal sein!
Dankeschön :D
Horst
-
Ich klinke mich auch mal wieder ein (Kommen aus diesem Thread: http://support.sundtek.com/index.php/topic,331.msg2906.html#msg2906 )
lennart@sheeva:~$ /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 ausführen
== reading digital TV signal ==
SIGNAL: [...] (100%)
SIGNAL: [...] (100%)
SIGNAL: [...] (100%)
SIGNAL: [...] (100%)
SIGNAL: [...] (100%)
SIGNAL: [...] (100%)
:
Alle Punkte wurden auf drei Punkte reduziert. Die Messung hat über 5 Minuten immer 100% ergeben. Die Artefakte treten weniger bei SD-Programmen auf (etwa 5-10% der Aufnahme) als bei HD (90-100%).
lennart@sheeva:~$ cat /etc/debian_version
6.0
lennart@sheeva:~$ uname -r
2.6.32-5-kirkwood
Die Datei im Anhang zeigt die Systemauslastung. Die Aufnahmen haben gegen halb 12 und 20:00 begonnen. Der Dicke Block in der Nacht hat nichts mit den Aufnahmen zu tun. HD-Programme sind ähnlich unauffällig.
Ich kann keine Dateien anhängen. "Es kann auf den UploadPfad der Dateianhänge nicht zugegriffen werden." Was würde man sehen? Nicht viel. Keine 40-80% auslastung während der Aufnahmen.
-
Ging das via Netzwerk, oder wie wurde aufgenommen?
Diese schwachen ARM Systeme ohne FPU sind nich besonders leistungsstark. Das Problem wird derzeit beim schlechten Scheduling vom System vermutet.
Bei MIPS oder PowerPC 450 Mhz haben wir diese Probleme nicht (laut Top CPU Auslastung 0%), auch bei X86 nicht.
Wir arbeiten derzeit an weiteren Netzwerkclients (insbesondere Apple) sobald diese fertig sind werden wir uns den Sheevaplug noch etwas genauer ansehen.
-
Es handelt sich um einen Sheevaplug auf dem ein mythtv-backend läuft. Es nimmt direkt auf Platte auf. Diese ist via eSata verbunden, hier sind also ausreichend Kapazitäten vorhanden.
Es ist egal, ob die Aufnahme dann live auf ein Frontend gestreamt wird, oder ob das Backend "in aller Ruhe" aufnimmt. Es gibt immer (mal mehr, mal weniger) Artefakte.
Hier ein link zur Grafik:
Auslastung: https://rtjuette.de/graph.png
-
Sieht man ja ganz gut das IO dort Schuld ist, MythTV darauf direkt laufen zu lassen wird wohl eher eine schlechte Idee sein.
Was sie versuchen können ist das Modul hinzuzukompilieren
http://support.sundtek.com/index.php/topic,534.0.html
Ansonsten sollte MythTV das schreiben auf die Platte irgendwie verlangsamen um IO nicht zum Peak zu bringen.
-
Ich hatte vergessen zu die Erklärung erneut zu posten: Die Aufnahmen haben gegen halb 12 und 20:00 begonnen. Der Dicke Block in der Nacht (4-10) hat nichts mit den Aufnahmen zu tun (Datenbankpflege). HD-Programme sind ähnlich unauffällig.
-
Frage ist passiert das auch auf einem PC? Dann wäre wohl das Signal die Ursache.
-
Ich hätte hier nur noch ein MacBook Pro. Aber es gibt anscheinend keine OS X Treiber. Linux in einer VMWare-VM bringt sicher auch nichts, richtig?
-
Hi,
versuche deinen Mac mit aptosid im Livemode zu starten.
Sollte booten. Du kannst den sundtek installer auch im Livemode ausführen und den Stick dann testen. Hoffe ich zumindest.
oder ubuntu
https://help.ubuntu.com/community/MacBookPro
-
Ja, die Idee mit Ubuntu hatte ich auch - nachdem ich versucht habe in meiner angestaubten und lange vergessenen Boot Camp-Partition Windows Media Center zu konfigurieren. Hätte ich vorher mal im Forum gelesen, dass das nicht geht.
Also habe ich Ubuntu 10.10 von CD gebootet, den Treiber installiert, Sender eingestellt, und per cat einen Stream abgegriffen.
Dort sind, genau wie bei Aufnahmen auf dem SheevaPlug, gelegentlich Artefakte zu sehen und zu hören. Keine Sorge: Die Aufnahme habe ich unter OS X betrachtet, es gab keine "Reibungsverluste" durch die Wiedergabe ohne Grafikkartentreiber im Live-System.
-
Es geht morgen ein Ersatzstick raus, das ist nicht das normale verhalten.
-
Es geht morgen ein Ersatzstick raus, das ist nicht das normale verhalten.
Sind Sie sicher, dass Sie die richtige Adresse angegeben haben? Können Sie von neu.wm Benutzernamen auf die Adresse schließen?
Ich habe übrigens inzwischen den offiziellen squeeze Kernel am Start. Es gibt insgesamt weniger Last (wohl auch, weil andere Anwendungen weniger brauchen), aber die gleichen Probleme. Man kann nicht wirklich fernsehen.
-
Ich habe mir heute auch mal das log vom mediaclient angeschaut:
dort taucht immer wieder mal folgendes auf:
2011-02-26 10:11:50 [519] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 10:11:50 [519] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 10:12:08 [519] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 10:12:08 [519] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 10:12:31 [519] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 10:12:31 [519] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 10:12:37 [519] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 10:12:37 [519] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 10:13:29 [519] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 10:13:29 [519] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 10:13:53 [519] Warning all hardware pid filter are in use unable to set PID 0x17d4
Und zuletzt:
2011-02-26 11:07:27 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:11:33 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:11:35 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:13:26 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:15:03 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:15:04 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:15:04 [501] this now very likely leads to stream corruptions
2011-02-26 11:15:49 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:16:10 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:19:18 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:19:20 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:19:27 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:19:28 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:19:28 [501] this now very likely leads to stream corruptions
2011-02-26 11:20:09 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:21:59 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:22:29 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:22:35 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:23:00 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:24:11 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:24:12 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:24:12 [501] this now very likely leads to stream corruptions
2011-02-26 11:25:02 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:25:07 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:25:07 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:25:07 [501] this now very likely leads to stream corruptions
2011-02-26 11:25:09 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:25:10 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:25:10 [501] this now very likely leads to stream corruptions
2011-02-26 11:25:35 [501] THERE MUST BE A BUG WITH YOUR HARDWARE, PLEASE CHECK ISO/BULK TRANSFER MODE
2011-02-26 11:25:35 [501] Packetsize < 188 bytes is invalid, throwing it away and increasing corruption
2011-02-26 11:26:51 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:26:52 [501] error submitting urb after second attempt, marking request as not submitted
2011-02-26 11:26:52 [501] this now very likely leads to stream corruptions
2011-02-26 11:27:44 [501] error submitting urb, retrying (but please check your hardware)
2011-02-26 11:30:03 [501] error submitting urb, retrying (but please check your hardware)
-
Ich habe bisher noch keinen Stick erhalten.
Wurde der Stick tatsächlich verschickt?
-
Die letzte private Nachricht kam anscheinend nicht an:
Nein, der Ersatzstick ist nicht angekommen.
Ich habe noch immer Probleme mit Artefakten. Ich habe inzwischen auch an einem weiteren x86-Rechner getestet. Es gibt auch hier gelegentlich Artefakte (seltener, aber vorhanden).
Edit Sundtek:
Stick ist ja mittlerweile angekommen, nun hoffentlich passt es jetzt.