[HOWTO] Installation VDR-Client auf ARM Boards mit Allwinner Chip z.B. Cubieboard2, Cubietruck, BananaPI

Das Image fürn Banana ging vorhin auch übers Deutsche Forschungs Netz nicht laden
Jetzt gehts wieder
evtl. war es nur kurzzeitig down

SO habe mir das gerade noch mal angesehen.
Der Link funktioniert in der Tat wieder.
Aber die 105 Images von Debian-2.0 haben kein cedar_dev das trusty schon.

Werde mir das jetzt mal ansehen

Danke

Also für mich ist das jetzt so, egal welches der drei Images von Igor seiner Seite ich nehme. Das Resultat ist immer das ich kein cedar_dev habe.
Versuche jetzt das ganz nochmal mit dem hier verlinkten Image.

hmm

Hab jetzt erst gelesen über die IR Probleme. Bei mir hat weder sunxi-ir noch sunxi-lirc gut funktioniert. Da habe ich sunxi-cir gefunden. Der wurde wohl als Ersatz für sunxi-ir geschrieben aber leider nicht in den 3.4 integriert. Bei mir tut er mit einer RC6 Fernbedienung guten Dienst. Er sollte mit jeder Fernbedienung funktionieren. Das ist ein rc-core Treiber. Es sollte Erfahrung im patchen und Kernel kompilieren vorhanden sein.

Gruss zille

So ich noch mal.
Ich muss meine Aussagen bezüglich der neueren Versionen von Igor rewidieren.
Cedar_dev ist sehr wohl enthalten.
Mein Fehler war, das im neuen Image keine uEnv.txt sondern eine boot.cmd enthalten ist welche nach dem Editiren noch per
mkimage -C none -A arm -T script -d /mnt/boot.cmd /mnt/boot.scr in eine scr gewandelt werden muss.

Sorry für die Falschaussage.

Spacy

Hallo,

läuft, allerdings gibt es auf dem Banana PI kein /dev/cedar.

Die Lösung liegt in der Kernel cmdline in der uEnv.txt

sunxi_ve_mem_reserve=0


This eliminates the reserved memory for the video acceleration 
engine, saving 80MB. You can use this if you don't run accelerated video
 with programs such as VLC or XBMC or libvdpau-sunxi.
 (This kernel parameter is ignored in recent 3.4 kernels, if CMA is 
enabled in kernel configuration. If CONFIG_CMA=y, ve_size is hardcoded 
to 80MB in sunxi_cedar kernel module.)

Wenn es wie oben drinnen steht wird /dev/cedar nicht angelegt!

Deswegen steht im howto ja auch

extraargs=rootfstype=ext4 sunxi_ve_mem_reserve=190 sunxi_g2d_mem_reserve=16 sunxi_fb_mem_reserve=32 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p50 panic=10 consoleblank=0

Danke für das super Howto, hat auch mit VDR 2.2.0 einwandfrei funktioniert!

Habe mir noch das satip Plugin installiert, hier eine Anleitung wie ich vorgegangen bin, vielleicht hilfts dem Ein oder Andren:

# Install libcurl

cd /usr/local/src/
wget http://curl.haxx.se/download/curl-7.40.0.tar.gz
tar xfvz curl-7.40.0.tar.gz
cd curl-7.40.0/
./configure
make -j3
make install

# Install TinyXML

apt-get install libtinyxml2.6.2 libtinyxml-dev

# Install vdr-plugin-satip

git clone https://github.com/rofafor/vdr-plugin-satip.git
cd VDR/PLUGINS/src/
ln -s ../../../vdr-plugin-satip/ satip
cd ../..

nano PLUGINS/src/satip/Makefile

remove the # sharp from this line:
#SATIP_USE_TINYXML = 1

make -j3
make install

# Optional: adapt sources.conf

nano /var/lib/vdr/sources.conf

SAT>IP satellite positions (aka. signal sources) shall be defined via
sources.conf. If the source description begins with a number, it's used
as SAT>IP signal source selection parameter. A special number zero can
be used to disable the source. Otherwise, the default parameter is one:

S19.2E Astra 1KR/1L/1M/2C
=> Signal source = 1

S19.2E 2
=> Signal source = 2

S19.2E 3 Astra 1KR/1L/1M/2C
=> Signal source = 3

S19.2E 0 Astra 1KR/1L/1M/2C
=> Source is disabled

# Add satip to runvdr

nano /usr/local/bin/runvdr

i.e.:
/usr/local/bin/vdr -d -l 2 -P satip -P"softhddevice -x -a sunxihdmi" -P femon

Danke für das tolle Howto, konnte damit auf dem Banana Pro zügig den VDR aufsetzen.

Zur Vollständigkeit sollte noch erwähnt werden, dass man zum Keys anlernen nur das OSD sieht, wenn man X selber vor dem VDR startet und nicht durch softhddevice.

Allerdings, und ich frage mich ob ich der einzige bin, bekomme ich lauter frame drops (speedup video) sobald das OSD geöffnet wird.
Zu beobachten ist dann, dass das Fernsehbild unter dem OSD langsamer wird und der Audio-Video-Abstand immer größer wird. Der Ton hat dabei immer noch die richtige Geschwindigkeit.
Sobald das OSD geschlossen wird fängt das Fernsehbild an stark zu wackeln (wird wohl beschleunigt) bis Audio und Video wieder synchron sind.

Habe das Verhalten mit dem Kernel 3.4.106 und 107 und VDR 2.2. Rest ist aktueller git Stand. Softhddevice habe ich auch mit dem Stand vom 16.12.2014 (Zeitpunkt des Howtos) getestet, machte aber keinen Unterschied.

Wo könnte das Problem liegen, wer hat eine Idee ?

Danke schon mal !

ist bei mir nur bei einem fetten skin so
nutze selber nur den alten "Startrek" skin da geht's

Hm, hab grad alle Skins durchprobiert: überall das gleiche Verhalten.

Hallo,
das liegt an libvdpau-sunxi. Welche Version benutzt ihr?
Ich würde euch empfehlen, mindestens den hier zu nutzen, da ich hier mit Hilfe von johns einige Sachen eingebaut bzw. verändert habe.
Wagemutige können sich auch an https://github.com/rellla/libvdpau-sunxi/tree/dev_fix1 wagen, der funktioniert zumindest bis zu diesem Commit. Die letzten beiden Commits konnte ich noch nicht testen.
Die Commit History sollte einigermaßen aufschlußreich sein, was alles geändert wurde.
Viel Spaß und Probleme bitte melden! <- EDIT: Ein paar sind bekannt

Gruß Andreas

Hallo Andreas,

der letzte Commit aus dem Branch dev_fix1 funktioniert nicht (schwarzes Bild).
Ich habe dies auf einer Mele M5 getestet


Gruß, Paul

Ok, danke. Schau ich mir an. Das heißt im Umkehrschluß, der vorletzte geht noch ?
Gruß Andreas

Den habe ich nicht getestet. Aber mit Commit 12bc0e4 geht es wieder.

Super! Mit beiden branches klappt das !
rell Danke für den Hinweis und den schnellen fix von dev_fix1 !

Jetzt gibt's nur noch einzelne frame drops wenn sich das OSD ändert, aber das ist vernachlässigbar.
Neu ist im Log beim Umschalten:

codec/video: ffmpeg/libav buggy: width or height zero
video/vdpau: can't set mixer attribute values: An invalid/unsupported VdpVideoMixerAttribute value was supplied.

Das hängt aber wohl mit den Änderungen für den Windowmanager zusammen? Ich bemerke hier jedenfalls keine negativen Auswirkungen.

Und noch ein dickes Lob und Dankeschön an alle Entwickler und Beteiligten, VDR auf dem A20 läuft echt super !

Habe (hoffentlich) noch einen bug gefixt.
Die frame drops muss man wohl derzeit akzeptieren. Mal sehen, ob es noch irgendwo Verbesserungsmöglichkeiten gibt, aber ich denke, wir sind hardwaretechnisch ziemlich am Limit.
Zur ffmpeg/libav info kann möglicherweise johns was sagen.
Die fehlenden Funktionen schaue ich mir mal an. Es würde mich interessieren, welche anderen Skins denn zufriedenstellend bzw. überhaupt laufen (skindesigner?)...
Ansonsten läufts wirklich gut soweit

Gruß Andreas

Der neue Stand mit den Ergebnissen von gestern ist online. Bei mir hier läufts gut.
https://github.com/rellla/libvdpau-sunxi/tree/dev
Viel Spaß! Bin für weitere Wünsche offen
Gruß Andreas

Hallo Andreas,

das klappt schon wirklich sehr gut! Wie könnte man nun das "Rauschen" wegbekommen, das man oft beim Umschalten sieht?

Gruß, Paul

Wohl mit dem Einbau einer "Schwarzschaltung" in libvdpau-sunxi, die einspringt, solange der Videodekoder "unvollständige" Frames liefert. D.h. der Video Layer müsste schwarz bleiben, bis das erste I-Frame kommt.
Das Problem bei libvdpau-sunxi ist, dass softhddevice dieses Problem mit einer schwarzen Fläche löst, die aber in unserem Fall auf dem OSD Layer landet und nicht das Video wegschaltet - wir haben OSD und Video auf getrennten Layern, die immer (zumindest beim Video) nacheinander bei jedem Frame angezeigt werden.

Falls man das Problem im Treiber lösen will, müsste man den Dekoder so verändern, dass bei einem Streamstart erst Frames ab dem ersten I-Frame ausgeliefert werden. Oder man lässt die Darstellung solange ins Leere laufen, bzw. schaltet den Layer unsichtbar, bis der Dekoder soweit ist - wenn ich das richtig verstanden habe.
Ob das der richtige Weg ist, weiß ich nicht. Falls die Experten hier zustimmen, dass das die richtige Vorgehensweise ist und ich keinen Mist erzähle kann ich mir da ja mal was überlegen.

Gruß Andreas