vdrrip unendlich langsam

  • Hallo zusammen,
    ich benutze den VDR (C't version, aber 3 - noch nicht 4) schon seit ca. einem Jahr und hatte nie Probleme mit vdrrip.
    Jetzt habe ich das System neu installieren müssen und seither läuft das Plugin unendlich langsam. Während das Konvertieren einer halben Stunde Film früher ne Stunde ging, benötigt es jetzt einen ganzen Tag.


    Die Datei /tmp/queuehandler.err liefert mir folgende Fehlermeldung:

    MMX2 suppoMMX2 supported but disabledrted but disabled
    3DNow supported but disabled
    3DNowExt supported but disabled
    File not found: 'frameno.avi'
    Failed to open frameno.avi
    The selected video_out device is incompatible with this codec.
    New_Face failed. Maybe the font path is wrong.
    Please supply the text font file (~/.mplayer/subfont.ttf).
    subtitle font: load_sub_face failed.


    1 duplicate frame(s)!


    1 duplicate frame(s)!


    1 duplicate frame(s)!


    Über google habe ich einen Hinweis gefunden, dass die Datei frameno.avi nur gelöscht werden muss wenn man keine Bitate festlegt. Da ich das über das VDR Menu aber mache, habe ich die rm-Zeile in der Datei /usr/bin/lav2avi.sh auskommentiert. Leider hat das gar nichts gebracht, da die Fehlermeldung immer noch beim Starten eines neuen Jobs erscheint.


    Das Zielverzeichnis für vdrrip und vdrconvert liegt auf einer anderen Platte als die Binärdateien, aber dass dürfte sicher auch kein Problem sein, oder?


    Woran kann es liegen, dass vdrrip so lange Zeit benötigt?


    Vielen Dank schonmal im voraus für eine Antwort!
    NJoyLife

  • Also ich hab jetzt mal versucht, alle von vddrip verwendeten Partitionen mit
    hdparm -d 1 /dev/hda etc.
    zu bearbeiten, aber es hat nichts gebracht.


    Hat niemand eine Idee, wieso VDR so langsam sein könnte? Oder gibt es ausser der queuehandler-Datei noch irgendwo eine Error-Datei? Ich wäre für jeden Hinweis dankbar...

  • Also ich weiss ja nicht welchen Codec Du verwendest, aber es steht doch
    ganz oben in der Meldung: MMX / 3DNow / SSE wird nicht verwendet. Das
    wird aber vermutlich extensiv genutzt - wenn man MPEG4 mit der normalen
    Integer-Einheit rechnen muss wird wohl auch der schnellste P4 zur Schnecke.


    Ich hatte den Effekt jetzt mit xvid. Habe zwar keine schöne Fehlermeldung
    bekommen, aber war sehr lahm. Und siehe da: im INSTALL von xvid steht, dass
    man für MMX/SSE den nasm/yasm braucht (configure muss ihn finden).
    Damit scheint er jetzt schon mal 3-4x so schnell zu laufen (auf meinem
    Pentium-M), wenn auch nicht grade Raketen-maessig.


    Generell wär ich auch interessiert wenn noch jemand anderer was
    schlaues zu dem Thema zu sagen hat.


    Einen ganz anderen seltsamen Effekt habe ich auch noch: der mencoder läuft am
    Anschlag (99% CPU), aber der Prozessortakt wird nicht hochgeschaltet. Etwa beim
    xvid-Compilieren geht der sofort hoch. Als wäre der mencoder irgendwie so freundlich,
    immer nur das zu nehmen was da ist und damit keinen Leidensdruck zu erzeugen?
    Klingelts da bei jemandem?


    Danke,
    hivdr

  • Zitat

    Original von hivdr
    Als wäre der mencoder irgendwie so freundlich,
    immer nur das zu nehmen was da ist und damit keinen Leidensdruck zu erzeugen?

    freundlich = nice, wahrscheinlich wird der mencoder mit dieser Option aufgerufen, um den Anwender nicht zu stören oder den Rechner unnötig aufzuheizen. Verringere einfach die Zahl hinter dem -nice , dann wird er unfreundlicher.

    vdr 1.4.7 sid von Tobi mit aktuellem sidux / TT-Budget & TT1.5 mit AVBoard 1.1

  • OK, das mit nice hatte ich auch noch im Hinterkopf und schon in der
    mencoder manpage gesucht, aber es gibt keine derartige Option.
    Allerdings gibt es ja auch das nice-Kommando, und siehe da: im queuerunner wird der mencoder in der Tat mit maximalem nice-Wert (+19) aufgerufen.
    Vermutlich kann ich ihn also zum Hochtakten bewegen indem ich das
    ändere. Ausprobieren kann ich es allerdings grade nicht, denn er
    rechnet noch..


    Hochrechnung derzeit: ca 12 Stunden für eine gut 2-stündige
    Sendung. Auf einem PentiumM@800. Also dann vielleicht doppelt
    so schnell @1600, aber das ist schon nicht so prickelnd.
    Das gleiche mit lavc statt xvid hatte nur 3 Stunden gedauert,
    also Faktor 4! Kann diesen Unterschied jemand bestätigen?


    Das Ergebnis mit lavc konnte ich dann auch nirgends ansehen,
    weder unter Windows mit xvid/divx, noch auf dem Haupt-VDR
    mit einer vielleicht ein halbes Jahr alten mplayer-Version!
    Der verwendete mencoder auf dem Server ist dagegen brandneu.
    Hat sich da so viel geändert? (FMP4 war glaub ich die Kennung)
    So gesehen ist jedenfalls xvid schon das vorzuziehende Format,
    das auch überall verstanden wird. Nur offenbar nicht das schnellste.


    hivdr

  • Und Nachtrag: Hochrechnung war etwas daneben, Dauer
    betrug 7.5h (@800) - aber also immer noch Faktor 2.5 gegenüber
    Encoding mit lavc.


    Zum Thema Nettigkeit:
    Bei nice-Faktor von +9 (statt +19) tat sich noch nichts, aber
    bei 0 (also "normal") wird dann hochgeschaltet! Damit habe
    ich also in etwa doppelte Echtzeit fürs Kodieren mit xvid @1600.
    Was wiederum mit der Erfahrung des Erstposters (vor seinen
    Problemen) übereinstimmt.


    Das Problem mit lavc ist offenbar nur der FourCC "FMP4". Ändert
    man diesen etwa zu DIVX, klappt auch das Abspielen. Wundert
    mich wirklich dass auch der mplayer sich davon beeindrucken lässt,
    aber ist so. Um gleich beim Generieren des Files den passenden
    FourCC zu setzen, gibt es die mencoder-Option -ffourcc.
    Das ganze im queuehandler.sh ergänzt und lavc ist die flottere
    Alternative zu xvid - Meinungen zum Qualitätsvergleich würden
    mich interessieren.


    hivdr

Jetzt mitmachen!

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