Cine S2 szap Problem

  • Hallo,


    wir haben verschiedene Probleme mit dem ngene Treiber und der Digital Devices Cine S2 Dual DVB-S2 Karte (Linux4Media cineS2 DVB-S2 Twin Tuner) festgestellt. Die Probleme sollten auch die Clones wie die Mystique SaTiX betreffen.


    Wir verwenden den Treiber aus dem linuxTV-Repository http://linuxtv.org/hg/v4l-dv und die Firmwareversion 15 von Digital Devices.


    Die Probleme lassen sich mit szap-s2 reproduzieren, es kann also auch sein, dass die Probleme auch mit dem vdr auftreten.


    Anbei ist die die genaue Problembeschreibung, die an die LinuxTV-Mailingliste gesendet wurde. Die gepatchte Version von szap-s2 zum Reproduzieren der Probleme habe ich diesem Post angehängt.


    Es wäre schön wenn jemand die Probleme bei sich reproduzieren könnte und man eine Lösung findet.


    Gruß,
    Andreas


    *Setup* *******************************************


    OpenSuse Linux 11.0
    Linux anna 2.6.25.20-0.5-pae #1 SMP 2009-08-14 01:48:11 +0200 i686 i686
    i386 GNU/Linux
    DVB drivers: http://linuxtv.org/hg/v4l-dvb (ngene)
    2e0444bf93a4 (changeset 14233:2e0444bf93a4, date: Mon Feb 22 10:58:43
    2010 -0300)


    module loaded with
    modprobe ngene one_adapter=0


    *Usage* *******************************************


    We slightly modified the latest version of szap-s2 (available from
    http://mercurial.intuxication.org/hg/szap-s2/ ); see attached .tar.gz


    tar xvfz modified_szap_s2.tar.gz


    make


    Most importantly, the modified version prints out the total delay in
    seconds of main() to allow for easier debugging.


    *Problem A* *******************************************


    Two running instance of szap-s2 are used:


    a) one for changing channels between "Das Erste" (Astra 19.2E) and
    "ZDF" (Astra 19.2E)


    b) the other one for recording from "Das Erste" (or any other channel)


    Result:


    When only a) is running, channel tuning times between the two
    different transponders of "Das Erste" and "ZDF" are around 0.5
    secs. This is really good.


    However, when b) is started in parallel, these times increase to 1.5
    to 1.8 seconds. This is not good.


    How to reproduce?


    1) in one shell, run


    ./run_szap-s2_adapter0.sh | grep Delay


    You will see


    Delay : 0.560508
    Delay : 0.545771
    Delay : 0.609781
    Delay : 0.593796
    Delay : 0.649772
    Delay : 0.614023
    ..


    2) in parallel in another shell, run


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


    Immediately, you will see in 1)


    Delay : 1.525178
    Delay : 1.781971
    ..


    *Problem B* *******************************************


    After reproducing Problem A, we terminate process 2) by hitting
    Ctrl-C.


    Even then, channel tuning time stay high in process 1), you will still see


    Delay : 1.773303
    Delay : 1.781734
    Delay : 1.749948
    ..


    This is not good.


    *Problem C* *******************************************


    What is even worse:


    Very often, you will soon run into trouble: After a very iterations,
    you will see:


    Delay : 21.616521
    Delay : 21.773475
    Delay : 21.765678


    This means that tuning was not possible anymore at all. In this
    situation, it always helps to re-load the module by runing:


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


    *Problem D* *******************************************


    When terminating process 1) and immediately restarting it, channel
    tuning times - again - stay high. This is not good.


    Often you will also see Problem C then.


    *Problem E* *******************************************


    Go back to reproducing Problem A (process 1 and 2 are running), and
    the continuously start and terminate process 2) by hitting Ctrl-C
    again and again. Sooner or later, you will see Problem C occur then.


    *Remark* *******************************************


    It _seems_ that, after terminating all szap-s2 processes, and waiting 1
    to 2 minutes, and then restarting szap-s2 again, the failures/problems
    seem to be gone _without_ reloading the module.


  • 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

  • Hi,


    bei mir mit einer baugleichen Satix stellt es sich folgend dar:


    Delay : 0.638886
    Delay : 1.685896
    Delay : 1.710820
    Delay : 2.489799
    Delay : 1.791213
    Delay : 2.924617
    .......
    Delay : 2.909785
    Delay : 2.157748
    Delay : 10.869177


    danach Ctrl-C and restart


    aber bleibt gleich hoch:


    Delay : 10.973163
    Delay : 10.973844


    erst nach einer Weile dann wieder:


    Delay : 1.722019
    Delay : 1.706110
    Delay : 1.725573

    1.Ur-VDR - (discontinued) FF TT 1.6 / 1.3, Skystar 2.6B TB Extension Board - Gentoo
    2. POV ION 330 - TBS 6980 Dual DVB S2 - Ubuntu 10.4

    The post was edited 2 times, last by argo ().


  • 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.

  • nur als Info, ist das nun ein reiners Treiberproblem?


    Zusätzlich ist mir noch folgendes aufgefallen: wenn ich auf einem HD-Kanal problemlos Empfang habe, kommt irgendwann, ganz unwillkürlich der TS error, manchmal fängt es sich selbst, andernmals muss man kurz umschalten um dan wieder auf demselben Kanal die TS errors loszuwerden.

    1.Ur-VDR - (discontinued) FF TT 1.6 / 1.3, Skystar 2.6B TB Extension Board - Gentoo
    2. POV ION 330 - TBS 6980 Dual DVB S2 - Ubuntu 10.4

    The post was edited 2 times, last by argo ().

  • Quote

    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.

  • Hallo,


    zunächst einmal vorab:
    Mit VDR ist - jedenfalls bei mir - selbst nach tagelangem Betrieb mit EPG-Scan kein derartiges Problem erkennbar.
    Allerdings öffnet VDR die Devices nur einmal beim Programmstart und macht sie beim Beenden wieder zu. So sollte man auch vorgehen.


    Gibt es eine "richtige" Applikation, mit der diese Probleme auftreten? Welche Applikation ist das?


    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!]


    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.


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


    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.


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


    CU
    Oliver

  • UFO


    dann bist du wohl einer der wenigen, der mit dieser Karte keine Probleme, oder wenig Probleme hat.


    Es ist bekannt das die Karte hardware Probleme hatte und vieleicht auch noch hat. Deine Karte ist womöglich nicht davon betroffen, ich habe sie sogar einmal austauschen lassen habe aber keine Änderung feststellen können.


    Fakt ist, die Karte ist jetzt und so nicht alltagstauglich und ich finde es nicht o.k. wenn ein Hersteller mit linux Kompatiblilität wirbt und danach von der comunity erwartet, dass die die Treiber schreiben....


    Dann lieber eine TBS mit closed source die dafür aber funktioniert!

    1.Ur-VDR - (discontinued) FF TT 1.6 / 1.3, Skystar 2.6B TB Extension Board - Gentoo
    2. POV ION 330 - TBS 6980 Dual DVB S2 - Ubuntu 10.4

  • 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.


    Quote


    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.


    Quote


    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.


    Quote


    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.


    Quote


    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.


    Quote


    @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

  • Sehe ich genauso ..


    Meine 2te Satix Dual die ich direkt vom Entwickler bekommen habe verhält
    sich anders als meine erste Karte bei exakt gleichen Software
    und Hardware Bedingungen.
    Alte Karte raus --> Neue rein


    Bei der Ersten hatte ich wenigstens immer HD Empfang.
    Jetzt garnicht mehr ..
    Dafür scheint die 2te Karte stabiler bei den privaten SD Sendern zu sein.
    Dafür gehen Eins Extra und andere Sender auch nicht mehr.


    So nach einer gefühlten Stunde ist dann auch Schicht im Schacht


    --> "No Signal" auf allen Kanälen.


    Nur Stromlos machen hilft dann eine Weile bis zum nächsten ...


    :( :(

  • Quote

    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?

  • Hallo,
    bei mir treten die beschriebenen Probleme auch auf und ich kann es sogar noch viel einfacherer reproduzieren.



    1) Tune on on Adapter 0
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep
    Delay
    Delay : 0.579985


    wait for a second


    2) Tune on Adapter 1
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -x | grep
    Delay
    Delay : 0.597315


    wait for a second


    3) Tune again in Adapter 1
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -x | grep
    Delay
    Delay : 2.893060


    => Anschliessend habe ich immer ein sehr hohes Delay beim Umschalten. Das Problem scheint also auch aufzutreten, wenn man einfach nur abwechselnd auf den Adpatern tuned.


    => Das Problem sollte dann evtl. auch auftreten, wenn man den VDR neustartet? Z.B. nachdem man zunächst TV (von Adapter 0) schaut, VDR neu startet und anschliessend Adpater 1 verwendet.

  • Quote

    Original von mlo
    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.


    Ok, dann ist ja auch schon klar, warum dieses Problem mit VDR nicht auftritt.



    Sorry, mir war nicht klar, daß es hier einzig darum geht, zu demonstrieren, daß das Öffnen/Schließen ein Problem darstellt.


    Kann mir vorstellen, daß es diesbzgl. noch Probleme geben könnte, denn insbesonders das sofortige Wiederöffnen dürfte sehr schlecht oder gar nicht getestet sein. Gilt vermutlich für fast alle Kartentypen!


    Könnte also sogar ein Problem in dvb-core sein. Und bei Dual-Tuner-Karten kommt erschwerend dazu, daß sich beide Kanäle gewisse HW teilen. Der Fehler könnte also fast überall stecken.


    Wie dem auch sei: Ich habe zur Zeit einfach keine Motivation, meine wenige Freizeit für Probleme, die VDR in keiner Weise tangieren, zu opfern. Vielleicht mag sich ja jemand anders darum kümmern...


    CU
    Oliver


  • Zumindest ist es mir nicht aufgefallen. Was aber nicht unbedingt etwas heißen will, denn ich habe hauptsächlich in Richtung "Command timeout" getestet... :schiel


    Andererseits finde ich dies nicht wirklich überraschend, denn beide Kanäle teilen sich I2C-Bus, ngene, stv0900.


    Edit:
    Man sollte auch berücksichtigen, daß das szap #1 nur einen Kanal einstellt, während #2 wegen "-r" auch Datentransfer aktiviert und die Daten in den Demuxer schickt.


    CU
    Oliver

  • Quote

    Original von UFO
    Zumindest ist es mir nicht aufgefallen. Was aber nicht unbedingt etwas heißen will, denn ich habe hauptsächlich in Richtung "Command timeout" getestet... :schiel


    Habe mit VDR die Zapgeschwindigkeit der cineS2 überprüft:


    Testbedingungen:
    (a) VDR verwendet Tuner #1 der cineS2, Tuner #2 unbenutzt.
    (b) Tuner #1 unbenutzt, VDR verwendet Tuner #2.
    (c) VDR verwendet beide Tuner.


    Die restlichen Tuner des Systems wurden mit Aufnahmen beschäftigt, so daß VDR gezwungen war, den einzig freien Tuner zum Zappen zu verwenden.


    Ergebnis:
    Wenn VDR beide Tuner verwendet (c), ist die Zapgeschwindigkeit (Bild von einem Kanal bis Bild des nächsten Kanals auf einem anderen Transponder) geringfügig langsamer. Bin mir allerdings nicht sicher, ob ich mir dies nur einbilde, der Unterschied war minimal.


    CU
    Oliver


  • 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

  • Quote

    Original von mlo


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


    Nun ja, die Sache mit der Verlangsamung wollte ich dann doch genau wissen.


    Quote


    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 so ist es. VDR wählt selbst den Tuner aus. Wenn man also einen bestimmten zum Zappen nehmen möchte, muß man dafür sorgen, daß alle anderen mit Aufnahmen beschäftigt sind.


    Quote


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


    Diese Zeiten kamen mir gleich seltsam vor (einen Unterschied von 1s hätte mir normalerweise auffallen müssen).
    Ich vermute, daß es mit der Art der Messung in Verbindung mit der Systemlast zusammenhängt.


    Quote


    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 ;)
    Ich denke, daß sich die Zeiten dann relativieren werden.


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


    Nur durch Offenhalten der Devices kann man verhindern, daß eine andere Anwendung das Gerät in Besitz nimmt.


    Wenn man "frontendX" schließt, signalisiert man dem Treiber, daß die Applikation den entsprechenden Kanal nicht mehr benötigt. Je nach Treiberimplementierung wird dann die HW in Energiesparmodus geschaltet und die LNB-Spannung abgeschaltet.


    Quote


    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.


    Alles hängt davon ab, was im Treiber implementiert ist. Wenn kein Powersave implementiert ist, kann da auch nichts schief gehen. Viele ältere Treiber tun einfach gar nichts. :schiel


    Die Karten arbeiten unabhängig voneinander, d.h. es sollte - abgesehen von Ressourcenbedarf - keine Rolle spielen, ob 1, 2 oder mehr verbaut sind.


    Quote


    Dann interessiert mich noch: Hast du eine Idee wo wir nach der Ursache des Problems im Treiber suchen müssen?


    Da es mit open/close zu tun hat, müßte man in dvb_frontend.c/stv090x.c ansetzen.


    Man könnte auch einmal dvb-core mit

    Code
    1. dvb_powerdown_on_sleep=0


    starten und sehen, ob sich etwas ändert.


    Quote


    Was könnte man noch im Treiber verbessern? Was sind dir bekannte Bugs? usw.


    Imho läuft der Treiber sehr gut. Ich kann keine Abstürze o.ä. beobachten. (Früher hat es z.T. Jahre gedauert, bis ein DVB-Treiber richtig stabil war. Da die Hersteller mittlerweile Interesse an stabilen Linuxtreibern haben, hat sich die Situation wesentlich verbessert.)


    was sonst so berichtet wird:
    - open/close-Bug
    - Vereinzelt wird die Empfindlichkeit des Tuners beanstandet. An den Parametern wird in einem anderen Thread gebastelt. Warte auf Rückmeldung.
    - Bei manchen Mainboards verhindert die Karte angeblich das Herunterfahren (Voodoo???).


    Quote


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


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


    CU
    Oliver