LinVDR auf CF-Card -> Probleme

  • Hallo zusammen,
    wie man in meiner Signatur lesen kann, habe ich mein LinVDR nun komplett auf eine CF-Card (SanDisk Ultra II) gepackt.


    - LinVDR07
    + Kernel 2.6.16.7 (weiß grad nicht mehr woher. Evtl. Mal den von Dr. Seltsam drüber bügeln)
    + linvdr-0.7-mt-1.3.24-20050518.tgz
    + libs-tarandor-20060824.tar.bz2
    + conf-tarandor-20060824.tar.bz2
    + vdr-1.4.3-tt-20060928.tar.bz2
    + selbstkompilierten vdr-1.4.3-1


    Mein Mainboard (Asus A7V 133) hat insgesamt 4 IDE Anschlüsse , so dass ich alle Laufwerke als Master angeschlossen habe:


    IDE-to-CF --> hda (LinVDR)
    Nec-133 DVD-Brenner --> hdc
    Samsung 120 GB --> hde (pub, tmp, ...)
    Samsung 160 GB --> hdg (video)


    folgendes ab ich, um die Schreibzugriffe auf die CF zu minimieren, auf meine Festplatten bzw. ramdisk ausgelagert:


    Zum CF-to-IDE-Adapter ist zu sagen, dass ich einen verwende, der laut Verkäufer ausdrücklich DMA unterstützt.


    Ein hdparm -I /dev/hda sagt mir:


    Der * heißt doch, dass mdma2 aktiviert ist, oder? Manchmal kommt es aber auch vor, dass in der zeile DMA: folgendes steht:
    DMA: mdma0 mdma1 mdma2 (?)
    dann hat er den Modus nicht gesetzt, oder?
    Muss ich, wie ich in einem anderen Thread gelsen habe, den "turn dma on" aufruf in der rcStart abhändern, dass der mdma2-Modus aktiviert wird, oder passt das schon so?



    An sich sich läuft das ganze System soweit ganz gut bis auf drei Probleme:
    1) Von Zeit zu Zeit hängt sich der VDR beim schnellen Umschalten auf und gibt kein Bild bzw. Ton mehr aus. Das OSD ist noch aufrufbar.


    2) Dei Aufnahmen sind sehr schlecht bzw. mit Artefakten versehen. Teilweise ist der halbe TV mit grünen Vierecken bedeckt. Auch kommt es vor, dass der VDR die Wiedergabe der Aufnahme selbstsändig abbricht, oder der Springen mit "gelb" gar nicht funktioniert.


    3) das burn-plugin bricht bei der Konvertierung ab, aber das liegt meiner Meinung nach an den "defekten" Aufnahmen.


    Hab zuerst gedacht, dass es evtl. an den Übertragungsraten der CF-Card bzw. der Festplatten liegt, aber nach eine Eingabe von hdparm -t /dev/hda /dev/hde /dev/hdg hat sich dieser Verdacht nicht bestätigt:


    Code
    /dev/hda:
     Timing buffered disk reads:  64 MB in  5.37 seconds = 11.93 MB/sec
    
    
    /dev/hde:
     Timing buffered disk reads:  64 MB in  3.74 seconds = 17.10 MB/sec
    
    
    /dev/hdg:
     Timing buffered disk reads:  64 MB in  3.83 seconds = 16.71 MB/sec


    Das müsste doch locker reichen, oder? Bei der CF-Card bekomm ich manchmal auch nur 6.xx MB/sec, aber die Aufnahme wird ja sowieso auf /dev/hdg gespeichert....



    Bin für jeden Tip bzw. Anregung dankbar.



    Mfg Josef

    registered VDR-User: #1013


    Hardware: Asus A7V133 / 640 MB Ram / Athlon TB 1000 / SanDisk Ultra II 1GB / Samsung 120 GB + 160 GB/ Nec 1300 / TT 1.5 + Extension Board / TT Budget / GLCD 240x64


    Software: LinVDR 0.7 - vdr-1.4.3-2 - Kernel-2.6.18 auf CF-Card ... 384 MB LiveBuffer auf Ramdisk

  • Ich hatte mal soein Probleme weil ich ein defktes IDE Kabel genommen habe.
    Oft sind diese Extralangen blauen die schuldigen!
    Mehr wie 4 Aufnahmen da war essig.


    Es ist mir erst aufgefallen als ich die dmesg gelesen habe als der Rechner 24 std an wahr.
    Linvdr stellt den DMA modus wie ich glaube automatisch bei jedem start auf udma oder so!
    Also kam der fehler erst nach Stunden als der Rechner gefordert wurde!Das steht dan in der dmesg.
    Der Kernel stellt ihn sicherheitshalber runter auf pio
    Mit neuen IDE Kabel konte ich bis 10> gleichzeitigen aufnahmen machen. und der Fehler war weg.
    Ach ja der PCI kan glaube ich 30MB/sek


    Vielleicht hilft´s sja!

    HauptVDR AMD Goede 1750 Easyvdr 0.06.4
    FF_TT2.3 Skystar2.6c 1x160GB + 1x1TB lautloser Rechner weil er im Keller steht. :D


    2x MediaMVP als Client+VOMPServer-Plugin


    TestVDR AMD Goede 1750 mit TT1.5 Easyvdr 06.*
    Bootet auf einer komischen Weise
    PicoPSU als NT

  • Hallo,
    erstmal danke für Eure Antworten.


    Dauser

    Zitat

    Ich hatte mal soein Probleme weil ich ein defktes IDE Kabel genommen habe.


    Hab jetzt mal die kompletten Kabel ausgetausch und es scheinen nun zumindest die Aufnahmen wieder normal zu laufen. An den Übertragungswerten hat sich jedoch nichts geändert. Beim Umschalten treten leider immer noch teilweise Artefakte auf.


    Zitat

    Linvdr stellt den DMA modus wie ich glaube automatisch bei jedem start auf udma oder so!


    Genau das hab ich gemeint. Die Adapter-CF-Card Kombination kann ja nicht udma sondern nur mdma. Muss ich deswegen was ändern?



    habichthugo
    Also femon zeigt mir beide Balken im grünen Bereich.
    STR: 67-68%
    SNR: 86%
    also an dem kannst dann wohl nicht liegen...



    Beim Testen sind mir gerade drei Dinge aufgefallen:
    1) Wenn ich einen Timer über TV-OnScreen programmiere, zeigt er mir mir die Meldung "Schnitt gestartet". Was soll den das?
    2) Hänger bzw. Artefakte beim Umschalten zwischen Sender bekomme ich vor allem wenn ich zwischen Privaten z.B. Sat1 und Öffentlichen ARD / ZDF hin und herschalte.
    3) Meine CPU Belastung ist immer so um die 68%. Bei einem Athlon TB 1000. Liegt das am Repacker wie hier im Forum gelesen habe?


    Vielleicht sollt ich mal darüber nachdenken mein System nochmal komplett neu aufzusetzen....


    Mfg Josef

    registered VDR-User: #1013


    Hardware: Asus A7V133 / 640 MB Ram / Athlon TB 1000 / SanDisk Ultra II 1GB / Samsung 120 GB + 160 GB/ Nec 1300 / TT 1.5 + Extension Board / TT Budget / GLCD 240x64


    Software: LinVDR 0.7 - vdr-1.4.3-2 - Kernel-2.6.18 auf CF-Card ... 384 MB LiveBuffer auf Ramdisk

  • Mein VDR läuft zur Zeit auch nicht perfekt.


    Zitat

    Original von JosefGierl
    Also femon zeigt mir beide Balken im grünen Bereich.
    STR: 67-68%
    SNR: 86%
    also an dem kannst dann wohl nicht liegen...


    Wichtiger sind die fehlerhaften Bilder (BER). Wenn ich das Komandozeilen-Tool femon -a 0 aufrufe bekomme ich bei der ersten Meldung meistens einen BER-Wert ungleich 0, z.B. ber 0000ff00, danach kommen keine Fehle mehr (nur noch ber 00000000) Ist das bei dir evtl. auch so ?


    linvdr:~# femon -a 0
    using '/dev/dvb/adapter0/frontend0'
    FE: ST STV0299 DVB-S (SAT)
    status 1f | signal af25 | snr daf4 | ber 0000ff00 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal af00 | snr dafa | ber 00000000 | unc 00000000 | FE_HAS_LOCK



    Zitat

    Original von JosefGierl
    1) Wenn ich einen Timer über TV-OnScreen programmiere, zeigt er mir mir die Meldung "Schnitt gestartet". Was soll den das?


    Das kommt vom Livebuffer. Wenn du eine Sendung aufzeichnest, die der Livebuffer schon teilweise aufnimmt, wird die bestehende Livebuffer-Aufnahme zu deiner programmierten Sendung dazugeschnitten.


    Zitat

    Original von JosefGierl
    2) Hänger bzw. Artefakte beim Umschalten zwischen Sender bekomme ich vor allem wenn ich zwischen Privaten z.B. Sat1 und Öffentlichen ARD / ZDF hin und herschalte.


    Hab ich auch teilweise, manchmal auch beim vorspringen in Aufnahmen.


    Zitat

    Original von JosefGierl
    3) Meine CPU Belastung ist immer so um die 68%. Bei einem Athlon TB 1000. Liegt das am Repacker wie hier im Forum gelesen habe?


    Mein Geode läuft meistens mit 666 Mhz und hat dann nur ca. 20% Auslastung.


    Gruß
    Bernhard

  • Hi,


    Also schwarzes Bild mit funktionierendem OSD deuete bei mir immer auf ARM crashes hin - schau mal im Logfile danach. Zumindest bei mir treten die (auch) besonders bei schlechtem Empfang auf. Früher auch bei schnellem Zappen, aber das ist mittlerweile viel besser (d.h. weg), das wenn ich mich recht erinnere mit Upgrades der TT-Firmware...


    Pit

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

  • Hallo,
    bma


    Zitat

    Wichtiger sind die fehlerhaften Bilder (BER). Wenn ich das Komandozeilen-Tool femon -a 0 aufrufe bekomme ich bei der ersten Meldung meistens einen BER-Wert ungleich 0, z.B. ber 0000ff00, danach kommen keine Fehle mehr (nur noch ber 00000000) Ist das bei dir evtl. auch so ?


    Das Tool femon hab ich leider nicht, aber wenn ich den BER-Wert im femon-plugin beobachte, dann ist es bei mir genau so wie bei Dir. Direkt nach dem Umschalten auf einen Kanal springt er kurz auf einen ungleich 0000000. Nach sehr kurzer Zeit kehrt er jedoch wieder zurück.


    Zitat

    Mein Geode läuft meistens mit 666 Mhz und hat dann nur ca. 20% Auslastung.


    Hab jetzt nochmal eine Installation drüber gebügelt und jetzt liegt die CPU-Last bei mir jetzt auch zwischen 10 bis 20 Prozent bei Normalbetrieb.


    Der_Pit

    Zitat


    Also schwarzes Bild mit funktionierendem OSD deuete bei mir immer auf ARM crashes hin - schau mal im Logfile danach.


    Danke für den Tip, werd wenn es das nächst mal vorkommt gleich nachschauen. Wenn es an ARM crashes liegt, was kann ich dagegen tun?


    Zitat

    Früher auch bei schnellem Zappen, aber das ist mittlerweile viel besser (d.h. weg), das wenn ich mich recht erinnere mit Upgrades der TT-Firmware...


    Hmm. Hab die dvb-ttpci-01-F62623.fw drauf. Eine neuere gibts gar nicht, oder?



    Hab jetzt wie, gesagt sämtliche IDE-Kabel ausgetauscht und sogar die Video-Platte (160GB) komplett formatiert. Aber trotzdem haben die Aufnahmen meiner Meinung nach bei weitem nicht die Qualität wie früher. Also teilweise Aussetzer, grüne Artefakte etc. Kann das daran liegen, dass ich die Platten bei einer Inaktiviät von 5 min abschalte?



    Mfg Josef

    registered VDR-User: #1013


    Hardware: Asus A7V133 / 640 MB Ram / Athlon TB 1000 / SanDisk Ultra II 1GB / Samsung 120 GB + 160 GB/ Nec 1300 / TT 1.5 + Extension Board / TT Budget / GLCD 240x64


    Software: LinVDR 0.7 - vdr-1.4.3-2 - Kernel-2.6.18 auf CF-Card ... 384 MB LiveBuffer auf Ramdisk

Jetzt mitmachen!

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