LinVDR 0.7: Kein Bild von DVB-T

  • tja, so ist Cooper halt. Der Ton macht die Musik, und da fühlte er sich wohl leicht angep... ;)


    Das Problem ist aber wirklich da, und wohl auch nicht ganz einfach zu lösen.


    Die Treiber müssen nicht unbedingt schuld sein, obwohl die Umschaltzeit m.E. immer noch einen Tick schlechter ist als bei dem alten HEAD-Zweig für Kernel 2.4.


    Vdr selbst ist auch betroffen: siehe
    http://www.vdrportal.de/board/thread.php?threadid=33238
    Das Statement von "TheAlamo" vom 26.04.2005 23:19 trifft den Punkt.


    Ich sehe 3 Lösungen:
    -Entweder schaffen es die DVB-Treiber-Entwickler, dass die Karte auch mit dvb-kernel schnell einen Lock bekommt (was beim alten Treiber der Fall ist)
    -oder man nutzt eine speziell für DVB-T kompilierte Variante ohne die Prüfung, ob es einen Lock gibt


    -oder man findet die Stelle in den vdr-sourcen, die die Wartezeit definiert und setzt diese etwas höher

    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

  • Also so wie ich das verstehe, geht das ganze weit über Linvdr hinaus und betrifft ausschließlich DVB-t Karten bzw. deren Treiber? Muss gestehen daß ich hier relativ selten mitlese, wenn ich nicht gerad ein Problem an der Kiste habe. Schon gar nicht in den Unterforen der anderen Distributionen.
    Na ja, wenn es also schon einmal besser war mit den älteren Treibern, und mit der zunehmenden Verbreitung von DVB-t besteht ja vielleicht Hoffnung, irgendwann einmal den gleichen Komfort wie auf den C und S Karten zu haben. *träum*


    Gruß
    Oppee

  • Hallo,


    für mich als reinen DVB-T Nutzer ist das Problem gelöst. Der Hinweis von Dr. Seltsam hat für mich die Lösung gebracht. Vielen vielen Dank!!!


    Ich lasse den vdr nicht mehr auf ein Lock der Karte warten:
    in device.c der vdr-sourcen habe ich die Funktion
    bool cDevice::AttachReceiver(cReceiver *Receiver)
    so angepasst, dass nicht mehr auf ein Lock gewartet wird.


    Vorgehen:
    - Kernel Sourcen der DarkAngel Version installiert
    - Sourcen meines aktuellen MT-Patches installiert
    - Compiler, make, etc., wie auf LinVDR.org beschrieben installiert
    - ein paar symlinks gesetzt
    - device.c angepasst
    - vdr neu kompiliert und installiert
    -> Problem weg, juhu!!


    Bleibt nur zu hoffen, das es bald einen (darkangel) 2.6.12 Kernel gibt, in diesem hat sich, wie ich gesehen habe, auch etwas an den relevanten DVB Treibern geändert. Vielleicht geht ja mit diesen der Tune-Vorgang der DVB-T Karten schneller.


    Ich bin sehr froh, dass ich bei LinVDR bleiben kann, tolle Distro! Auf tieferes Einsteigen hatte ich auch gar keine Lust, in meiner Freizeit will ich bei Bedarf mal gerne Fernsehen, aber nicht auch noch rumhacken...


    Nochmals vielen Dank für die Hilfe!


    Gruß
    acid

    athlon xp 2500+ :: asus a7n8x-x :: 512MB RAM :: Maxtor 250 GB HD :: Silverstone LC03 :: TT DVB-S 1.6 FF :: 2x TT DVB-T 1300 budget :: linvdr 0.7 :: linvdr-0.7-mt-1.3.23-20050403 :: One for all URC-7030

  • prima! vielleicht kannst Du die neue vdr-datei ja irgendwo zum Download bereitstellen? Gibt bestimmt noch mehr, die das interessiert.


    Gibt`s eigentlich beim Umschalten ein Stotter-Problem? Wenn man sowieso ein spezielles vdr-binary für DVB-T benutzt, könnte man evtl. auch den Buffer allgemein etwas erhöhen (wie es für das Analogtv-Plugin gemacht wird).
    siehe http://www.vdr-portal.de/board/thread.php?threadid=34249
    1024k ist m.E. aber zuviel. Vielleicht mal 576 nehmen.


    Beim MT-Patch vom 18.5. fehlt der Patch für analogtv übrigens, die Sourcen sind zumindest in dieser Hinsicht noch plain-vanilla.

    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


    -oder man findet die Stelle in den vdr-sourcen, die die Wartezeit definiert und setzt diese etwas höher


    o.k., das ist in device.c

    Code
    #define TUNER_LOCK_TIMEOUT 5000 // ms


    Das heißt, die Umschaltdauer muss 5 Sekunden übersteigen, damit das Problem auftritt? Na ja, in den einschlägigen Testberichten von DVB-T-Karten hat die beste Karte 3 Sekunden Umschaltzeit bei unterschiedlichen Transpondern. Die schlechtesten liegen bei 5 und 6 Sekunden, das kann dann wirklich schon eng werden. Das sind Umschaltzeiten bei Windows-Treibern, aber anscheinend sind die aktuellen Linux-Treiber aus dem CVS nicht besser. Dass es bei DVB-T nicht so flott wie bei C oder S geht, ist ja bekannt.
    Man könnte also auch den obigen Wert einfach auf 10000 erhöhen, wenn man auf die Lock-Prüfung in gemischten Systemen nicht verzichten will.


    Aber 10 Sekunden Umschaltzeit? Mann, das ist heftig...

    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

  • Irgendie widerstrebt mir es, ein binary ohne sourcen, GPL Licence, etc. zum download anzubieten. Wer das Binary des vdr für linvdr-0.7-mt-1.3.23-20050414 will, kann mich ja kontaktieren. Eine saubere Lösung wäre das ganze über /etc/vdr/setup.conf zu steuern:
    a la:
    device.wait_for_lock=<0|1>
    device.wait_for_lock_timeout=<xxx ms>


    Ich sehe mir morgen nochmal device.c etc. an, ob man das ganze noch ahängig von der Art des device (nur DVB-T) steuern kann...


    Ich muss sagen, ich bin absuluter Neuling mir Linux basiertem Fernsehen, seit ich anfang Juni zwangsweise von analog auf DVB-T wechseln mußte. Das Forum hier ist echt super, nur die Suchfunktion könnte besser sein. Man will ja nicht mit Standard-Problemen rumnerven...
    So ein "Patch" für DVB-T könnte ja in die MT-Patches mit einfließen, wie ist da der offizielle Weg?


    Gruß
    acid


    P.S.: "Der aktuelle DVB-Treiber aus dem CVS" damit meinst Du den von Linuxtv.org? So wie ich das verstehe, haben inzwischen die DVB-Treiber Einzug in den aktuellen Kerneltree gehalten, und sind dort am aktuellsten (siehe Kernel 2.6.12). Bitte korrigiere mich, falls ich hier falsch liege.
    Stotterprobleme hatte ich bisher nicht. Die Tune-Dauer variiert bei mir stark, bis zu ca. 10 Sekunden beim Bouquet-Wechsel, meistens geht es aber viel schneller.

    athlon xp 2500+ :: asus a7n8x-x :: 512MB RAM :: Maxtor 250 GB HD :: Silverstone LC03 :: TT DVB-S 1.6 FF :: 2x TT DVB-T 1300 budget :: linvdr 0.7 :: linvdr-0.7-mt-1.3.23-20050403 :: One for all URC-7030

    2 Mal editiert, zuletzt von acidbabe ()

  • Zitat

    Original von acidbabe


    So ein "Patch" für DVB-T könnte ja in die MT-Patches mit einfließen, wie ist da der offizielle Weg?


    MT fragen :)
    Aber er hat ja schon erklärt, dass es mangels Zeit erstmal keine neuen Patches mehr geben wird. Falls man die Lock-Prüffunktion selektiv (nur für DVB-T) abschalten/verändern könnte, wäre das ideal. Oder per Menü. Ansonsten hätte man das Problem, dass die C oder S-Nutzer vielleicht wieder Probleme (UPT etc.) kriegen.


    Zitat


    P.S.: "Der aktuelle DVB-Treiber aus dem CVS" damit meinst Du den von Linuxtv.org? So wie ich das verstehe, haben inzwischen die DVB-Treiber Einzug in den aktuellen Kerneltree gehalten, und sind dort am aktuellsten (siehe Kernel 2.6.12). Bitte korrigiere mich, falls ich hier falsch liege.


    Die Entwickler basteln fast täglich an den Treibern rum, so dass man über das CVS von Linuxtv.org immer den neuesten Stand hat. Wobei neu nicht immer besser sein muss.... das große Problem ist, dass seit Monaten (Jahren?) keine stabilen Zwischenversionen veröffentlicht werden. Die Treiber sind in Dauer-Entwicklung. Irgendwann geht dann ein Entwicklungsstand an die "Kernelwächter", der dann bei Veröffentlichung des Kernels natürlich auch schon nicht mehr der neueste ist.


    Ende Mai gab es mal eine Diskussion auf der linux-tv-mailing list, weil ein user lange Lock-Zeiten hatte.


    "...besides i detected that the card locks faster with QAM_64 modulation as with QAM_16 modulation, though the dvb-t provider says it is using QAM_16 modulation."
    der Entwickler schrieb dann "For me this sounds like i didn't mess things up with my changes but the initialization procedure for the tda10045 wasn't perfect in older versions either and the driver should be optimized a bit. Unfortunately i can't do this since i don't have any hardware to test the tda10045 specific code.
    Can anybody else do this?"


    Da weiter keiner antwortete, war das Thema damit beendet... Ist natürlich auch sehr unglücklich, wenn ohne praktische Prüfmöglichkeit nur auf theoretischer Basis an den Treibern gearbeitet wird. Ich hätte an seiner Stelle Lorenzen um ein Exemplar gebeten. Es müsste doch auch in deren Interesse liegen, dass es funktionierende Linux-Treiber gibt.



    Zitat


    Stotterprobleme hatte ich bisher nicht. Die Tune-Dauer variiert bei mir stark, bis zu ca. 10 Sekunden beim Bouquet-Wechsel, meistens geht es aber viel schneller.


    schau bitte nochmal mit femon, ob es wirklich so lange bis zum Lock dauert. Dass das Bild später kommt, kann auch am AC3-Buffer liegen. Der muss erst gefüllt sein, das macht bestimmt auch noch mal 1-2 Sekunden.

    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

  • Hi,


    mit dem Darkangel Kernel 2.6.12.2 und der neuen Firmware fw-dvb


    unter http://www.vdrportal.de/board/thread.php?threadid=35897&sid=


    gehts jetzt. Keine Lock-Probleme mehr und Umschaltzeiten beim Transponderwechsel von 2 Sekunden. Freu mich tierisch daß Linvdr0.7 jetzt auch uneingeschränkt DVB-t fähig ist.


    Siehe auch http://www.vdrportal.de/board/thread.php?threadid=35691&sid=


    Vielleicht kann der Thread-Ersteller es ja mit in den Titel (Lösung) packen.
    Gruß
    Oppee

  • das sind ja gute Nachrichten. Ich frage mich nur, was da nun den Unterschied bewirkt hat.


    Zuletzt hatte hier jemand berichtet, dass es mit DarkAngels Kernel 2.6.12.1 auch nicht richtig läuft.


    Im CVS ist am 13.6. folgende Änderung beim tda1004x verzeichnet:

    Zitat

    - added preliminary support for tda827x tuners
    - set parameters for drift compensation to 0
    makes no sense for DVB-T but can prevent lock


    Ich glaube mich zu erinnern, dass DarkAngel diesen CVS-Stand in seinem 2.6.12.1 vom 30.6. schon drin hatte.


    An der Firmware ist seit Monaten nichts geändert worden.

    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

  • ich habe mir jetzt mal das Modul tda1004x mit den Soucren aus dem CVS für Kernel 2.6.9 compiliert.
    Tatsächlich scheint das Tunen jetzt fix zu gehen!


    Ich habe nur ein Problem:


    Beim Booten hängt es jetzt 10 Sekunden:


    Jul 25 23:23:36 linvdr user.info kernel: tda1004x: found firmware revision 0 -- invalid
    Jul 25 23:23:36 linvdr user.info kernel: tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)...
    Jul 25 23:23:46 linvdr user.err kernel: tda1004x: no firmware upload (timeout or file not found?)
    Jul 25 23:23:46 linvdr user.warn kernel: tda1004x: firmware upload failed


    danach geht es weiter, und es kommt auch ein Bild. Also wohl eine spontane Selbstheilung :)
    nee, im Ernst, die aktuelle Firmware liegt natürlich in /usr/lib/hotplug/firmware wie immer.


    Ich finde beim googlen jede Menge Threads dazu auf der mailinglist. Angeblich soll es im CVS gefixt sein, aber es gibt auch Leute die das nicht bestätigen.


    Schaue doch bitte mal in Dein Log, ob Du da auch sowas siehst.

    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

  • Hi,
    bei mir scheint das nicht aufzutreten:


    Jul 26 01:13:33 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter0/frontend0
    Jul 26 01:13:33 linvdr user.debug vdr[2841]: tuner on device 1 thread started (pid=2841, tid=1026)
    Jul 26 01:13:33 linvdr user.debug vdr[2842]: Section handler thread started (pid=2842, tid=2051)
    Jul 26 01:13:33 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter1/frontend0
    Jul 26 01:13:34 linvdr user.info kernel: tda1004x: found firmware revision 0 -- invalid
    Jul 26 01:13:34 linvdr user.info kernel: tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)...
    Jul 26 01:13:35 linvdr user.info kernel: tda1004x: firmware upload complete
    Jul 26 01:13:35 linvdr user.info kernel: tda1004x: found firmware revision 2c -- ok
    Jul 26 01:13:35 linvdr user.debug vdr[2861]: tuner on device 2 thread started (pid=2861, tid=3076)
    Jul 26 01:13:35 linvdr user.debug vdr[2862]: Section handler thread started (pid=2862, tid=4101)
    Jul 26 01:13:35 linvdr user.debug vdr[2828]: probing /dev/dvb/adapter2/frontend0
    Jul 26 01:13:35 linvdr user.info vdr[2828]: found 2 video devices
    .
    .
    Jul 26 01:13:35 linvdr user.info vdr[2828]: setting primary device to 1


    Hoffe es hilft dir.


    Gruß
    Oppee

  • Moin, ich habe ein ganz ähnliches Problem. Auf meinem DVB-T System habe ich direkt nach einem Transponderwechsel zunächst kein Bild. Wechsle ich auf einen anderen Kanal des selben Transponders, is das Bild dann da.
    Ich nutze LinVDR mit dem Originalkernel - bringt vielleicht ein neuerer Kernel Besserung?


    Gruß,


    m.


    mein VDR:
    Siemens Gigaset 740AV, Buffalo Linkstation NAS
    in meiner Bastelkiste:
    2x Activy 300, 1x MediaPortal mit GLCD, 1x Fujitsu-Siemens Jetson, 1xDVB-C Rev.2.1, Airstar2, neue Nova-T, Linksys NSLU2, defekte 2300C

  • Zitat

    Original von Dr. Seltsam
    Jul 25 23:23:46 linvdr user.warn kernel: tda1004x: firmware upload failed


    ich habe gerade einen Geistesblitz!
    Da ich vorher meinen selbstgebastelten Kernel 2.4.31 laufen hatte, war sysfs nicht gemountet (hatte ich in /etc/fstab auskommentiert). Wahrscheinlich läuft hotplug dann nicht korrekt. Werde es also heute abend nochmal mit gemountetem sysfs testen.

    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

  • MR42HH


    Schau dir logread nach einem fehlgeschlagenen Kanalwechsel an.
    Wenn da was von "Device ... has no lock" steht, dann sollte es der gleiche Fehler sein. Und wenn deine Umschaltzeiten auch dermaßen schlecht sind wie es meine waren, dann würd ich nicht zögern, es auszuprobierren.


    Gruß
    Oppee

  • Zitat

    Original von oppee
    Und wenn deine Umschaltzeiten auch dermaßen schlecht sind wie es meine waren, dann würd ich nicht zögern, es auszuprobierren.


    Meine Umschaltzeiten waren ganz OK - ich hab's trotzdem mal riskiert. Resultat: Zappen geht jetzt auch querfeldein problemlos. Schönen Dank!


    Gruß,
    Mirko


    mein VDR:
    Siemens Gigaset 740AV, Buffalo Linkstation NAS
    in meiner Bastelkiste:
    2x Activy 300, 1x MediaPortal mit GLCD, 1x Fujitsu-Siemens Jetson, 1xDVB-C Rev.2.1, Airstar2, neue Nova-T, Linksys NSLU2, defekte 2300C

Jetzt mitmachen!

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