Beiträge von mw_183

    Zitat

    Ich vermute mal, das die eine der beiden Nova-T-Karten noch die alte Karte ist. Die hatte ziemlich bescheidene Empfangseigenschaften.


    So ist es. Mein Eindruck von der Neuen ist aber nicht grundsätzlich besser. In sowas habe ich mich aber schon oft getäuscht ...


    Zitat

    Interessant wäre jetzt mal, auf welche der beiden Budget-karten vdr beim Fernsehen bzw. beim Aufzeichnen zuerst zurückgreift. Bau doch mal die alte Karte aus...


    Die alte Karte wird zuerst verwendet. Die neue könnte ich wahrscheinlich durch Tauschen der Modulreihenfolge auch zuerst laden (?). Leider kann femon sie aber nicht auslesen, es zeigt keine sinnvollen Werte. Ich nehme an, dass sie vielleicht zwei frontends besitzt, das Log beim Laden sieht irgendwie danach aus (kann ich bei Interesse nachliefern). Laut Homepage unterstützt femon solche Karten nicht.


    Zitat

    ...und schaue, ob Du mit der neuen eine BER von unter 500 hinkriegst.

    500 hex oder dezimal? ;)


    Viele Grüße,
    Matthias

    Super - das wars scheinbar gewesen.


    Mit "sleep 5" vor dem Aufruf von unloaddriver (allerdings unter "down)") hatte ich gleich eine Fehlermeldung weniger. Dann habe ich die Ausgabe von lsmod studiert und schließlich nur noch cx88_blackbird und cx88_dvb geladen. Jetzt wird alles ohne Probleme auch in der runvdr wieder entladen. Bis jetzt gabs auch keine Probleme beim Shutdown mehr.


    Heißen Dank für den Tipp,
    Matthias

    Es war scheinbar doch das dvb-t-Signal bzw. die Antenne. Ich bin nochmal einen Abend lang mit der Antenne durchs Wohnzimmer geturnt und habe den Blick auf die BER von femon gerichtet. Jetzt liegt die Antenne horizontal auf dem Regal(!) und ich habe erstmals eine nur 3-stellige BER, jedenfalls bei arte/Phoenix/N3/ARD. Bei den anderen Sendern sind es 4 Stellen, aber es geht auch.


    Timeshift macht jetzt kein Problem mehr. Ich hatte bereits früher schon den Eindruck, dass die dxr3 sehr empfindlich gegenüber fehlerhaften Daten ist. Und das kommt bei dvb-t scheinbar ständig vor.


    OK, ich bin zufrieden, vielen Dank für Eure Tipps!

    Moin,


    seit kurzem habe ich eine neue Nova-t 90002 als Zweitkarte. Ich verwende linvdr 0.7, vdr 1.3.17, mit Dr. Seltsams Kernel 2.6.15 (28.2.2006) und ebendessen dxr3-Paket. Um die Karte verwenden zu können, habe ich in der runvdr als letzte Module cx88xx und cx88_dvb angefügt. Soweit läuft es prächtig, beide Karten liefern ein Bild, ich kann gleichzeitig zwei Frequenzen schauen/aufnehmen etc.


    Beim Shutdown wird jetzt ca. jedes 2. Mal das Netzteil nicht abgeschaltet, daher fährt der Rechner dann natürlich auch nicht mehr automatisch hoch. Ich habe den Rechner ins Arbeitszimmer geschleppt, einen Monitor angeschlossen und folgendes (nach verunglücktem shutdown) abgeschrieben:


    An den Stellen (...) habe ich jeweils was gekürzt.
    Danach fährt das System runter und sagt "system halted". Es gibt also keine "kernel panic", wie in einem anderen Thread berichtet. Nur geht eben der Strom nicht aus.


    Ich habe dann damit experimentiert, verschiedene Module in der runvdr mit aufzulisten, bis hin zu der ganzen Liste

    Code
    cx88xx
    cx8802
    cx22702
    video_buf_dvb
    cx88_dvb


    Das ändert aber gar nichts.


    Beim Runterfahren sollten wohl eigentlich die Module schon entladen sein (?). Wenn ich "/etc/init.d/runvdr stop" aufrufe, kriege ich die Meldung

    Code
    Unknown HZ value! (84) Assume 100.
    FATAL: Module cx88_dvb is in use.
    FATAL: Module video_buf_dvb is in use.
    FATAL: Module cx22702 is in use.
    FATAL: Module cx8802 is in use.
    FATAL: Module cx88xx is in use.
    FATAL: Module dvb_core is in use.
    FATAL: Module video_buf is in use.
    FATAL: Module videodev is in use.


    Die Module können also nicht entladen werden. Ich frage mich, warum. Nach einem "/etc/init.d/runvdr stop" konnte ich mit rmmod -f das cx88_dvb ohne Crash entladen. Trage ich diesen Aufruf in die runvdr als letzten Befehl unter "stop)" ein, steht das System sofort.


    Wieso können die Module nicht in der runvdr entladen werden (Knackpunkt scheint cx88_dvb zu sein)?
    Wer benutzt beim Shutdown cx88_dvb (Module cx88_dvb in use)?
    Wieso geht das Entladen per Hand (kann allerdings ein Zufall gewesen sein)?
    Hat das verpatzte Power-off vielleicht einen anderen Grund (und welchen)?


    Für Hinweise aller Art dankt
    Matthias

    Oh ja - das will ich auch!
    Stabiler vdr mit "flüssiger" Bedienung bei dxr3-Ausgabe - das hört sich traumhaft an. Im Moment hab ich vdr 1.3.17, Dr. Seltsams Kernel 2.6.15 vom 28.2.2006 und ebensein dxr3-Paket. Das läuft nicht schlecht, könnte aber (na klar) noch besser sein.


    Ich habe jetzt noch nicht ganz verstanden, woher ich die Komponenten bekomme:


    vdr 1.3.47 - cody-Thread
    dxr3-plugin 0.2.6-cvs - Dein dxr3-Paket, ab sofort oder später?
    dxr3-Module 0.15.3 - woher? Kernel-Update-CD ab wann etwa?
    Oder schon in Dr. Seltsams Kernel 2.6.15 ab 2.4.2006
    oder vielleicht später?


    Für Tipps ist dankbar
    Matthias

    Moin,


    soweit ich weiß, geht mit dxr3 sowieso kein screenshot. Ich habe jedenfalls noch nie einen machen können.


    Falls es doch (inzwischen) klappen sollte, wär das für mich natürlich auch interessant.


    Viele Grüße,
    Matthias

    Moin Günter,


    leider keine Hilfe - aber das erinnert mich ein bisschen an mein Problem hier: http://www.vdr-portal.de/board/thread.php?threadid=46500&sid=
    Vergleiche doch selbst mal die Beschreibungen. Leider habe ich keinen Lösungsansatz zu bieten. Insbesondere steht ja nichts im Log.


    Meine einzige Idee ist Kernel 2.4 und vdr 1.2.6 (das ist bei mir im ct-vdr einwandfrei gelaufen, nur das dxr3-Plugin war Mist). Das ist aber wohl auch nicht mehr zeitgemäß.


    Viel Glück,


    Matthias

    Moin Toxic,


    den neuen Kernel und das dxr3-Plugin werde ich demnächst ausprobieren. Bisher hat das neueste vom neuesten allerdings keine Abhilfe gebracht ...


    Die meisten Aufnahmen etc. mache ich tatsächlich auf der arte-Phoenix-N3-ARD-Frequenz (dvb-t). Ich werde nochmal versuchen, das Problem auf anderen Frequenzen nachzuvollziehen. Gibt es da welche, die man zuerst ausprobieren sollte?


    AC3 benutze ich gar nicht.


    Systemlast ist m.E. kein Thema, werde ich aber auch nochmal nachsehen. Bei Timeshift habe ich wie gesagt CPU deutlich unter 10% und außer vdr taucht bei top nichts auf, was nennenswert CPU braucht. Mit noad oder vdrconvert kann ich das Ruckeln auch erzeugen bzw. zusätzlich verschlimmern.


    Vielen Dank jedenfalls für die Hinweise, ich melde mich sobald ich was Neues weiß,


    Matthias


    PS: Der Logauszug scheint wirklich normal zu sein, aber durch die vielen gleichen Meldungen sehe ich kaum noch was Wichtiges im Log. Es speichert ja auch nur ca. 400 Zeilen oder so. Kann man das eigentlich ändern?

    Liebe Leute,


    wegen der besseren dxr3-Unterstützung bin ich kurz vor Weihnachten vom ct-vdr auf Linvdr umgestiegen und bin auch soweit sehr zufrieden damit. Dr. Seltsams dxr3-Paket ist wirklich klasse.


    Nun zum Problem:
    Sobald außer dem vdr noch irgendwas läuft (Aufnahme, timeshift, noad oder gar vdrconvert), beginnt nach 10-20 Minuten ein Ruckeln und Stottern, das einem das Fernsehen verleidet. Die Aufnahmen sind auch hinüber.


    Das Problem tritt auf bei Kernel 2.6.9 und Dr. Seltsams 2.6.14.2 sowie 2.6.15 (2.6.15 subjektiv heftiger als die anderen Versionen). Außerdem alle vdr-Versionen, die ich mit Linvdr ausprobiert habe (1.3.12, 1.3.17, 1.3.24, und noch irgendeine 1.3.3x). Zum Testen hatte ich jeweils nur das dxr3-Plugin aktiviert.


    Schaue ich nur fern, ist alles ok. Lasse ich den vdr während der Aufnahme in Ruhe, ebenso. In den Aufnahmen ist dann höchstens mal ein kleiner Ruckler.


    Vom ct-vdr (vdr 1.2.6, Kernel 2.4.x) kann ich mich an sowas überhaupt nicht erinnern. Timeshift und stundenlange Parallel-Aufnahmen waren kein Thema (dafür gabs andere Probleme genug).
    Die CPU-Belastung ist unter 10%, und im Log steht - Nichts. Nur ständig Meldungen über das OSD (siehe Anhang).


    Ähnliche Probleme wurden hier unter Linvdr öfters berichtet, teils nur für FF Karten, teils für andere Spezialfälle. Eine Lösung habe ich nicht gesehen. Nach allem, was ich bisher ausprobiert habe, könnte es an der Kombination dxr3, Kernel 2.6 und vdr>1.2.6 liegen. An die CPU-Last und Daten-Transferraten glaube ich nicht, weil dieses Problem mit vdr 1.2.6 und Kernel 2.4 eben nicht auftrat.


    Kennt jemand Kombinationen aus Kernelversion und vdr-Version (eventuell auch Version der dxr3-Treiber und des Plugins), die das Ruckelproblem "sicher" nicht haben?


    Für Hinweise ist dankbar
    Matthias

    Moin Leute,


    auch ich habe dank eternalplayer und dxr3player zum ersten Mal ruckelfreie DVDs auf meinem vdr gesehen: heißen Dank und Respekt für diese Leistung!


    Ich habe ein Problem mit selbst gemachten DVDs, auf denen die ac3-Tonspur fehlt. Dieses scheint ein Problem von vdrsync zu sein - siehe hier: http://www.vdrportal.de/board/thread.php?threadid=43546&sid=
    Der dxr3player spielt allerdings einwandfrei die Mpeg-Audio Tonspur, nur lässt sich dabei die Lautstärke nicht regeln! Es sieht so aus, als würde der dxr3player die Lautstärke nur für ac3 regeln.


    Hat jemand eine Idee, wie die Lautstärke beim dxr3player für Mpeg-Audio zu regeln ist? Möglicherweise würde ein "Slave-Modus", bei dem vdr die Lautstärke regelt, die Sache lösen.


    swer:
    Vielen Dank für das dxr3player-Lompilat - es läuft einwandfrei. Leider spielt es keinen Mpeg-Audio Ton. Im vdrconvert-Paket von hjs (link: http://www.vdr-portal.de/board/thread.php?threadid=22804&sid=&hilight=vdrconvert+linvdr+0+7) war offenbar die fehlende Lib drin - seitdem nutze ich wieder die Version von joachim-h.


    Vielen Dank,
    Matthias


    Setup: Linvdr 0.7 mit Dr. Seltsam Kernel 2.6.14.2 und dxr3 Plugin; Nova-t "alt" und dxr3, lirc-FB

    Moin,


    ich habe eine Nova-t, mit der ich auch ein "Kanal nicht verfügbar" Problem hatte. Bei mir lag es daran, dass der vdr wegen der dxr3 sehr oft abstürzt, und dann neu startet. Dabei werden die Module für die Nova-t nicht korrekt wieder initialisiert. Abhilfe schaffte eine Zeile in der runvdr, die bei Neustart des vdr zunächst die Nova-t Module entlädt und neu lädt. So hab ich auch wieder Kanäle.


    Da Du (scheinbar) eine FF Karte benutzt, wird das nicht das Problem sein. Vielleicht aber was ähnliches? Reihenfolge der Module beim Laden? Oder doch gelegentlicher Absturz des vdr (macht sich nur kurz bemerkbar)?


    Eine zweite Möglichkeit (hast Du wahrscheinlich längst gemacht ;) ist, dass Du in der channels.conf jeden Kanal auf eine bestimmte Karte festlegen kannst (und bei Dir wohl auch musst). Die FF Karte wird die dvb-t-Kanäle nie empfangen. Wie die Zuweisung geht, weiß ich nicht, aber das findest Du bestimmt.


    Mehr fällt mir nicht ein...


    Viel Glück,
    Matthias


    PS: Ich sehe grade, dass Du schon auch mal Erfolg mit einer Nova-t hattest, dann erübrigen sich wohl leider meine klugen Ratschläge. Wer lesen kann, ...
    Vielleicht ist ja doch ne Anregung dabei ;)

    Hi,


    den Fehler hatte ich auch mit dem ctvdr-2. Die Kernelquellen von Heise hatten in linux/version.h nicht die richtige Version eingetragen (2.4.24 statt 2.4.24-ctvdr-2). Alle dvb-Module kompilierten ok, aber beschwerten sich beim Laden über die falsche Kernelversion.


    Ich habe in linux/version.h die richtige Version eingetragen, dvb-Module neu kompiliert und dann gings.


    Mein Vorschlag also: schau in linux/version.h, ob dort 2.4.27-ctvdr-1 steht. Wenn nicht, korrigier es. Dann sollte es gehen.


    Viel Erfolg,


    Matthias

    Auf die Gefahr hin, dass ich noch nen wertlosen Hinweis gebe ...


    Ich weiß nicht genau was Version-magic-inkompatibilitäten sind. Ich hab mal dvb-Treiber für Kernel 2.4.24-ctvdr-2 kompiliert, die haben sich dann beschwert, dass sie nur für Kernel 2.4.24 passen würden, aber nicht für 2.4.24-ctvdr-2, der (korrekt) am laufen sei. Der Fehler steckte in den Quellen des ct-Kernels in linux/version.h, dort hatte man nicht die richtige Version eingetragen (s.o.). Als ich das geändert hatte, liefen auch die (neu übersetzten) Module.


    Mir ist klar, dass das nicht die gewünschten Patches herbeizaubert. Aber vielleicht willst Du ja gar nicht den ganzen Kernel neu bauen ...


    Viel Glück,


    Matthias (der sich immer noch für den 2.6-er interessiert)

    Hallo,


    ich weiß ja nicht, was Du _genau_ abspielen willst.


    Ich habe mal ein DVD-iso-image, das der vdr erstellt hatte, mit vlc 0.6.2 auf einem anderen Rechner abgespielt. Es gab erst Ton, als ich Tonspur Nr. 3 auswählte, Spuren 1,2 und 4 tönten nicht.


    Vielleicht hilfts,


    Matthias

    Moin,


    auch wenn der Thread schon etwas älter ist, meldet sich hier noch ein dxr3-Benutzer. Ich hab sie zusammen mit einer nova-t für dvb-t in Bremen im Einsatz.


    Zuerst mit ctvdr-2. Probleme: sowohl em8300 als auch dxr3-Plugin waren instabil und praktisch unbrauchbar. Mag sein, dass es auch mit meinem Via-Chipsatz zusammenhängt, sowas hab ich hier mal gelesen. Dazu kam, dass mit den dvb-Treibern nur schlechter Empfang möglich war. Jedenfalls haben zwei Patches von Austrian Coder die dxr3-Probleme ratzekahl beseitigt
    -- dickes fettes Lob!! 8)


    Jetzt mit ctvdr-3. Ein Problem war zunächst der em8300-Treiber, jetzt hab ich 0.14 und es läuft gut. Nächstes Problem ist das DVD-Plugin, das mit der dxr3 nicht befriedigend läuft. Selbstgemachte DVDs ruckeln und stottern entsetzlich, und bei meiner einzigen kommerziellen DVD bleibt das DVD-Plugin hängen. Ich habe gelesen, dass ein älteres Release sehr viel besser laufen soll (0.3.4-rc5) als das des ctvdr-3 (0.3.4-rc10), aber ich kann es nirgends finden. Schade. DVD gucken wäre auch schön gewesen. :(


    Mein Eindruck ist, dass die dxr3 sehr leistungsfähig ist, aber als "Außenseiter-Hardware" wenig berücksichtigt wird. Austrian Coder ist dabei natürlich die große Hoffnung für alle vdr's mit dxr3 :respekt


    So, ich denke, das war's.
    Viele Grüße,
    Matthias


    VDR: ct-vdr-3 auf asus p4vp-mx, celeron 2000, nova-t (januar 2004) & dxr3

    Moin Sergei,


    das war genau die Config, die ich bis zum ctvdr-3 benutzt habe (falls ich mich nicht doch verguckt habe). Hat auch super funktioniert, nur addr_stat nicht, wie gesagt.


    Inzwischen habe ich allerdings ctvdr-3 installiert, und zunächst wollte das Board überhaupt nicht mehr aufwachen, auch nicht, wenn ich die Parameter direkt im BIOS einstellte.


    Dann habe ich im BIOS rumgeändert (Bootreihenfolge) und wieder zurück, und seitdem wacht es auch wieder auf. Braucht aber stets ein Reboot. Das war vor ctvdr-3 nicht der Fall! Ich vermute, dass das BIOS nicht ganz sauber ist.


    Ich habe jetzt also zu der alten Config (wie in Deinem Vorschlag) noch need_reboot auf ON_ANY_CASE gesetzt, den poweroff-kernel installiert, und jetzt läuft alles wieder super. Status Ändern habe ich noch nicht probiert, weil es so ein Aufwand ist, alle BIOS-Einstellungen wieder neu zu machen.


    Seit den neuesten DVB-Treibern für ctvdr-3 habe ich auch endlich vernünftigen Empfang, wenn auch mit 45s Umschaltzeit (nova-t "altes" Modell). Nach 10 Monaten rumdoktern ist das echt erhebend!


    Vielen Dank & keep up the good work!


    Matthias

    Moin,


    bei mir wurde das locales-Problem durch ein schlichtes


    dpkg-reconfigure locales


    gelöst. Ich habe dann de_DE ISO-8859-1 ausgewählt (default)
    und vdrconvert lief durch! Vorher hatte ich auch die hier
    beschriebenen Fehler. Der Tipp ist aus diversen älteren Postings,
    es scheint ein bekanntes Problem des ct-vdr zu sein.


    Die anderen locales beziehen sich auf Ascii-Tabellen mit Euro-Zeichen
    oder sogar ganz andere Kodierungen (UTF?), brauchte ich zum Glück nicht.
    Es gibt übrigens noch sehr viel mehr de-locales für Österreich, die Schweiz, etc. pp. ;)


    Jetzt hab ich ein neues Problem: beim Testlauf mit dvdselect
    sind die erzeugten DVD-Isos voller Fehler. Sie ruckeln und
    stottern wie verrückt, sind also erstmal wertlos ;(
    Liegt es an den Aufnahmen (dvb-t, die sind aber sehr gut anzuschaun),
    an mir oder woran?
    Ich werd wohl erstmal suchen müssen ...


    Erstmal viele Grüße,
    Matthias