Beiträge von udobroemme

Entschuldigung, die Datei kommt hier.

XBMC rufe ich so auf:

xbmc --standalone -fs -l /var/run/lirc/lircd

Meine externalplayer.conf habe ich angehängt.
Der rcxbmc-Service macht nichts anderes als xbmc und einen Android-Emulator für mein TFT-Display zu starten.
Allerdings lasse ich, wie oben schon geschrieben, den X-Server nicht vom Softhddevice-Plugin starten, weil ich fürs graphtft-fe auch ein zweites Display mit dem Xserver starte.

Bei mir funktionierte bisher der Start von XBMC mit dem Externalplayer-Plugin. Mit der aktuellen Git-Version bekomme ich einen Segfault, wenn ich XBMC starten will.

segfault at 2 ip 00007f191fbb7ec3 sp 00007f18fbebc8d0 error 4 in libvdr-softhddevice.so.1.7.23[7f191fb9c000+28000]

Ah, das war der passende Hinweis. Ich habe jetzt Libjpeg8 installiert und damit ist alles gut. Vielen Dank.

Eine Kleinigkeit:
Die Jpeg-Grabbing-Geschichte funktioniert bei mir nicht.
Da die Libjpeg anscheinend kein pkg-File installiert, wird in /usr/lib nach der Library gesucht. Bei meiner 64Bit-Suse liegen die Libraries aber in /usr/lib64. Nun gut, den Pfad konnte ich selbst anpassen, allerdings kommt dann nach Programmstart folgender Fehler:

libvdr-softhddevice.so.1.7.23: undefined symbol: jpeg_mem_dest

Ich lasse den X-Server komplett unabhängig vom VDR über einen Dienst starten. Damit kann ich völlig problemlos über das Externalplayer-Plugin XBMC starten, ohne dass ich ein Suspend des Softhddevice-Plugins anstoßen muss.

Hurra. jetzt läuft bei mir auch das Atmo-Plugin. Jetzt hat die Quengelei bei mir auch ein Ende

Vielen Dank nochmal für Deinen Einsatz und Deine Geduld. Das Plugin ist echt super. Keinerlei Aussetzer, Top-Bildqualität und eine sehr geringe Prozessorauslastung. Was Du in ein paar Wochen geschafft hast, haben die anderen Programmierer mit der Xinelib in mehreren Jahren nicht so gut hinbekommen. Jetzt wird es wirklich langsam schwierig, am VDR noch was zu verbessern...

johns
Danke für die Erklärung, aber so weit geht mein Wissen/Können dann doch nicht. Vielleicht kommst Du ja demnächst mal dazu, das Scaling einzubauen.

Ich habe, um das Grabbing zu testen, in der grab.cpp des Live-Plugins mal jpeg auf false gesetzt. Jetzt kommt die Meldung:

softhddev: scaling not supported

Das Scaling wird auch fürs Atmo-Plugin benötigt. Ich habe mir mal im Xine-Plugin angeschaut, wie das Scaling dort gelöst ist. Dort wurde der y4mscaler eingebaut. Allerdings verstehe ich leider nicht so ganz, wo man den im Softhddevice-Plugin reinbasteln könnte...

Zitat von johns

udobroemme

Der Fehler ist aber was anderes.

Johns

<AufdemSchlauchstehModus>
Was anderes als was? Egal, mit dem letzten Checkout tut's
</AufdemSchlauchstehModus>

Die beiläufige Frage wegen Autocrop habe ich nur gestellt, weil ich sehnsüchtig auf das Grabbing warte...

Ich bin's mal wieder mit einem Bug unter SuSE. Die aktuelle GIT-Version lässt sich mal wieder nicht recht starten.
Bei einem Aufruf von

vdr -h

gibt es einen Segfault:

segfault at 50 ip 00007f8f03911b67 sp 00007fff6ef87b50 error 4 in libvdr-softhddevice.so.1.7.23[7f8f038f6000+23000]

Bei einem normalen VDR-Start lässt sich nach softhddevice kein anderes Plugin mehr laden.

*beiläufig erwähn*
Autocrop klingt gut, dafür wird doch das Grabbing gebraucht, oder?

Generell wird für das Atmo-Plugin die Grab-Schnittstelle genutzt, die auch die Screenshots für das Fernsehbild im Live-Plugin und so weit mir bekannt auch im VDRadmin (den kenne ich aber nicht) zur Verfügung stellt. Du könntest die Funktion also auch mit dem Live-Plugin testen.
Das Atmo-Plugin selbst ist schon länger nicht mehr weiterentwickelt worden, so ist z.B. die SD-FF-Grabbing-Funktion gar nicht auf die VDR-1.7.x-Plugin-Umgebung umgestellt worden. Ich habe mir damit geholfen, dass ich in den Atmo-Quellen alles, was mit SD-FF-Input zu tun hat, herauskommentiert habe. Die Quellen könnte ich Dir gern zur Verfügung stellen.
Die meisten Atmo-Nutzer nutzen mittlerweile das native Xine-Plugin, das Durchflieger entwickelt hat und das die ebenfalls von ihm geschriebene Grabbing-Funktion der xine-Lib nutzt.

Lange Rede, wenig Sinn, sinnvoll wäre es sicher, die Grabbing-Funktiono, wie sie im Softdevice-Plugin vorhanden war, auch ins Softhddevice zu implementieren, so dass man im Live-Plugin die Screenshots erkennen kann. Mit Glück funktioniert dann auch schon Atmo.

Ich habe keinen Windowmanager und mit der Option

-g 1920x1080+0+0

wird das Bild bildschirmfüllend dargestellt.

Diesmal saß mal wieder das Problem vorm Rechner. Kaum habe ich das richtige Audio-Device angegeben, dann kommt auch kein Knatterton mehr

Gerade habe ich mal einige Aufnahmen durchgeprobt.
Ich habe auch das Problemchen, dass bei HD-Aufnahmen beim Sprung zu Schnittmarken oder beim Verschieben derselben, das Bild nicht immer aktualisiert wird. Bei SD-Aufnahmen klappt es nach meiner Beobachtung immer. Das stört mich aber nicht weiter.

Auf jeden Fall bin ich höchst beeindruckt, wie gut das Plugin jetzt schon flutscht. Wenn demnächst noch die Grabbing-Funktion für mein Atmolicht funktioniert, kann ich das ressourcenfressende Xine entsorgen.

Das Alsa-SP/Dif-Passthrough funktioniert bei AC3 so noch nicht. Es wird anscheinend kein AC3-Flag an den Receiver gesendet. Man hört nur das bekannte 'Geschnatter' eines als PCM ausgegebenen AC3-Bitstreams.

Ich bin's mal wieder und nerve mit Suse 12.1
Wenn bei mir die aktuelle GIT-Version des Plugins installiert ist, kommt beim Programmstart folgender Fehler:

segfault at 2d0 ip 00007fe8fe8a2181 sp 00007fff578546f0 error 4 in libpthread-2.14.1.so[7fe8fe895000+18000]

VDR wird allerdings trotzdem ausgeführt, nur werden keine weiteren Plugins mehr geladen. Der Fehler lässt sich auch schon provozieren, indem ich einfach

vdr --help

aufrufe. Lösche ich das Plugin aus dem Verzeichnis der installierten Plugins, gibt es keinen Fehler.
Ich nutze übrigens VDR-1.7.22.

Ich habe das Plugin jetzt mit VDPAU laufen und bin begeistert. Der A/V-Sync ist perfekt und das Scaling der SD-Sender ist auch viel besser als mit VAAPI. Meinetwegen kann es jetzt an die Grabbing-Funktion fürs Atmo-Plugin und SP/Dif-Passthrough gehen

fnu:
Bei mir funktioniert xrandr mit den Nvidia-Treibern ohne Probleme.

Probier es doch mal mit folgenden Optioonen:

Option "ExactModeTimingsDVI" "True"
Option "ModeValidation" "NoVesaModes,NoXServerModes"

Ich habe das Ganze noch etwas eleganter gelöst. Ich habe im runvdr-Skript Folgendes am Anfang eingebaut:

/usr/bin/szap-s2 -a 0 -c /etc/vdr/astra_szap-s2.conf -x -S 0 "ARD"
/usr/bin/szap-s2 -a 1 -c /etc/vdr/astra_szap-s2.conf -x -S 0 "ARD"

Szap-s2 und die szap-s2.conf findest Du im Treiberarchiv. Die Pfade musste Du natürlich dementsprechend anpassen, wo Du die Dateien hinpackst. Die Befehle bewirken, dass beide Tuner einmal auf ein SD-Programm getunt werden und sich das Programm szap2 dann beendet. Somit kann VDR dann auch auf HD-Kanälen gestartet werden.

Bei 12.1 ist es auch noch Version 3.6, dann ist es wohl nicht der Linker...