Beiträge von mlo

    Hallo,


    ich versuche nun schon einige Zeit, die Media-Pointer / Digital Device Cine2 DVB-S2 Dualtuner Karte vernünftig zum Laufen zu bekommen:


    Hauptproblem ist: Wenn man beide Tuner der Karte verwendet (z.B. ein Tuner macht eine Aufnahme, der andere wird für Live-TV und Zapping verwendet) dann sind die Umschaltzeiten extrem schlecht.


    Mittlerweile konnte ich das Problem soweit eingrenzen, dass man es mit einem leicht modifiziertem szap-s2 reproduzieren kann.


    Ich habe damit:
    - Verschiedene Treiber probiert (auch die von User UFO empfohlenen)
    - Verschiedene Kernel (auch den von User UFO empfohlenen)
    - Alle mir zur Verfügung stehenden Firmware Versionen (15, 17, ..)
    - Verschiedene Hardware (PCs)
    - Verschiedene Karten (auch die neuste Hardware Revision V5.5 statt V5.4 von Digital Devices)
    - Verschiedene Sat-Anlagen (teure Anlagen mit DVB-Switch, und einfache Anlagen aus dem Baumarkt)


    ... aber immer mit dem gleichen schlechten Ergebnis.


    (Ich habe auch 2xSingle- oder 1xDualtuner Karten von anderen Herstellern getestet, und konnte das Problem bei _keiner_ anderen Karte reproduzieren...)


    Trotzdem kann ich nicht ausschließen, dass es an meiner Konfiguration liegt. Deshalb meine große Bitte:


    Bitte testet das mal bei Euch und schickt die Ergebnisse rum. Danke!


    Angehängt ist ein .tar.gz Archiv. Verwendung:


    tar xvfz modified_szap_s2.tar.gz
    make


    eventuell muss man daring folgende Zeile anpassen
    INCLUDE=-I/usr/src/linux/include/


    Alles weitere zum Test steht in der Datei PROBLEMS.txt


    Nochmal: Vielen Dank für Eure Hilfe! Gruß, Marco

    Zitat

    Originally posted by UFO
    Einen weiteren Bug habe ich am Wochenende gefixt:
    - Kein Low-Band-Empfang möglich.
    Ich weiß aber nur von 3 Leuten, wo dies auftrat.


    Ja, haben wir schon gesehen.


    Vielen Dank für den schnellen Fix auch von unserer Seite.

    Zitat

    Originally posted by UFO
    Ich kann keine so langsamen Umschaltzeiten bestätigen. Bei meinen Tests achte ich darauf, wenn das Bild kommt.


    Möglicherweise tunt die Karte also schnell, es dauert jedoch aus irgendeinem Grund lange, bis "Lock" angezeigt wird.


    Hmm, das hört sich ja eigentlich gut an, wenn du das Problem so nicht hast.


    Andererseits haben nun schon verschiedene Leute diese langen Umschaltzeiten mit szap-s2 reproduziert.


    Mit dem Oben angehängten .tar.gz kann man das ja auch in 2-3 Minuten schnell ausprobieren.


    UFO: Was für Zeiten bekommst du denn damit?


    Ja, den open/close-Bug können wir auch bestätigen. Gibt es dazu hier noch weitere Threads/Posts?


    Dann haben wir am Wochenende einen weiteren Bug gefunden:


    Wenn man direkt nach dem Kanalwechsel/Transponderwechsel Daten vom dvr Device liest, dann kommt es etwa in einem von 50 Fällen vor, dass man noch "alte" Daten kommt - obwohl das Tunen bereits abgeschlossen ist. Mit "alte Daten" meine ich, dass man noch Daten des vorherigen Transponders bekommt.


    Das hat sehr "unschöne" Auswirkungen, inklusive TS-Discontinuity Fehler, da ja noch ein paar "alte" TS Pakete empfangen werden, und dann direkt "neue", oder es wird noch eine "alte" PAT empfangen, so dass der Kanalsuchlauf Kanäle nicht findet, usw.


    Diesen Bug können wir auf _keiner_ der anderen der von uns getesteten Karten reproduzieren (TT, Tevii, KNC, ...) (Ja, ich weiß, das habe ich schon mal geschrieben, aber wenn man einen möglichen Bug findet, dann sollte man so fair sein, einen Gegentest mit einer anderen Karte zu machen, ansonsten bekommt man oft nur als Antwort: "Nee, ich kann dein Problem nicht reproduzieren")


    Klar, man kann jetzt einfach einen work-around einbauen: Einfach nach dem Kanalwechsel 1 Sekunde warten (per sleep) und erst dann Daten lesen, hat das Problem behoben. Das erhöht halt nochmal die Kanalwechselzeiten ...


    Nein es hängt sicher nicht mit der Systemlast zusammen (ich verwende nur szap-s2 auf einem schnellen System, und sonst nichts CPU- oder IO-lastiges)


    Die guten Nachrichten: Ja, ich kann reproduzieren: Wenn man das frontend device nicht schließt, dann treten keine timeouts bzw. Hänger des Treibers auf, die ein Neuladen des Treibers nötig machen.


    Die schlechten Nachrichten: Ich habe szap-s2 noch eine Zeitmessung nur der Funktion zap_to eingebaut und das Programm mit "-i" im interaktiven Modus gestartet, so dass man TV-Sendernamen auf der Kommandozeile eingeben kann (siehe Anhang .tar.gz).


    Problem: Auch wenn man alle devices offen lässt, hat man die _schlechten_ Umschaltzeiten von rund 1.7 - 1.8 Sekunden (alle Details im angehängten PROBLEMS.txt)


    Ich vermute mal, deshalb hast du in deinen Tests keinen Unterschied gemerkt: Die Umschaltzeiten sind einfach immer so groß mit dieser Karte/Treiber, da ja der vdr direkt alle devices öffnet (egal ob verwendet oder nicht).


    Somit hat man im vdr _immer_ die _schlechten_ Umschaltzeiten, auch wenn man effektiv nur einen Tuner verwendet.


    Das ist doppelt schade: Zum einen haben wir auf allen von uns in den letzten Jahren gemessenen Karten (KNC, Tevii, ..) immer sehr viel bessere Umschaltzeiten gehabt, z.B. 0.7 Sekunden beim Transponderwechsel.


    Andererseits ist uns weiterhin unklar, ob man mit dieser Karte/Treiber überhaupt jemals Umschaltzeiten von 0.7 Sekunden bei _gleichzeitiger_ Verwendung _beider_ Tuner schaffen kann. Umso trauriger, da man ja mit nur einem verwendeten Tuner sehr gute Werte von nur 0.5 Sekunden bekommt.


    Wir werden Euch über Fortschritte - und neue Probleme - weiter auf dem Laufenden halten.


    Gruß, Marco


    Hallo Oliver, danke dass du Dir die Mühe gemacht hast, das zu testen.


    Was genau meinst du denn mit (c) : Wir hier wirklich von beiden Tunern Daten gelesen? Z.B. auf Tuner1 läuft eine Aufnahme, und mit Tuner2 zappst du? Genau bei diesem Test hatten wir nämlich 3mal so große Zapping Zeiten (statt 0.5 Sek. sind es 1.5 bis 1.8 Sek.)


    Ich werde versuchen, dass mit szap-s2 nachzustellen, also mehrfach in einem Start von szap-s2 und ohne Schließen der devices auf einem Tuner dauernd umschalten und Daten lesen, und vom anderen Tuner Daten lesen. (Dann werde ich wirklich nur das Tunen messen und nicht mehr das Einlesen der channels.conf ;)


    Muss man wirklich alle 3 devices die ganze Zeit offen lassen, um das Problem zu vermeiden?


    Generell wollen wir versuchen den Treiber zu verbessern und zu optimieren. Denn die Probleme mit dem Öffnen/Schließen der devices haben wir nur mit dieser Karte/Treiber festgestellt - alle anderen von uns getesteten Karten (KNC, Tevii, ...) haben dieses Problem nicht, auch nicht wenn man mehrere davon in einem Rechner betreibt.


    Dann interessiert mich noch: Hast du eine Idee wo wir nach der Ursache des Problems im Treiber suchen müssen? Was könnte man noch im Treiber verbessern? Was sind dir bekannte Bugs? usw.


    Und: Wer möchte / kann bei der Entwicklung helfen?


    Vielen Dank für deine Hilfe, Gruß, Marco

    Zitat

    Originally posted by UFO
    Hallo,


    zunächst einmal vorab:
    Mit VDR ist - jedenfalls bei mir - selbst nach tagelangem Betrieb mit EPG-Scan kein derartiges Problem erkennbar.


    Entschuldige, aber in meiner vorherigen Antwort habe ich etwas vergessen:


    Was ist mit dem Problem, dass das Tunen auf einem Tuner langsamer wird, wenn der zweite Tuner in Verwendung ist? In unseren Tests (ja, inklusive Auslesen channels.conf) steigt die Tuning-Zeit beim Transponderwechsel von 0.5 Sekunden auf 1,5 bis 1,8 Sekunden.


    Hat man dieses Problem im vdr nicht?

    Vorab: Wir sind einfach nur daran interessiert die Karte unter Linux vollständig nutzen zu können. Wir helfen gerne mit Tests und - in beschränktem Umfang - auch bei der Verbesserung des Treibers selbst.



    Das Problem tritt immer dann auf, wenn eine Anwendung einen Tuner verwendet, und diese Anwendung dann ganz normal beendet wird - denn dabei sollte die Anwendung alle devices schließen. Das ist in meinen Augen eine "normale" und "richtige" Anwendung.


    Zitat


    Die hier eingeschlagene Vorgehensweise mit szap2 erscheint mir fragwürdig:


    [1) Die gemessene Zeit beinhaltet alles Mögliche, sogar das Lesen der Datei channel.conf!]


    Das ist vollkommen korrekt. Die Ausgabe der Zeit sollte auch keinerlei Benchmark darstellen, sondern dient lediglich dazu, schnell und einfach zu sehen, wenn das Problem auftritt. Deshalb wurde einfach ganz am Anfang und ganz am Ende von main() eine Zeitmessung eingebaut.


    Zitat


    2) Beim Beenden von szap wird das Frontend-Device geschlossen und die Frontend-Shutdown-Sequenz beginnt zu laufen. Bei diesen Tests wird das Frontend-Device ständig geöffnet und geschlossen. Dies ist unüblich und nicht zu empfehlen.


    Warum? Ich denke, das Öffnen und Schließen eines devices, und nochmaliges Öffnen, usw. sollte funktionieren.


    Zitat


    3) Ein realistischer Test würde das Frontend offen halten und einfach zwischen zwei Kanälen hin- und herschalten.


    Das mag ja sein, da es sich aber um ein Dualtuner board handelt, sollte es auch erlaubt sein, einen der beiden Tuner zu öffnen und nach einer Weile wieder zu schließen, ohne dass das Verhalten des anderen Tuners dadurch beeinflusst wird. Aber genau das ist nicht der Fall - es kommt zu den beschriebenen Problemen.


    Zitat


    4) Wenn man Daten vom Treiber haben möchte, muß man das Frontend-Device offen halten. Andernfalls fährt das Frontend herunter und es kommt nichts mehr.


    Das Problem tritt auch auf wenn man _zwei_ Karten (also vier Tuner) in einem System verwendet.


    Zitat


    @Moderatoren:
    Würdet ihr das alles bitte in einen separaten Thread verschieben? Danke! :)


    Es tut mir leid, wenn dies hier der falsche Thread ist.


    Gruß, Marco

    Zitat

    Originally posted by argo
    nur als Info, ist das nun ein reiners Treiberproblem?


    Kann ich überhaupt nicht einschätzen; wir versuchen gerade nur das Problem soweit wie möglich zu verstehen, und soweit zu dokumentieren, dass der Hersteller bzw. Treiberentwickler daran arbeiten kann.


    Danke, damit können wir dann relativ sicher sein, dass es nicht an einer falschen Konfiguration/Treiberversion/Kernel, etc. liegt.


    Das Problem mit den Zeiten > 10 Sek. ist auch: Dann wird der Kanal gar nicht getunt.


    Was wir mittlerweile rausgefunden haben:


    Das Problem tritt noch viel "einfacher" aus: Man muss lediglich adapter0 (=Tuner 1) öffnen und wieder schließen, dann adapter1 ( = Tuner 2) öffnen und wieder schließen. Ab diesem Zeitpunkt besteht das Problem und führt sehr schnell zu Timeouts, etc.



    Das äussert sich auch so: Liest man über adapter0 Daten (z.B. für eine TV-Aufnahme), ändert dann den Kanal von adapter1 (d.h. öffnen, tunen, schließen) dann kommt es nach circa 60 Sekunden dazu, dass man _keine_ Daten mehr von adapter0 mehr erhält.


    Ich habe noch eine Möglichkeit gefunden, alle Probleme noch einfacher und schneller zu reproduzieren. Die Beschreibung Unten verwendet auch die leicht ge-patchte Version von szap-s2 und die Skripte aus dem tar.gz : http://www.vdr-portal.de/board…nt.php?attachmentid=24599


    Kann jemand bestätigen, dass diese Probleme auch auf anderen Systemen und Konfigurationen auftreten?


    Vielen Dank! Gruß, Marco


    0) su -c "rmmod ngene && modprobe ngene one_adapter=0"


    1) ./run_szap-s2_adapter0.sh | grep Delay


    2) in parallel to 1)


    szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r -Q 7


    (better: by adding "-Q" the program is terminated, and all devices are
    closed
    after approx. 8 to 9 secs)


    => while 2) is running 1) will show increased tuning times


    Delay : 0.541970
    Delay : 0.606943
    Delay : 1.410069 [ HERE 2) was started ]
    Delay : 1.369592
    Delay : 1.261879
    Delay : 1.766680


    3) after 2) has terminated simply let 1) continue for 30-40 iterations. you
    will see


    ..
    Delay : 1.845793
    Delay : 1.772285
    Delay : 2.045703
    Delay : 1.817985
    Delay : 0.982030
    Delay : 1.769856
    Delay : 1.769782
    Delay : 0.537857
    Delay : 21.628382


    4) At this point, immediately press Ctrl-C and restart 1) - you will see


    Delay : 0.577599
    Delay : 0.549717
    Delay : 0.593816
    Delay : 0.593758
    Delay : 0.549584
    Delay : 0.546012


    ==> BAD: Problem seems to happen due to one adapter being opened and closed
    again


    ==> GOOD: we are now able to easily and quickly reproduce both problems
    without
    Ctrl-C