Hallo zusammen
Die Ausgangslage
Satkarten wie die Twinhan VP1041/Technisat SkyStar HD2/TerraTec Cinergy S2 PCI HD CI und andere, welche den STB0899 Demodulator verwenden, sind seit langem berüchtigt für Probleme beim Kanal Tuning. Es war über verzweifelte Versuche zu lesen, mit höheren oder tieferen Frequenzen in den Kanallisten doch noch einen zuverlässigen Lock zu erreichen, was aber nicht wirklich gelang. Meistens wartete man auf den Lock zu lange oder er kam gar nicht zu Stande.
Die Ursache dafür liegt an fehlerhaftem Code im Source von stb0899_algo.c, welcher das Tuning dadurch erreicht, dass mit verschiedenen Frequenzen ggf. in einem Zickzack-Verfahren der Kanal Lock gesucht wird. Diese Fehler findet man bereits im Fedora 6 Code des Mantis Treibers, welcher ursprünglich von Twinhan und STM an die Linux Community freigegeben wurden. Bis anhin hat sich offenbar nur Alex Betis vor 2 Jahren intensiv bemüht, den DVB-S Algo auf Geschwindigkeit zu optimieren. Seine Patches bildeten die Grundlage für meine Code Verbesserung.
Die passende Testumgebung
Um gesicherte Informationen über den Zustand eines Tuning Algorithmus zu erlangen, braucht man reproduzierbare Tuningvorgänge. Ein solches Testprogramm sollte möglichst Lowlevel implementiert sein, damit man andere Fehlerquellen (Bildentfaltung, mangelhafte DiseqC Schalt Sequenzen, etc) ausschliessen kann. Ausserdem muss ein solches Tool selbstständig umfangreiche Kanallisten mit DVB-S und DVB-S2 Sendern durchzappen können und dabei eine Statistik führen (Zeitbedarf, Kanalhistorie, Signalwerte, Anzahl Tuning Anläufe bis zum Lock)
Dafür wurde das Konsolen Tool szap-s2 von mir abgeändert, so dass für alle Sender sofort nach dem Zap-Vorgang der Status abgefragt wird. Falls noch kein Lock vorhanden ist, wird in weiteren Intervallen von 10ms abgefragt und jede Sekunde das Ergebnis angezeigt, bis entweder Lock erreicht ist oder 10s verstrichen sind. Die Anzahl der DiseqC Wiederholungen kann über einen neu eingeführten Parameter gesetzt werden (Default sind 2, nicht nur eine Sequenz wie bisher).
Wenn nach 10s kein Lock zustande kommt, wird ein Fehlerzähler erhöht und zum nächsten Sender fortgeschritten. Die angehängte Senderliste umfasst rund 3000 Sender auf Astra+Hotbird in dem für das Testprogramm geeigneten zap Format.
Mit meinen zwei Twinhan VP1041 Karten dauert ein Durchlauf rund 1 Stunde, d.h. rund 1 sec pro Zapvorgang. In unzähligen Durchläufen ist seit der letzten Code Optimierung kein einziger Fehler aufgetreten, so dass meiner Meinung nach der Code nun perfekt ist.
Jetzt seid ihr gefragt!
Da ich mit der Funktionsweise von meinen zwei Karten soweit zufrieden bin, möchte ich gerne den nächsten Schritt wagen, und den Code einem breiteren Testpublikum zugänglich machen. Das Ziel muss sein, den Code endlich im Kernel unter zu bringen.
Mit Kaffeine, vdr und anderen Medienplayer Anwendungen kann es allerdings immer noch vorkommen, dass einzelne Senderwechsel nicht auf Anhieb funktionieren. Z.B. wenn diese Apps. die DiseqC-Sequenz nicht 2x senden oder andere Macken bei der Bildentfaltung aufweisen.
Die Testumgebung erklärt
Nach dem entpacken des angehängten Archivs gilt es zuerst den DVB Treiber mit meinen Code Anpassungen neu zu übersetzen:
Egal ob ihr im Moment s2-liplianin oder v4l-dvb einsetzt, könnt ihr die angehängte stb0899_algo.c Datei *komplett* ersetzen. Das ist auch der Grund, warum es im Moment keinen Patch dazu gibt: Der gesamte Tuning Code für DVB-S und DVB-S2 befindet sich in dieser Datei.
Die Tests mittels modifiziertem szap-s2 habe ich mit beiden Treiber Quellen erfolgreich durchgeführt, indem ich ebenfalls nur diese Datei komplett ersetzt habe.
-> Die bei euch vorhandene Datei linux/drivers/media/dvb/frontends/stb0899_algo.c umbenennen in stb0899_algo.c.OLD und in dasselbe Verzeichnis die stb0899_algo.c aus dem Archiv einstellen. Danach make erneut durchlaufen lassen, make install installiert wie gewohnt ins System. Danach empfiehlt es sich das System neu zu starten.
Wer yaVDR mit DKMS verwendet findet eine Bau Anleitung für den Treiber ein paar Posts weiter unten
Das Zap Testprogramm (ich nenne es ezap2, um eine Verwechslung mit szap-s2 zu vermeiden) wird mit einem Shellskript aufgerufen, damit die jeweiligen Parameter immer dieselben sind. Der komplette Output von ezap2 landet in einer Logdatei, was eine Fehleranalyse erst ermöglicht.
Wer ein 64bit System verwendet, muss den Quellcode von ezap2 neu übersetzen, oder er verwendet die Binaries von Midas
Vom Shellskript gibt es 3 Versionen:
1) Skript "short" für 4 Sender (DVB-S/DVB-S2) auf Astra/Hotbird - das soll einem nur eine Idee geben, ob der neue Code (DVB-S/DVB-S2/DiseqC) grundsätzlich schon mal läuft. Wer Hotbird nicht empfängt geht direkt über zu 3)
2) Skript "all" durchläuft eine durchmischte Liste von Astra und Hotbird. (Astra muss auf dem DiseqC Ausgang A liegen, Hotbird auf B) Wer nur eine Anlage für Astra besitzt (die meisten hier vermutlich) geht direkt über zu 3)
3) Skript "zap" Diesem Shellskript wird beim Aufruf die Kanalliste mit übergeben, so dass man flexibel verschiedene Tuning Varianten wechseln kann. (Nur Astra DVB-S, nur Astra DVB-S2, Astra gemischt)
Das Konsolen Programm beep (im apt Repository zu finden) ist nützlich, um nach dem Durchlauf "alarmiert" zu werden - wer das nicht wünscht kommentiert die beep Zeile am Dateiende in den 3 Shellskripts aus. Solltet ihr mehr als eine Karte im System einsetzen, so achtet bitte auf die korrekte Adapter Nummer. Der default ist Adapter 0 für die erste Karte, sofern die stb0899 Karte als Adapter 1 eingebucht wurde, muss der -a Parameter im Shellskript entsprechend angepasst werden.
Wenn man jetzt die Programme mit ./"Skriptname" startet und alles prima läuft, dann rennt ezap2 durch die Kanalliste, und zeigt euch währenddessen folgende Varianten an Status Rückmeldungen (die meisten davon nur im Logfile), gefolgt von einer abschliessenden Zusammenfassung am Ende:
a) Sofortiger Lock im 1. Anlauf (hinterste Spalte hat Wert 0)
b) Lock im 2. Anlauf (hinterste Spalte hat Wert 1)
c) Kein Lock auf diesen Sender möglich
d) Zusammenfassung während dem Tunevorgang und am Ende von ezap2:
lok_errs: Anzahl erfolglose Tuning Versuche
multi: Zählt die Anzahl Locks im 2. Anlauf oder grösser hoch
multi_max: Merkt sich den höchsten multi Wert, im Logfile zu finden in der hintersten Spalte
runs: Anzahl durchlaufene Sender
Locks im 2. Anlauf (multi_max=1) sind nicht ungewöhnlich, weil ezap2 schon nach 10ms die Signalwerte abfragt. Gerade wenn man den Satelliten oder das Band wechselt vergeht mehr Zeit - den Effekt kennt man auch bei der Verwendung von Settop Boxen.
Andere mir bekannte Fehler der Mantis-Karten
Hier soll zum Schluss noch kurz auf andere in der linux-media ML diskutierte Probleme mit den Mantis Karten eingegangen werden:
Die Zahl der ausgelösten Interrupts (Interrupt Polls) ist bei Mantis Karten deutlich höher als notwendig (um den Faktor 4 zu hoch), was die Gefahr einer Race Condition unnötig erhöht. HDTV Streaming übers Netzwerk kann dadurch zum Problem werden. Ausserdem dürftet ihr beim verwenden des Testskripts folgenden Effekt bemerken: Das rasche tunen der DVB-S2 Sender verunmöglicht z.B. eine parallele Audio Wiedergabe. Der Ton stottert und hackt, weil der Audio Player nicht rechtzeitig neue Daten beziehen kann.
Diesem Problem hat sich vor kurzem Marko Ristola angenommen, und in der linux-media ML um Tester gebeten [Link]
Der Patch hat bei mir und Bjørn Mork die erwünschte Wirkung, was ihr z.B. mit dem Tool powertop überprüfen könnt. Danach läuft auch die Audio Wiedergabe problemlos neben dem S2-Code durch.
Einsatz der Mantis Karte in Intel Systemen
Leider musste ich feststellen, dass die Mantis-Treiber auf Intel Hardware (Dual-Core CPU) während der Verwendung von ezap2 nach spätestens 1 Stunde mit einem Stacktrace crashen. Das passiert sowohl mit dem originalen v4l-dvb Code, wie auch mit dem von mir modifizierten Algo. Der DMA Patch sorgte hier nicht für Abhilfe. Ich konnte den Stacktrace mit 2 identischen MSI Boards zuverlässig reproduzieren.
Die von mir täglich verwendeten AMD/ATI Boards (780G/785G Chipsets von ASRock) durchlaufen die Testanordnung mehrmals hintereinander ohne zu murren.
Ich wäre euch dankbar, wenn Ihr die Tests einmal durchlaufen lassen würdet, und die Ergebnisse hier im Forum postet. Speziell die Zusammenfassung am Ende ist interessant, aber auch das eine oder andere Logfile, gerade wenn doch einmal lok_errors auftreten sollten. Die könnt ihr (bitte als Archiv gepackt, die Dinger sind riesig!) an meine hier im Forum hinterlegte Email Adresse schicken.
Wer gerne selber eine Kanalliste erzeugen möchte findet hier die passenden Anleitung, inkl scan-s2