[Gelöst] Artefakte Problem

[gwaag]

Mit dem Befehl /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter1/frontend0
zeigt es immer 100% an.

gruss
gwaag

[Sundtek]

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")

[hjt]

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 
Horst

[lajuette]

Ich klinke mich auch mal wieder ein (Kommen aus diesem Thread: http://support.sundtek.com/index.php/topic,331.msg2906.html#msg2906 )

Code: [Auswählen]

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%).

Code: [Auswählen]

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.

[Sundtek]

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.

[lajuette]

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

[Sundtek]

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.

[lajuette]

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.

[Sundtek]

Frage ist passiert das auch auf einem PC? Dann wäre wohl das Signal die Ursache.

[lajuette]

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?

[hjt]

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

[lajuette]

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.

[Sundtek]

Es geht morgen ein Ersatzstick raus, das ist nicht das normale verhalten.

[lajuette]

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.

[lajuette]

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)