softhddevice und yavdr 0.4 - hat das jemand am laufen?

Zitat von CKone

Aber die oldabi Pakete gibts doch nur in 0.7, oder hab ich was auf den Augen? :o

Korrekt, hatte ich aber auch geschrieben ...

ffmpeg aus dem PPA entspricht den libav Versionen der entsprechenden Ubuntu LSB-Releases, weil die ffmpeg Entwickler regelmäßig gegen libav merge'n. Die parallele Installation OLDABI und NEWABI hat halt den Vorteil, das alles bestehende weiter funktioniert. Nur wenn man ein Paket gegen OLDABI bauen will muß man sich was einfallen lassen. markad baute z.B. leider nicht geben ffmpeg 0.9, was jetzt aber kein Vorwurf sein soll.

Regards
fnu

markad hatte ich mir schon gedacht, was wäre denn sonst in so einer yavdr distri anfällig? VDR in meiner Konfig scheint hier ok, spielt xbmc auch bei ffmpeg mit?

ich kann markad hier gern mal testen obs gegen die 0.8 durchläuft

Christian

hier was von der ffmpeg Seite:

Zitat

June 24, 2011

Instead of having fun outside in the warm summer months, we have made a
new release: FFmpeg 0.8!
All bugfixes and merges from ffmpeg-mt and libav are included in this release.
Although we still recommend you use the latest git version of our code.

We have also made an
OLDABI release: FFmpeg 0.7.1.
It contains almost all of the features, bugfixes and merges of ffmpeg-mt and libav of 0.8,
while being compatible with the 0.6 ABI and API. It has a few missing features,
read the Changelog for more information.

Alles anzeigen

das wäre ja quasi das aus deinem Link. Vllt funktioniert das ja, wär für alle das Einfachste.

Christian

Zitat von CKone

markad hatte ich mir schon gedacht, was wäre denn sonst in so einer yavdr distri anfällig? VDR in meiner Konfig scheint hier ok, spielt xbmc auch bei ffmpeg mit?

Wir können niemanden daran hindern sich andere Pakete aus den Ubuntu-PPAs zu installieren. Mittelfristig werden wir das eventuell auch eher vereinfachen. Deswegen muss es für das Problem eine Lösung geben, die es ermöglicht ohne zu Patchen und neu zu Kompilieren auch Anwendungen zu nutzen, die das alte ABI benutzen.

Gerald

Zitat von CKone

spielt xbmc auch bei ffmpeg mit?

Ja, ganz wichtig.

Ich weiß nicht ob Oneiric am Ende vergebene Liebesmüh ist, für Precise ist der Akt mit OLDABI & NEWABI nicht notwendig. Effektiv gehen aber beide PPAs den gleichen Weg, das ist gut.

Persönlich würde ich aber das PPA für alle LSB Releases bevorzugen, weil es konsistent von Lucid bis Precise ist und die Nutzung von Lucid & Natty ermöglicht. Vor allem da ich mir vorgenommen habe unser Lucid PPA bis LTS Ende 2013 zur Verfügung zu halten.

Regards
fnu

fein, das gefällt mir immer besser!

Für Natty muss man neben dem Jon Severinsson's FFmpeg PPA noch dieses hier bemühen https://launchpad.net/~klaus-v…75/+listing-archive-extra , danach kann man den oneiric vdr-plugin-softhaddevice source sauber bauen.

Das remux dpatch welches ich weiter vorn für oneiric hochgeladen hab läuft auch auf 1.7.21 natty sauber durch.

Ich teste das mal durch ob mit den OLDABI Paketen noch alles vorher vorhandene sauber läuft.

Christian

Also in dem setup spielen beide natty's bei mir absolut unauffällig, inklusive xbmc (das p8 Paket), graphtft etc. Nix zu bemängeln, genauso gut wie in oneiric.

fnu: Super Tipp mit der OLDABI/OLDAPI, Respekt!

Christian

CKone

Gerne doch, wenn ich helfen kann, immer.

Mit 0.3 @ Lucid würde das genauso laufen, man müßte da aber bei "softhddevice" VA-API abklemmen. Ich scheue mich aber das als "macht-alle-glücklich" Lösung zu bezeichnen, weil diese Anordnung erfordert schon auch einen versierten Nutzer wie Dich.

Regards
fnu

Zitat von fnu

man müßte da aber bei "softhddevice" VA-API abklemmen.

musste ich bei natty natürlich auch machen, hatte ich vergessen zu erwähnen

Christian

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

cat /usr/share/vdr/menuorg-appswitcher

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

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

Getestet mit natty und oneiric

Christian

Zitat von CKone

fein, das gefällt mir immer besser!

Das remux dpatch welches ich weiter vorn für oneiric hochgeladen hab läuft auch auf 1.7.21 natty sauber durch.

Christian

Kannst Du mal so freundlich sein und mal genau beschreiben wie man den remux patch richtig einspielt? Für jemanden der noch nie seinen VDR gepatcht hat sondern immer nur fertige VDR aus PPAś installiert.

also der Patch tut echt nicht weh und stört auch sonst nicht, da er die API nicht verändert.

wenn ihr mal alle Hoplo oder fnu ruft ist es bestimmt für alle komfortabler wenn der 1.7.21 kurz im Repo gepatcht wird. - Das selbe gilt im übrigen auch für oneiric und lucid, da müssen ja jetzt nicht alle losrennen und vdrs patchen...

Gruß Christian

CKone

Hatte ich nicht irgendwo gelesen, das Patchen nicht nötig wäre, wenn nur der ffmpeg Stand neu genug ist? Oder erinnere ich mich da falsch?

[Edit] wie war das hier gemeint? [/Edit]

Regards
fnu

also ohne Patch stürzt der hier dauernd mit vdr < 1.7.23 beim Umschalten ab softhddevice und yavdr 0.4 - hat das jemand am laufen?

Bei Hoplo und mir stürzt er mit oneiric (natty geht ja nicht mal druch den compiler) mit der 7.3 er lib trotzdem beim Umschalten auf nen AC3 Kanal ab wenn NICHT passthrough eingestellt ist. In Beitrag 66 hatte ich das noch mal im Kontext erwähnt

Zitat

Das remux dpatch welches ich weiter vorn für oneiric hochgeladen hab läuft auch auf 1.7.21 natty sauber durch.

Also du brauchst schon beides damit das vernünftig fliegt, den Patch und die 9.1er lib, wobei du dir aufgrund des Designs in Natty dsa mit der OLDAPI sparen kannst, es reicht die 9.1er mit den dev Paketen zusätzlich zu installieren

Gruß Christian

CKone

Ok, danke für die Info.

Regards
fnu

Zitat von CKone

wenn ihr mal alle Hoplo oder fnu ruft ist es bestimmt für alle komfortabler wenn der 1.7.21 kurz im Repo gepatcht wird.

Wir werden den VDR im Repo nicht patchen, das zieht unüberschaubare Aufwände nach sich, deren Zeitbedarf man besser in eine neue yaVDR Version (mit softhddevice) steckt.

Es weiß auch keiner wie sich der Patch global auf 0.4 auswirkt, soll ja alles getestet sein, weil 0.4 als stable gilt und es bleiben soll.

Wer also 0.4 mit softhddevice testen möchte, übernimmt zum einen die Verantwortung komplett für seine Installation/Bastelei und sollte sich deshalb auch die nötigen Kenntnisse aneignen.

Regards
fnu

Soll oder soll ich nicht. Ach was solls.

Der Patch ist ein vier Zeiler, der einen eindeutigen bösen Bug fixt, darüber sollte man nicht diskutieren müssen ob man den einbaut.
Entweder Patchen oder die Version entfernen.

Johns

Zitat von johns

Der Patch ist ein vier Zeiler, der einen eindeutigen bösen Bug fixt, darüber sollte man nicht diskutieren müssen ob man den einbaut.
Entweder Patchen oder die Version entfernen.

Klar sollst Du nicht mit der Meinung hinterm Berg halten. Aber, ja, Bugs sollten gefixt werden, nein, weil wir hier nicht über eine einzelne eigen-kompilierte Installation reden.

Egal was wir im Repo machen, wir müssen immer das Gesamtbild von, die Auswirkungen auf vmtl. von hunderten Installationen sehen, den Download zahlen nach sogar 4-stellig. Aktuell stört der Fehler mit xinelib nicht, die Nutzer können sich wie gestaltet auf 0.4 verlassen. Es ist leider nicht damit getan nur VDR neu zu bauen ...

"softhddevice" ist nicht Teil von 0.4 und wird es nie werden, aber wir arbeiten dran eine Version mit "softhddevice" zu bringen, mit fehlerbefreiten 1.7.24 oder eben neuer. Ich selbst setzte gerade eine VDR mit softhddevice (@VDPAU) auf um praktische Erfahrung im reellen VDR Betrieb zu sammeln.

Regards
fnu

Zitat von fnu

Klar sollst Du nicht mit der Meinung hinterm Berg halten. Aber, ja, Bugs sollten gefixt werden, nein, weil wir hier nicht über eine einzelne eigen-kompilierte Installation reden.

Egal was wir im Repo machen, wir müssen immer das Gesamtbild von, die Auswirkungen auf vmtl. von hunderten Installationen sehen, den Download zahlen nach sogar 4-stellig. Aktuell stört der Fehler mit xinelib nicht, die Nutzer können sich wie gestaltet auf 0.4 verlassen. Es ist leider nicht damit getan nur VDR neu zu bauen ...

"softhddevice" ist nicht Teil von 0.4 und wird es nie werden, aber wir arbeiten dran eine Version mit "softhddevice" zu bringen, mit fehlerbefreiten 1.7.24 oder eben neuer. Ich selbst setzte gerade eine VDR mit softhddevice (@VDPAU) auf um praktische Erfahrung im reellen VDR Betrieb zu sammeln.

Regards
fnu

Alles anzeigen

fnu
fullACK

nun wir hatten letztens mal ne unschöne Unterhaltung, aber ich muss mal sagen das du hier recht hast - es wär natürlich einfacher aber auf der anderen Seite fehlt ja die komplette Einbindung.

Und wer libs installieren und gar tauschen, Plugins bauen, Scripte anpassen etc.pp. kann, nun der wird auch ein schlüsselfertig geliefertes Patch nach einer Anleitung die mehrfach im Forum gepostet wurde in den vdr spielen können.

Auch wenn das wirklich super Funktioniert mit dem softhddevice: das ist natürlich derzeit Extrembasteln, besonders das drumherum!

Gruß Christian

Zitat von fnu

Klar sollst Du nicht mit der Meinung hinterm Berg halten. Aber, ja, Bugs sollten gefixt werden, nein, weil wir hier nicht über eine einzelne eigen-kompilierte Installation reden.

Egal was wir im Repo machen, wir müssen immer das Gesamtbild von, die Auswirkungen auf vmtl. von hunderten Installationen sehen, den Download zahlen nach sogar 4-stellig. Aktuell stört der Fehler mit xinelib nicht, die Nutzer können sich wie gestaltet auf 0.4 verlassen. Es ist leider nicht damit getan nur VDR neu zu bauen ...

"softhddevice" ist nicht Teil von 0.4 und wird es nie werden, aber wir arbeiten dran eine Version mit "softhddevice" zu bringen, mit fehlerbefreiten 1.7.24 oder eben neuer. Ich selbst setzte gerade eine VDR mit softhddevice (@VDPAU) auf um praktische Erfahrung im reellen VDR Betrieb zu sammeln.

Der Bug betrifft nicht nur mich. Jedes Plugin was cDevice::PlayVideo bzw. cDevice::PlayAudio benutzt bzw. implementiert, kann Abstürzen.
z.b. auch streamdev.

Und wiederspricht dich hier selbst, wenn der Bug niemanden betrifft, dann betrifft der Bugfix auch niemanden.

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

Johns