[patch] Dvb-t Fixes

  • Hallo,


    ich hab mal wieder ein weng rumprobiert bezüglich der Prbleme mit DVB-T. (ARM crash, Black screen etc.) und mal einen Patch erstellt.


    Der Patch macht folgendes:


    Erstens integriert er die Möglichkeit, im VDR einzustellen, mit welchem Kanal dieser gestartet wird (Patch ursprünglich von ???).


    WICHTIG: Unter Einstellungen/Sonstiges Bitte einen DVB-C oder DVB-S Kanal einstellen, der von der Primären Karte kommt.


    Zweitens hab ich den Check herausgenommen, der überprüft, ob ein Lock auf dem FE passiert ist.


    Scheinbar gibts da Probleme in Bezug auf DVB-T.


    Ich habe jetzt meinen VDR so seit ca. 3 Tagen durchweg laufen, und bisher läuft das Teil absolute Sahne. Keine Probleme mehr, keine ARM crashes etc. Aufnahmen wurden auch einwandfrei in der Zeit gemacht.


    Deshalb, bitte alle mit DVB-T Problemen testen. Es ist noch ein weiterer Patch mit im Diff und zwar der vom DVD Plugin. Bitte das Diff auf einen vanilla VDR anwenden.

  • Geht der Patch auch für 1.3.23 ??

    Asus Pundit-S 2600 - Celeron 2,6 GHz - 512 MB - Samsung 160 GB - NEC DVD-+RW 1300 - WinTV Nova-T (alt) - DXR3 (Creative);
    c't3 - tobi Distri experimental (Sarge)/ VDR 1.4.x + (DXR3 oder em84xx 4MB bin am testen) , Streamdev, LIRC

  • Zitat

    Original von neumann2k
    Erstens integriert er die Möglichkeit, im VDR einzustellen, mit welchem Kanal dieser gestartet wird (Patch ursprünglich von ???).


    Meine Wenigkeit ;)

  • Zitat

    WICHTIG: Unter Einstellungen/Sonstiges Bitte einen DVB-C oder DVB-S Kanal einstellen, der von der Primären Karte kommt.


    Was sollte man einstellen, wenn man nur DVB-T Karten hat?

    yavdr 0.5 :: Mainboard: Point of View POV/ION330 :: 2 GB RAM :: TT Connect S2-3600 HDTV-S2 USB :: Gehäuse: In-Win BM639 mit 120W Netzteil :: atric IR-Einschalter :: FB: Hauppauge :: Hama Nano-Bluetooth-USB-Adapter :: Logitech Cordless MediaBoard Pro

  • ich habe eine FF DVB-T Karte und einen DVB-T Budget Karte.

    yavdr 0.5 :: Mainboard: Point of View POV/ION330 :: 2 GB RAM :: TT Connect S2-3600 HDTV-S2 USB :: Gehäuse: In-Win BM639 mit 120W Netzteil :: atric IR-Einschalter :: FB: Hauppauge :: Hama Nano-Bluetooth-USB-Adapter :: Logitech Cordless MediaBoard Pro

  • Super, darauf habe ich schon lange gewartet. Frueher lief mein vdr mit kernel 2.6.8.1 perfekt aber nach nachdem ich ihn neu mit 2.6.11 aufgesetzt hab, laeuft er ueberhaupt nicht stabil. Andauernd solche meldungen im log: device1 has no lock.
    Deswegen meine frage auch: funktioniert der patch auch mit vdr1.3.23?


    danke fuer deine Muehen!


    gruss
    jan

  • Zitat

    Original von loswillios
    Deswegen meine frage auch: funktioniert der patch auch mit vdr1.3.23?


    hab ihn eben gerade eingespielt, zusammen mit lnbsharing, scheint zu laufen, also das Zappen ist irre schnell geworden nun.
    Ich habe beim ersten mal nicht übeall einen Lock gehabt, aber nach 2-4mal zappen war sofort alles da.

  • Zitat

    Original von Torsten/WarEagle


    hab ihn eben gerade eingespielt, zusammen mit lnbsharing, scheint zu laufen, also das Zappen ist irre schnell geworden nun.
    Ich habe beim ersten mal nicht übeall einen Lock gehabt, aber nach 2-4mal zappen war sofort alles da.


    Hi,


    das Verhalten ist normal. Da die DVB-T Karten manchmal nicht schnell einen Lock bekommen (oder besser gesagt das Frontend), reicht es aus, auf dem Sender ein paar Sekunden zu verweilen. Dann sollte auch ein Bild kommen. Es ist also nicht nötig, wieder auf diesen Sender zu zappen.

  • Zitat

    Original von neumann2k
    Da die DVB-T Karten manchmal nicht schnell einen Lock bekommen (oder besser gesagt das Frontend), reicht es aus, auf dem Sender ein paar Sekunden zu verweilen.


    Welchen DVB-Treiber benutzt Du eigentlich? 1.0.1 oder dvb-Kernel? Ich habe den 1.0.1 in der aktuellen CVS-Version (mit AC3-Firmware) unter 2.4.21 laufen und habe eigentlich sehr schnelle Umschaltzeiten. Unter Linvdr 0.7 mit aktuellen dvb-Kernel-Treibern dauert`s länger!

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Zitat

    Original von Dr. Seltsam


    Welchen DVB-Treiber benutzt Du eigentlich? 1.0.1 oder dvb-Kernel? Ich habe den 1.0.1 in der aktuellen CVS-Version (mit AC3-Firmware) unter 2.4.21 laufen und habe eigentlich sehr schnelle Umschaltzeiten. Unter Linvdr 0.7 mit aktuellen dvb-Kernel-Treibern dauert`s länger!


    Hi,


    also ich habe 2.6.11 mit aktuellen dvb-kernel treibern drauf.


    Ich habe aber auch alle möglichen Alternativen durch. Bei VDR 1.2.6 und alten HEAD treibern (2.4 Kernel) hab ich auch sehr schnelle Umschaltzeiten, dafür aber trotzdem ARM crashes.


    Mit der jetzigen Kombination und dem Patch läuft bisher *toitoitoi* alles stabil.


    Aber das alles ist natürlich nur ein Workaround. Der Hase scheint da wohl sehr tief im Pfeffer zu liegen.

  • Hi,


    klingt ja interessant. Ich hätte nur ein Frage: Du entfernst mit dem Patch auch irgenwas mit SpuDecoder:Scale..., Letterbox, Scale usw. was genau macht das, bzw. wieso sollte es raus?


    Ciao
    UloPe

  • Zitat

    Original von neumann2k
    das Verhalten ist normal. Da die DVB-T Karten manchmal nicht schnell einen Lock bekommen (oder besser gesagt das Frontend), reicht es aus, auf dem Sender ein paar Sekunden zu verweilen. Dann sollte auch ein Bild kommen. Es ist also nicht nötig, wieder auf diesen Sender zu zappen.


    Achso, werd ich mal testen, ohne den patch brachte das nämlich absolut nix, daher bin ich gewohnt zu zappen.
    Werds mal intensiv beobachten, bisher ists (selbst wenn noch etwas auffallen sollte) 1000mal besser als vorher.

  • Zitat

    Original von UloPe
    Hi,


    klingt ja interessant. Ich hätte nur ein Frage: Du entfernst mit dem Patch auch irgenwas mit SpuDecoder:Scale..., Letterbox, Scale usw. was genau macht das, bzw. wieso sollte es raus?


    Ciao
    UloPe


    Hi,


    das kommt vom Patch aus dem DVD Plugin. Hatte ich mit drin, ist aber für das Problem irrelevant.


    Kommt wie gesagt, vom DVD Plugin.

  • Zitat

    Original von Torsten/WarEagle


    Achso, werd ich mal testen, ohne den patch brachte das nämlich absolut nix, daher bin ich gewohnt zu zappen.
    Werds mal intensiv beobachten, bisher ists (selbst wenn noch etwas auffallen sollte) 1000mal besser als vorher.


    Ja, vorher war das so. Wenn VDR gemerkt hat, dass die Karte innerhalb einer gewissen Zeit keinen Lock bekommt, wird kein Receiver Thread gestartet, infolgedessen hat man für immer einen schwarzen Schirm.


    Da ich diesen Check wieder entfernt habe, schaltet VDR jetzt ganz schnell um (weil er nicht wartet, bis das FE einen Lock hat) und nach einer Zeit sollte dann auch was auf dem Bildschirm kommen. Je nach Karte mal langsamer mal schneller.


    Der Effekt früher war ja, dass es teilweise ewig dauerte, bis man umgeschaltet hatte und dann kam nix.

  • Hallo,


    danke für den patch, habe jetzt nur noch manchmal beim
    zappen ein Schwarzen Schirm (liegt aber am schwachen Signal),
    aber man kann ja jetzt schnell hin und her schalten :)



    Ich habe den Patch noch mal ohne DVD-Patch angehangen, den
    braucht man ja nur wenn man das DVD-Plugin in der CVS-Version nimmt.



    Das Hauptproblem ist aber scheinbar der Treiber (Tuningverhalten).
    Unter Windows kann ich mit meiner Karte ohne probleme zwischen den
    Frequnzen hin und her zappen und das Bild kommt ca. 1 Sekunde Später,
    unter Linux bekommt der Treiber keinen lock oder sehr spät.


    Gruss


    Marcus

  • Zitat

    Original von neumann2k
    Da ich diesen Check wieder entfernt habe, schaltet VDR jetzt ganz schnell um (weil er nicht wartet, bis das FE einen Lock hat) und nach einer Zeit sollte dann auch was auf dem Bildschirm kommen. Je nach Karte mal langsamer mal schneller.


    Ja, aber, aber, aber - Huch, das verwirrt mich jetzt doch. Diese ganze Sache, mit dem Warten auf das Lock, die ist doch erst mit vdr Vers. 1.3.5 oder so reingekommen, und zwar, um die UPT Errors zu vermeiden.
    Wenn ich es richtig verstanden habe, vertragen die DVB-S es nicht, wenn der vdr versucht, pid-Filter zu setzen, wenn das Frontend noch kein Lock hat.
    Und genau diese Mimik wird jetzt wieder abgeschaltet durch den Patch. Das würde ja bedeuten, dass jemand, der eine Kombination aus DVB-S und DVB-T hat, sich wieder potentielle Probleme auf der Sat-Seite einhandelt (wahrscheinlich bei schlechten Empangsbedingungen).

  • Zitat

    Original von TheAlamo


    Ja, aber, aber, aber - Huch, das verwirrt mich jetzt doch. Diese ganze Sache, mit dem Warten auf das Lock, die ist doch erst mit vdr Vers. 1.3.5 oder so reingekommen, und zwar, um die UPT Errors zu vermeiden.
    Wenn ich es richtig verstanden habe, vertragen die DVB-S es nicht, wenn der vdr versucht, pid-Filter zu setzen, wenn das Frontend noch kein Lock hat.
    Und genau diese Mimik wird jetzt wieder abgeschaltet durch den Patch. Das würde ja bedeuten, dass jemand, der eine Kombination aus DVB-S und DVB-T hat, sich wieder potentielle Probleme auf der Sat-Seite einhandelt (wahrscheinlich bei schlechten Empangsbedingungen).


    Ja, da gebe ich Dir Recht. Das ist so. Allerdings weiß ich mir nicht anders zu helfen :)

  • Ich weiss nicht ob es interessiert, aber seit ich an meine Lorenzen eine Kathrein DVB-T Antenne angeschlossen habe, bekomme ich keine ARM- Crashes noch sonstige Fehler mehr! Hat zwar nichts mit den Patches hier zu tun, aber vielleicht hilfts jemand.


    Steffen

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!