PDAexport verursacht nach Wechsel auf vdr-1.6 hohe Last

    Hallo,


    bis letzte Woche verwendete ich vdrdevel-experimental-multipatch 1.5.13 und bin dann auf vdr-experimental-multipatch 1.6.0 gewechselt.


    Die paketunabhängigen Addons habe ich (hoffentlich) alle entsprechend umkonfiguriert.


    Seit einigen Monaten bin ich begeisterter Anwender des pdaexport-Scriptes [1] was unter vdrdevel nach ein paar Anpassungen wunderbar lief.


    Nach der Umstellung von vdrdevel auf vdr habe ich natürlich auch in /etc/pdaexport/pdaglobal.conf den Pfad zu mplayer korrigiert:


    Code
    MPLAYER="/usr/share/vdr-plugin-mplayer/mplayer"

    im Orginalscript stand hier MPLAYER="mplayer", was aber unter ctvdr nicht klappte.


    Wenn ich jetzt einen Export starte get die Prozessorlast des vdr (!) auf 100%, also nicht die Last des pdaexport.sh bzw. der hiervon aufgerufenen Komponenten wie mplayer oder vdrsync.pl. Ich verwende übrigens das Profil 3 "HQ-XVID-Profile"


    Dadurch fängt das Live-Bild an zu ruckeln. Wiedergabe von Aufzeichnungen werden ganz zur Qual.


    Vermutlich habe ich doch noch irgendwo eine Einstellung vergessen oder muss ein vdr/devel-spezifiesches Paket nachladen. Hat jemand eine Idee?


    [1] [ANNOUNCE] PDAExport 0.0.7b - VDR-Aufnahmen über das OSD in AVIs konverieren

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Einmal editiert, zuletzt von HolgerAusB ()

    Zitat

    Original von HolgerAusB
    Nach der Umstellung von vdrdevel auf vdr habe ich natürlich auch in /etc/pdaexport/pdaglobal.conf den Pfad zu mplayer korrigiert:


    Code
    MPLAYER="/usr/share/vdr-plugin-mplayer/mplayer"

    im Orginalscript stand hier MPLAYER="mplayer", was aber unter ctvdr nicht klappte.


    Das Script /usr/share/vdr-plugin-mplayer/mplayer verwendet eine andere Konfigurationsdatei als /usr/share/vdrdevel-plugin-mplayer/mplayer. Vergleiche mal die Werte in /etc/vdr/plugins/vdrmplayer.sh.conf mit /etc/vdrdevel/plugins/vdrdevelmplayer.sh.conf.


    Ich denke aber nicht, dass das Script hier aufgerufen werden sollte. Mit MPLAYER="mplayer" ist wohl eher der Aufruf des wirklichen mplayer-Programms gemeint. Das Script gibt dem mplayer schon einige Parameter mit, so dass das Video direkt auf die FF-Karte ausgegeben werden kann. Wahrscheinlich behindern sich jetzt der PDAexport und VDR, da sie beide auf die FF-Karte ausgeben wollen.


    Tom

    Wenn ich die Variable auf MPLAYER="/usr/bin/mplayer" oder nur MPLAYER="mplayer" setze hört das pdaexport.log hier auf:


    Code
    ++ /usr/bin/mplayer /var/lib/video.00/test/Testfilm/2004-06-09.23.57.01.01.rec/001.vdr -v -frames 0
++ grep 'VIDEO: '
++ awk '{print $3}'

    und nichts passiert mehr


    Die beiden Dateien /etc/vdr[devel]/plugins/vdr[devel]mplayer.sh.conf sind im übrigen identisch, außer das "vdrdevel" durch "vdr" ersetzt sind. Beide Dateien enthalten im übrigen einen Workaround um festzustellen welche Kartennummer die FF gerade hat.


    EDIT:
    Außerdem wird mplayer meines erachtens nach nur dazu benutzt um die Video- und Audiospuren und vielleicht noch die Auflösungen zu ermitteln (?)


    EDIT 2:
    Ich hänge mal das Log eines erfolgreichen Durchlaufs mit MPLAYER="/usr/share/vdr-plugin-mplayer/mplayer" an. Der Testfilm ist 3:45 Minuten kurz.

    Zitat

    Original von HolgerAusB
    Wenn ich die Variable auf MPLAYER="/usr/bin/mplayer" oder nur MPLAYER="mplayer" setze hört das pdaexport.log hier auf:


    Code
    ++ /usr/bin/mplayer /var/lib/video.00/test/Testfilm/2004-06-09.23.57.01.01.rec/001.vdr -v -frames 0
++ grep 'VIDEO: '
++ awk '{print $3}'

    und nichts passiert mehr


    Versuch doch mal, das Kommando auf der Kommandozeile auszuführen. Neuere mplayer-Versionen verhalten sich bei diesen Aufrufen zur Feststellung der Video-Eigenschaften etwas seltsam.


    Bei vdrrip hatte ich auch damit zu kämpfen. Zum Beispiel liefert
    mplayer test.avi -identify -frames 0
    gar nichts mehr. Man muss das Kommando so aufrufen:
    mplayer test.avi -identify -frames 1 -vo md5sum:outfile=/dev/null -ao null


    Einen ähnlichen Patch braucht anscheinend auch PDAexport. Wenn mit diesen oder ähnlichen Optionen auf der Kommandozeile die Informationen zur Auflösung usw. erscheinen, solltest du sie einfach in PDAexport einbauen. Dann funktioniert es auch mit dem mplayer-Programm.


    Tom

    Oben hatte ich im Edit 2 noch ein log angehängt. Hier wird in späteren Aufrufen tatsächlich mit "-ao null -vo null" gearbeitet.


    Folgendes passiert beim manuellen Aufruf:


    Die gesuchte "Video: "-Zeile ist vorhanden und würde das gewünschte liefern. Allerdings verhält sich die SSH-Konsole nach diem Befehl sehr komisch. Buchstaben werden nicht angezeigt aber nach Enter ausgeführt. Enter führt nicht zu einem Zeilenumbruch sondern der Prompt wird in der gleichen Zeile einfach wieder angehängt:


    "vdr1:~# vdr1:~# vdr1:~# vdr1:~# "


    Vermutlich ist das die Ursache für den Abbruch.


    mit -vo null -ao null :


    Code
    vdr1:~# /usr/bin/mplayer /var/lib/video.00/doku/DVD-Test_für_VDR/2004-06-09.23.57.01.01.rec/001.vdr -v -frames 0 -vo null -ao null | grep 'VIDEO: '
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not open config files /root/.lircrc and /etc/lirc//lircrc
mplayer: No such file or directory
Failed to read LIRC config file ~/.lircrc.
VIDEO:  MPEG2  720x576  (aspect 2)  25.000 fps  15000.0 kbps (1875.0 kbyte/s)

    die Konsole lässt sich dann auch wieder bedienen.


    über das Skript sieht's so aus:


    Ich habe jetzt in der pdfglobal.conf den Wert wie folgt geändert:


    Code
    MPLAYER="/usr/bin/mplayer -vo null -ao null

    damit bleibt er nicht stehen, aber ich habe die Lastprobleme mit vdr um 100% trotzdem wieder, während vdrsync.pl und anschließen mplex nur bis etwa 20% hochgehen.

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    3 Mal editiert, zuletzt von HolgerAusB ()

    Jetzt kann ich dir wohl nicht mehr weiterhelfen. Seltsam finde ich die Logs:
    File a001250130bf20 is in wrong format - aborting
    und
    SVDRP message: 'Mehrfachexport gestartet...'


    Aber beides scheint nicht zu verhindern, dass der Export gestartet wird.


    Vielleicht ist die Prozessorbelastung bei der mplayer-Konvertierung wirklich so hoch. Dann hilft vielleicht der Einsatz von nice. Ich kann dir nur raten, alle Aufrufe einzeln auf der Kommandozeile zu testen.


    Tom

    Zitat

    Original von TomG
    SVDRP message: 'Mehrfachexport gestartet...'
    [...]
    Dann hilft vielleicht der Einsatz von nice


    Das ist ja normal. Das Script teilt mir per OSD mit, was es gerade macht. Mehrfachexport bedeutet, dass ich zunächst per rec-commands mehrere vdr-Aufnahmen zur Konvertierung markieren kann und zwar jede mit unterschiedlichen Profilen (HQ oder LQ XVID, oder PDA mit niedriger Auflösung...) und zum Schluss starte ich über Befehle den Mehrfachexport, der die Filme nacheinander (!) konvertiert, also Queue-mäßig. Im weiteren Verlauf des Log sagt er mir auch jeweils per OSD, welchen Film er als nächstes bearbeitet und wann ein Film fertig ist.


    die pdaglobal.conf hat einen Parameter nice, der schon auf 18 stand. Selbst wenn ich das auf den Maximalwert 19 stelle passiert das gleiche.


    Das ganze scheint aber auch Abhängig vom Sender bzw. der Aufzeichnung zu sein. Bis etwa nominale 8 MBit/s habe ich keine Aussetzer. Sender mit 15 MBit/s ruckeln. Wobei QVC mit nu 5 MBit/s trotzdem ruckelt. Bei Aufzeichnungen ist das ebenfalls unterschiedlich. Ist mir vielleicht unter devel nicht aufgefallen, weil ich nur die "richtigen" Sender und Aufzeichnungen angesehen habe.

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Einmal editiert, zuletzt von HolgerAusB ()

    Zitat

    Original von HolgerAusB
    die pdaglobal.conf hat einen Parameter nice, der schon auf 18 stand. Selbst wenn ich das auf den Maximalwert 19 stelle passiert das gleiche.


    Wird dieser Parameter auch wirklich verwendet? Wenn ja, weiß ich auch nicht weiter.


    Zitat


    Das ist ja normal. Das Script teilt mir per OSD mit, was es gerade macht. Mehrfachexport bedeutet, dass ich zunächst per rec-commands mehrere vdr-Aufnahmen zur Konvertierung markieren kann und zwar jede mit unterschiedlichen Profilen (HQ oder LQ XVID, oder PDA mit niedriger Auflösung...) und zum Schluss starte ich über Befehle den Mehrfachexport, der die Filme nacheinander (!) konvertiert, also Queue-mäßig. Im weiteren Verlauf des Log sagt er mir auch jeweils per OSD, welchen Film er als nächstes bearbeitet und wann ein Film fertig ist.


    Warum verwendest du nicht vdrrip? Meiner Meinung nach kann es das auch alles.


    Tom

    laut oben angehängtem log wird nice auch verwendet:


    nice -n 18 vdrsync.pl|mplex|ffmpeg|...


    Ich hatte vor einigen Jahren mal mit vdrrip oder vdrconvert (eher letzteres) versucht ein divx zu machen. Leider hat das Ergebnis unter Windows nicht funktioniert. Das Video war zu schnell.


    Mit PDA-Export kann ich relativ schnell zwischen verschiedenen Profilen für unterschiedliche Qualitäten oder Endgeräte umschalten

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Zitat

    Original von HolgerAusB
    laut oben angehängtem log wird nice auch verwendet:


    nice -n 18 vdrsync.pl|mplex|ffmpeg|...


    Auch mplayer? Denn da war ja wohl das Problem ...


    Zitat

    Ich hatte vor einigen Jahren mal mit vdrrip oder vdrconvert (eher letzteres) versucht ein divx zu machen. Leider hat das Ergebnis unter Windows nicht funktioniert. Das Video war zu schnell.


    Mit PDA-Export kann ich relativ schnell zwischen verschiedenen Profilen für unterschiedliche Qualitäten oder Endgeräte umschalten


    vdrconvert hat mir auch nicht so zugesagt. Aber vdrrip lässt sich recht gut bedienen und hat auch Profile. Wie sich die Videos unter Windows verhalten, weiß ich nicht. Aber ein Versuch ist es wert.


    Tom

    Nee, mplayer nicht aber der taucht auch unter "top" nicht unter den Höchstlast-Prozessen auf. Und ich bin auch der Ansicht, das mplayer gar nicht so viel rechnet, der wird IMHO nur zum Auslesen einiger Video-Parameter missbraucht.


    vdrrip ist meine ich ein deamon der immer im Hintergrund läuft und beim runterfahren ewig braucht, bis er sich beendet? Deshalb hab ich den, glaub ich, irgendwann removed.

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Zitat

    Original von HolgerAusB
    Nee, mplayer nicht aber der taucht auch unter "top" nicht unter den Höchstlast-Prozessen auf. Und ich bin auch der Ansicht, das mplayer gar nicht so viel rechnet, der wird IMHO nur zum Auslesen einiger Video-Parameter missbraucht.


    Dann habe ich deine Beschreibung falsch verstanden:

    Zitat

    damit bleibt er nicht stehen, aber ich habe die Lastprobleme mit vdr um 100% trotzdem wieder, während vdrsync.pl und anschließen mplex nur bis etwa 20% hochgehen.


    Was verursacht denn nun die hohe Last?


    Zitat

    vdrrip ist meine ich ein deamon der immer im Hintergrund läuft und beim runterfahren ewig braucht, bis er sich beendet? Deshalb hab ich den, glaub ich, irgendwann removed.


    Der Hintergrundprozess verbraucht kaum Ressourcen, der schläft sowieso die meiste Zeit. Die lange Wartezeit beim Runterfahren ist sicher verbesserungswürdig, wirklich störend finde ich sie aber auch nicht.


    Tom

    Zitat

    Original von TomG
    Was verursacht denn nun die hohe Last?


    Genau das ist die Quizfrage. Denn das verwunderliche ist ja, dass der vdr-Prozess zwischen 80% und tlw. über 100% Last verursacht und die Video-Umwandelprogramme nur um 20%...

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Zitat

    Original von HolgerAusB


    Genau das ist die Quizfrage. Denn das verwunderliche ist ja, dass der vdr-Prozess zwischen 80% und tlw. über 100% Last verursacht und die Video-Umwandelprogramme nur um 20%...


    Stimmt, das hattest du erwähnt. ;)


    Vielleicht solltest du die Quizfrage mal dem Autor von PDAexport stellen. Möglicherweise hat er die richtige Idee, wo das Problem liegt.


    Wo werden eigentlich die fertigen Videos und die temporären Dateien abgelegt? Wenn sie im Videoverzeichnis liegen, würde der VDR versuchen sie zu scannen. Keine Ahnung, was das für Auswirkungen hat.


    Tom

    Zitat

    Original von TomG
    Wo werden eigentlich die fertigen Videos und die temporären Dateien abgelegt? Wenn sie im Videoverzeichnis liegen, würde der VDR versuchen sie zu scannen. Keine Ahnung, was das für Auswirkungen hat.


    Dafür gibt es einen Parameter in der pdaglobal.conf und liegt in meinem Fall außerhalb des Videoverzeichnisses von vdr und es fürt auch kein Symlink vom /var/lib/video.00/... nach /path/to/pda


    Außerdem überwacht doch vdr IMHO nicht ständig das Videoverzeichnis, oder?

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    Zitat

    Original von HolgerAusB


    Dafür gibt es einen Parameter in der pdaglobal.conf und liegt in meinem Fall außerhalb des Videoverzeichnisses von vdr und es fürt auch kein Symlink vom /var/lib/video.00/... nach /path/to/pda


    Außerdem überwacht doch vdr IMHO nicht ständig das Videoverzeichnis, oder?


    Du hast Recht. Wie du siehst gehen mir die Ideen aus ...


    Tom

    Moin!


    Sorry, bin grade erst aus dem Urlaub zurück! Ist das Problem noch aktuell?


    Bin momentan auch dabei mir einen Debian-VDR mit den Paketen von e-tobi zu bauen und 'nem VDR 1.6.x, dann werde ich auch PDAExport testen, mal sehen, ob ich das Problem dann auch habe.


    Eigentlich kann aber das Script auf den VDR einen Einfluss haben. Prinzipiell wird ja über at das Script in einer eigenen Shell gestartet. Das die Prozessorlast dabei auf 100% geht ist ja OK, aber 1. sollte der VDR-Prozess nicht die Last verursachen und 2. das FFMPEG mit "nice -n18" gestartet werden, daher auch keinen anderen Prozess behindern...


    Naja, wie gesagt, ich probier es mal aus, weiß aber noch nicht 100%ig wann. Ziehe grade auch noch um und wechsel den Arbeitsplatz. Ist ein bisschen viel auf einmal!! ;)


    Gruß


    Toxic

    Registrierter VDR-User #1275


    VDR-Server: Proxmox 7.1 - LXC Container - Debian 11.5 - eTobi-VDR 2.6.0

    DVB-Hardware: Digital Devices - Cine S2 V5.5 und V6

    VDR-Clients: FireTV Sticks 2 bis 4K Max und Kodi 19.4

    Ob es noch aktuell ist, kann ich erst am Donnerstag oder Freitag testen.


    Ein anderes Problem ist uns aber noch aufgefallen. Der erste mplayer Aufruf zum Ermitteln der Videogröße erfolgt ohne Parameter "-ao null -vo null", was bei ct zu Problemen führt, Details siehe hier in diesem Thread. Ich hatte das gelöst, indem ich den Pfad zu mplayer auf das Script des debian-vdr-mplayer-Plugins verbogen habe.


    Richtiger wäre aber das Script um die Parameter zu erweitern, oder?


    Allerdings hat das natürlich nichts mit dem Lastproblem zu tun.


    Wie ich oben schon schrieb, sind die Ruckler auch Senderabhängig.

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    OK, das mit den Parametern wundert mich, aber ich schaue mal! Wird aber auch erst nächste Woche was...


    Gruß


    Toxic

    Registrierter VDR-User #1275


    VDR-Server: Proxmox 7.1 - LXC Container - Debian 11.5 - eTobi-VDR 2.6.0

    DVB-Hardware: Digital Devices - Cine S2 V5.5 und V6

    VDR-Clients: FireTV Sticks 2 bis 4K Max und Kodi 19.4

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden