Andere Hardware - Andere Fehler ...

[Muschimann]

Hallo,

da bei mir der VDR dermaßen instabil lief habe ich den erstmal wieder auf 'ne PCI Karte umgestellt.

Nun habe ich einen ähnlichen Rechner aufgebaut um mit den Sticks eine stabile Konfiguration anzutesten.

Hardware:
Board: Intel BLKD945GSEJT
Speicher: 2GB DDR2 800 von Kingston
HDD: 30 GB SSD von OCZ

OS:
Ubuntu 10.04 Server
Kernel: Linux ramsdorf-srv01 2.6.32-22-generic-pae #35-Ubuntu SMP Tue Jun 1 15:47:31 UTC 2010 i686 GNU/Linux
Sundtek-Treiber: der neueste

Installierte Dienste:
Asterisk
Samba
lighttpd
openldap

Installiertes VDR Zeuch:
vdr - 1.7.14-7yavdr1
vdr-plugin-epgsearch - 0.9.25.beta16-4yavdr1
vdr-plugin-streamdev-server - 0.5.0~pre20090706+cvs20100307.2102-4yavdr1
vdr-plugin-svdrpservice - 0.0.4-9yavdr1
vdradmin-am - 3.6.7-1yavdr2

Damit ist der Rechner fast identisch mit meinem Produktivsystem.

Die Probleme mit der Aufnahme öffentlich-rechtlicher Sender konnte ich bis dato noch nicht verifizieren, jedoch steigt der vdr jetzt zwischendurch immer mal aus. Aber auch diese Probleme habe ich mit einer Technotrend PCI Karte nicht.

Da ich eben beim rumspielen wieder so einen Ausfall hatte habe ich mal die Logs zeitlich begrenzt hier angehangen.

[Sundtek]

Wie bereits erwaehnt scheint es probleme mit dem jeweiligen Kabelanschluss und dem Stick zu geben.
Eventuell ist sogar der Stick bei Ihnen defekt, falls moeglich sollten Sie ihn an uns zuruecksenden.

Ihre VDR Konfiguration war einwandfrei und sollte im Allgemeinen keine Probleme bereiten (besonders da wir quasi ebenfalls ein identisches System installiert haben).

[Muschimann]

Verwechseln wir uns gerade!? Ich kann mich nicht erinnern die Konfiguration geschickt zu haben.

Also das es sich um einen defekt handelt kann man glaube ausschließen, zum einen weil ich zwei habe und es bei beiden unabhängig von einander zu Problemen kommt und zum anderen weil ich die Sticks aus der "Aktion" kaufte und diese von daher bei Ihnen im Testbetrieb waren.

Die Sache mit dem Kabelanschluß wär schade. Könnte ich evtl. irgendwie dabei helfen die Sticks "kompatibel" zu machen?

Was mich nur wundert ist das ich das was oben in den Logs steht noch nie hatte. Vorher hatte ich da ganz andere Problemchen...

[Sundtek]

Koennten Sie die Sticks eventuell unter Windows testen?
Ich denke in einigen ihrer Logfiles waren "continuity errors" zu finden.
Sollte dieser Fehler konstant auftreten haben wir hierfuer noch keine Loesung (eventuell hilft ein Kabeltausch?).
Bei allen Kunden die wir bis jetzt hatten trat dieser Fehler bis jetzt bei 2-3 Kunden auf.
Da diese Probleme wohl auf Chiplevel liegen haben wir diese auch an Trident weitergeleitet, dort werden unsere Reports mittlerweile auch genauer untersucht.

[Muschimann]

Koennten Sie die Sticks eventuell unter Windows testen?
Ich denke in einigen ihrer Logfiles waren "continuity errors" zu finden.

Unter Windows testen ist kein Problem, kann ich heute Abend mal machen. Nur wie sehe ich da ob Fehler geschehen!? Manchmal liefs bisher ja auch mehrere Tage ohne Probleme und dann wieder Problemchen im Stundentakt. Das ist irgendwie sehr merkwürdig.

Die Logs habe ich eben mal danach durchsucht - mit dem Ergebnis das das gar nicht drin steht.

[Sundtek]

Einfach ein Video aufnehmen, falls moeglich unter Windows und Linux gleichzeitig fuer 1-2H (unter Linux eventuell Kaffeine dafuer verwenden).

Danach koennen die Datenstroeme unter Linux z.b mit Mplayer auf Fehler ueberprueft werden.

[Muschimann]

Gleichzeitig unter Windows und Linux? Das verwirrt mich jetzt.

Ich hätte noch 'ne andere Fehlerquelle im Visir - kam mir eben so beim duschen.

Ich habe die Sticks nicht an der ATX Blende angeschlossen (weil da aufgrund der Länge der Sticks kein Platz ist), sondern per Front-USB Kabel an einem internen USB-Anschluß. Ist bekannt das da vielleicht die Leistung des USB Anschlusses nicht mehr ausreicht um die Sticks zu versorgen?
Das könnte auch das Problem mit den Aufnahmen vom ÖR sein, denn die haben eine deutlich höhere Datenrate als die Privaten. Gibt es im Treiber eine Möglichkeit das mal zu testen?

Alternativ hätte ich noch ein Asus AT4NM10-I Board da - mit dem werde ich am Wochenende das ganze auch mal noch testen.

[Sundtek]

Die Datenraten sollten ziemlich identisch sein

cat /dev/dvb/adapter0/dvr0 | pv > /dev/null sollte bei allen Sendern ca. 4.5 MB/Sek anzeigen

1.5 MB werden vom Treiber standardmaeszig gefiltert und entfernt (Null Packets)

/opt/bin/mediaclient --nullpackets=on schaltet die Null Packets beim Stream hinzu, dann sollte der Datendurchsatz bei ca 6 MB/Sek liegen.

[Muschimann]

Die Datenraten sollten ziemlich identisch sein

cat /dev/dvb/adapter0/dvr0 | pv > /dev/null sollte bei allen Sendern ca. 4.5 MB/Sek anzeigen

Das hab ich mal schnell noch getestet, aber ich komme da auf ganz andere Werte:

RTL Gruppe: ca 600 kB/s
ProSiebenSat1: ca 800 kB/s
ARD: ca 1,4 MB/s
ARD HD: ca 1,65 MB/s

So jetzt muß ich erstmal bisschen Geld verdienen. Den Rest teste ich heute Abend durch.

[Sundtek]

Niedrigere Werte bekommt man wenn VDR aktiv ist und VDR die PID Filter fuer die jeweiligen Sender aktiviert hat.
Wenn Sie VDR beenden bekommen sie die hoeheren Werte (den gesamten Transponder) und nicht nur den gefilterten Sender.

Um was fuer einen Kabelanschluss handelt es sich hier, was fuer ein Anbieter?
Oder handelt es sich um einen Gemeinschaftsanschluss welcher DVB-S -> DVB-C umsetzt?

[Muschimann]

Anbieter ist dieser:
http://www.servicekabel.de/

Da kommen aber auch Sender von Telecolumbus mit, weil die einen Kooperationsvertrag haben.

[Muschimann]

Eben bin ich nach Hause gekommen udn wollte mal gucken ob der brav aufnimmt - Pustekuchen, diesmal:

Code: [Auswählen]

Jun  4 18:45:51 ramsdorf-srv01 runvdr: stopping after fatal fail (vdr: no primary device found - using first device!)
Nach kurzer recherche stellte ich fest das der gegen 12:55 Uhr die Geräte "verloren" hat.

Ich hänge mal die Logs gefiltert nach 12:5x hier mit an.

[Muschimann]

Ich will mich noch nicht zu früh freuen, aber hier ein kurzer Zwischenbericht:

So, nach einem Testmarathon Freitag und Samstag früh scheint das Problem gelöst zu sein, allerdings weis ich noch nicht genau wodurch.

Das Problem das bei mir via Streamdev keine Daten kommen hatte ich schonmal früher. Damals habe ich das mit dem Dummydevice-Plugin gelöst, also habe ich das auch diesmal versucht und das scheint zu klappen.

Des Weiteren habe ich im BIOS "Legacy USB" deaktiviert. Da bin ich eher durch Zufall drauf gekommen, weil mein USB IR Adapter bei einem meiner Streaming-Clients gezickt hat und seit der Deaktivierung dieser Option dort vernünftig läuft.

Außerdem kam ein VDR Update und ein Kernelupdate über die Paketquellen.

Nunja, jetzt läuft die Kiste seit Samstag Nachmittag durch, ohne Fehler (bisher) und wurde auch schon massiv mit Aufnahmen und Streamdev Anfragen gequält. Den Spaß werde ich mal noch über die Woche testen und wenns wirklich stabil läuft kann ich dann endlich die Sticks samt Konfiguration in mein Produktivsystem übernehmen.

Achja, zum Beitrag vorher:
Da der VDR die Devices verlor und dadurch runvdr nicht richtig funktionierte habe ich runvdr so erweitert das er den Treiber beendet und neu startet bevor vdr neu gestartet wird. Bisher wurde runvdr noch nicht wieder ausgeführt, aber ich hoffe das das klappt.

[Sundtek]

Des Weiteren habe ich im BIOS "Legacy USB" deaktiviert. Da bin ich eher durch Zufall drauf gekommen, weil mein USB IR Adapter bei einem meiner Streaming-Clients gezickt hat und seit der Deaktivierung dieser Option dort vernünftig läuft.

solche Notwendigkeiten sind fuer uns leider unmoeglich zu erkennen, mittlerweile haben mindestens 10 Leute oder mehr Probleme mit etwaigen Bios USB Einstellungen benachrichtigt. Das einzige was wir sehen ist jedoch immer wieder nur ein "Signalproblem" da der Datenstrom defekt zu sein scheint (was eine Auswirkung der falschen Bios Einstellungen darstellt)
Die Loesung war in diesen Faellen ebenfalls die gleiche, einfach die Bios Einstellung aendern.

[Muschimann]

So, ich mal wieder.

Also diese Legacy Geschichte hat zwar die Stabiliät verbessert, aber dennoch waren bei Aufnahmestart VDR Abstürze zu bemerken.

Nunja, ich habe die ganze Woche getüftelt und mir ist aufgefallen das der im LOG vorm Abschiß des VDR dieses recording-hooks-Zeuch ausgeführt wird und nun habe ich da einfach mal bei den drei Optionen ein "sleep 5" rein gesetzt und seit dem (Donnerstag) ist das Ding kein einziges mal abgestürzt und ca 50 Testaufnahmen liefen ohne Probleme durch.

Ich kanns mir zwar nicht erklären, aber wenns läuft will ich mich auch nicht beschweren.