softhddevice und yavdr 0.4 - hat das jemand am laufen?

Zitat von johns

Und es geht hier nur um den Bugfix und nicht um softhddevice.

Hab ich klar und deutlich verstanden und auch so signalisiert.

Aber nochmal, es geht nicht um einen einzelnen eigen-kompilierten VDR bei uns, wo man das mal eben "hinpfuscheln" kann. Egal was wir in unseren Repo's machen es zieht einen Rattenschwanz an Arbeiten nach, die Du nicht machen musst, auch wenn Du jetzt 100 Jahre argumentierst. Diese Arbeitszeit stecken wir aktuell besser in eine komplett neue fehlerbereinigte yaVDR Version, die dann auch auf Dein Plugin abgestimmt ist.

Aber hey, ich bin der letzte der Dich nicht im Team willkommen heißt, dann kannst Du gerne das 0.4er Repository aufhübschen ...

Regards
fnu

Moin,

weil mir heute xine(liboutput) bei der Sportschau mal wieder durch Artefakte und

Feb 25 18:42:54 vdr vdr: [3389] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
Feb 25 18:43:12 vdr vdr: last message repeated 163 times

im syslog den spass vermiesste hab ich mich dran gemacht und das softhddevice eingerichtet. Ich bin extrem begeistert, Zapping-zeiten sind 1a und endlich keine tonaussetzer mehr.

Vielen dank für die arbeit an johns und alle anderen die hier tips und scripts gepostet haben

Zitat von TesaFilm

Moin,

weil mir heute xine(liboutput) bei der Sportschau mal wieder durch Artefakte und

im syslog den spass vermiesste hab ich mich dran gemacht und das softhddevice eingerichtet. Ich bin extrem begeistert, Zapping-zeiten sind 1a und endlich keine tonaussetzer mehr.

Vielen dank für die arbeit an johns und alle anderen die hier tips und scripts gepostet haben

Hi,

das hat mich motiviert- und sofort angesteckt. Läuft so wie ich mir das immer gewünscht habe. Yavdr & softhddevice- so macht das ganze richtig spass!
Auch von mir vielen Dank an alle!

Bei dem Versuch das menuorg-appswitcher script anzupassen hab ich ledier keinen Erfolg:

[2096] connect from 127.0.0.1, port 34292 - accepted
[2096] ERROR (svdrp.c,426): Broken pipe
[2096] closing SVDRP connection

auf der console funktioniert '/usr/bin/svdrpsend plug softhddevice SUSP' perfekt, kann mir jemand sagen wo der Fehler liegt?

Vielleicht vertippt?

kann ich ausschließen, wenn ich die zeile in die console copy paste stoppt er wie gewuenscht

Was ist das menuorg Appswitcher?
svdrp funktioniert nich wenn ein VDR Plugin gerade aktiv ist.

Nimm besser dbus über das dbus2vdr Plugin.

/usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Plugins/softhddevice de.tvdr.vdr.plugin.SVDRPCommand string:'SUSP'

cu

Das wars! Große Freude hier, vielen Dank!

Zitat von CKone

Für alle die gern den taskswitcher zum xbmc toggeln benutzen hier eine kleine Änderung um softhddevice einzubinden.

cat /usr/share/vdr/menuorg-appswitcher

Code

if [ "x$STANDALONE" = "xyes" ]; then
	/usr/bin/svdrpsend plug softhddevice SUSP
#	$STOP vdr-frontend
	sudo /sbin/initctl start --no-wait toggle JOBNAME=$APP OPTIONS=$OPTIONS STANDALONE=yes
else
	sudo /sbin/initctl start --no-wait toggle JOBNAME=$APP OPTIONS=$OPTIONS
fi

Sowie
cat /etc/init/xbmc-exit.conf

Code

*)
    	signal-event reset-display-rate
#    	initctl emit vdr-frontend-restart
    	/usr/bin/svdrpsend plug softhddevice RESU
    	;;

Getestet mit natty und oneiric

Christian

Alles anzeigen

das muss natürlich genau so über dbus SUSP/RESU gelöst sein wie vorab erklärt damit es übers menu(org) geht.

Ich habs nur mit ner separaten Taste auf der Fernbedinung über irexec angesteuert und das ging auch mit svdrpsend

Christian

johns

ich suche nun seit 4 tagen warum die upstart scripte einfach das RESU signal sendet. doch es ist so das der parameter -s das problem ist!

/usr/bin/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown.wrapper -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 -w 60 -P"softhddevice -f -s -g 1920x1080+0+0 -d :1" -Pdbus -P"sc -B0 -B1 -B2" -P"dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hooks-wrapper=/usr/share/vdr/plugins/dbus2vdr/shutdown-wrapper" -Pepgsearchonly -Piptv -Pconflictcheckonly -P"live --port=8008 --ip=0.0.0.0 --epgimages=/var/cache/vdr/epgimages" -Pgraphtft  -Pstreamdev-server -Pmarkad -Pquickepgsearch -Pepgsearch -Pmenuorg -P"skinpearlhd --epgimages=/var/cache/vdr/epgimages" -Ptext2skin -Pextrecmenu -Pfemon -Pchannellists -Pwirbelscan -Pdynamite

das führt dazu, dass die ausgabe NICHT im suspended gestartet. ich weis nicht warum, aber irgendwie passt da was noch nicht. hab auch schon die reihenfolge der optionen gedreht oder das -g weggelassen. johns könntest du nochmal schauen was der grund sein könnte?

EDIT: Mist falscher Thread

traxanos

ich bleib mal hier im Thread.

Ich hab jetzt seit ca 10 Tagen mit dem Plug im yavdr Kontext (natty wie oneiric) gearbeitet und darf jetzt mal mit den Großen reden

Nee Spaß beiseite. Aber ich will jetzt auch nicht den Dialog führen mit dem Berg und dem Propheten, aber ich glaub du machst dir den Weg steiniger als er ist. Das Softwaredesign bringt hier einfach keine Front-/Backend Lösung mit, deshalb sollte man es auch nicht mit aller Gewalt in eine solche pressen und den pragmatischen Schluss ziehen:

echo "manual" >> /etc/init/vdr-frontend.override

Dazu noch menuorg-appswitcher wie xbmc-exit.conf mit dem dbus Befehl von Keine_Ahnung versehen und das Ding ist in nem Dreizeiler integriert.

Was noch fehlt sind zwei Patches um den Launcher wieder zum Leben zu erwecken:
Das erste um das plug rahmenlos im Openbox Fenster zu starten, das schauen Horchi und ich uns diese Woche an (es sei denn ihr habt schon ne Lösung?), hier hat johns schon Bereitschaft signalisiert dieses einzubauen. Das andere ist das man dem Plug es abgewöhnen muss den Bildschirm aufzuzoomen wenn man es im Fenster betreibt und mit der Maus reinklickt. - Ich glaube aber nicht das johns hier ein Spielverderber ist

Ansonsten seh ich das (natürlich neben dem WFE, dem scripting und templating welches noch fehlt) nicht so steinig wie du.

Hab ich was Grundsätzliches übersehen? - Ich betreibe das so ohne jegliche Seiteneffekte seit ~10 Tagen im Test und seit ca 5 Tagen parallel produktiv, selbiges bei Horchi

Gruß Christian

Zitat von CKone

Das erste um das plug rahmenlos im Openbox Fenster zu starten, das schauen Horchi und ich uns diese Woche an (es sei denn ihr habt schon ne Lösung?), hier hat johns schon Bereitschaft signalisiert dieses einzubauen.

Dafür muss kein Patch eingebaut werden. Das Plugin wird einfach ohne Fullscreen gestartet und Openbox erkennt das Fenster und maximiert es und entfernt die Fenster-Deko. Siehe die Openbox-Konfiguration. Mit vdr-sxfe und xine-ui machen wir es jetzt schon genauso. Ich würde auch Wert darauf legen, dass es so bleibt, weil ich das für den kommenden Desktop brauche. Einfach mit xwininfo mal nachsehen wie der Titel des Openbox-Fensters aussieht und die Openbox-Konfiguration anpassen. Sollte eine 5 Minuten-Sache sein.

Gerald

perfekt. - schau ich mir heute Abend an. Bei Graphtft hatten wir (in natty) auch ein patch benötigt um es rahmenlos zu betreiben. Wenn es ohne geht: umso besser, Punkt abgehakt.

Zitat von gda

ohne Fullscreen gestartet und Openbox erkennt das Fenster und maximiert es

aber ist maximiert nicht eher blöd da man dann nicht mehr an den launcher kommt? Ihr hattet wenn ich mich recht erinnere immer die Zeile ganz links nicht geschrieben, also 1919x1080 und deshalb kam dieser ganz links nach hervor?

Christian

Zitat von CKone

aber ist maximiert nicht eher blöd da man dann nicht mehr an den launcher kommt?

Nein, das ist überhaupt nicht blöd, weil maximiert nicht das Selbe wie fullscreen ist. Ich arbeite gerade viel mit dem Desktop wo das maximieren nicht von Openbox sondern von Devilspie gemacht wird und weiß das deshalb ganz genau.
Wenn du Fullscreen hast, dann kann nichts über dem Fenster liegen. Wenn es maximiert ist, dann kann sich ein schmales, unsichtbares Fenster des Launchers über das Ausgabe-Fenster legen.

Gerald

ok, teste ich gern - ist derzeit der einzig offene Punkt hier.

Christian

In meinen Tests benutze ich vdr-frontend mit RESU im post-start und SUSP im post-stop - shd ist konfiguriert audio/video zu stoppen im Suspend und es startet suspended um keine Race Conditions zwischen vdr und X zu bekommen (Es sollte nicht das erste Programm auf dem Xserver sein und etwaige Einstellungen (openbox-tools) sollten schon passiert sein). Hier hatte ich mich beim Testen verhaspelt weil die XBMC Version die ich drauf habe suboptimal zu sein scheint (es bleibt ein stale/defunct xbmc.bin der nur mit kill -9 weggeht)

Also grundlegend gebe ich dir Recht - nicht so das große Ding es in das momentane Framework zu bekommen - aber ich stimme traxanos zu das suspended durch keine Aktion des VDR (wie auch immer) gestört werden sollte. Das führt bestenfalls zu unerwarteten Resultaten (andere würden es dann Bug nennen )

Die Fensterdeko ist hier auch der einzige Punkt (aber simpel) - was das Maximieren angeht, hatte johns ja bereits signalisiert das dies in Kürze der Default sein wird (dann kann man sich -f und -g XxY+0+0 sparen). Letzteres kann man abwarten.

EDIT:
- Soundeinstellungen muss in die Plugineinstellungen templated werden
- setup.conf Values muss die Interlacer Werte gesetzt bekommen

Zitat von steffen_b

Hier hatte ich mich beim Testen verhaspelt weil die XBMC Version die ich drauf habe suboptimal zu sein scheint (es bleibt ein stale/defunct xbmc.bin der nur mit kill -9 weggeht)

hatte ich in oneiric zuerst auch - horchi hat mir remote die xbmc-p8 ppa Pakete mit aptitude reingespielt ohne die Abhängigkeiten zu versauen, die Version läuft soweit rund hier.

Christian

Also steffen_b hat das perfekt erklärt warum das ganze im suspended laufen sollte/muss. Wer sehen will wie ich aktuell den start stop für precise baue:

https://github.com/yavdr/yavdr…tc/init/softhddevice.conf damit bekommt man das ganze auch als start/stop, ohne nen main exec zu haben, hin.

und die vdr-frontend.conf hast du auch abgeklemmt und vdr.conf im Wesentlichen so belassen?

Somit bereitet nur das "-s" aktuell Probleme=

Christian

Zitat von steffen_b

Also grundlegend gebe ich dir Recht - nicht so das große Ding es in das momentane Framework zu bekommen - aber ich stimme traxanos zu das suspended durch keine Aktion des VDR (wie auch immer) gestört werden sollte. Das führt bestenfalls zu unerwarteten Resultaten (andere würden es dann Bug nennen )

Ich glaube ihr wollt was anderes als Suspend

Suspend ist ja die Funktion des VDR die anspringt wenn kein Nutzer mehr in Reichweite ist ("power" bei laufender Aufnahme oder User inaktivität schlägt zu), und die muss ja triggern spbald sich ein Nutzer dem VDR gegenüber bemerkbar macht.

cu