Reel eHD Gentoo Anleitung

Hab die 12384 ebuilds mal installiert, lassen sich problemlos emergen.

ABER: Leider klappt die VDR Bildausgabe nicht mehr, vdr startet laut Logfile ganz normal hoch (und das OSD lässt sich per Remote & GLCD auch noch bedienen), aber auf dem HDMI Ausgang ist nur das "Avantgarde" Standbild zu sehen, aber kein Live-TV Bild wie mit den vorherigen Ständen.

Hat schon jemand anders auch mal die 12348 Version installiert und kann seine Erfahrungen damit berichten? Hat sich was geändert und man muss jetzt noch an irgend wat anderem fummeln oder konfigurieren um ein TV-Bild zu bekommen?

Zitat

Original von Quacks

Ich habe im Verdacht, das es diese Änderung im SVN der reel war (unbewiesen):

Code

------------------------------------------------------------------------ 
r12354 | balaji | 2009-06-03 16:36:45 +0200 (Wed, 03 Jun 2009) | 5 lines  
vdr/reelbox-plugin During Initialize() shutdown hdplayer and video output.
Service ToggleVideoOutput enables/disables both hdplayer and video output

Hi,

guter Tipp das mit der Änderung in der Initialize() funktion. Ich habe mal die Änderung (also die drei Zeilen die sich zum vorherigen SW-Stand geändert haben) in der reelbox.c rückgängig gemacht und jetzt habe ich auch wieder ein TV-Bild!

Moin Gemeinde,

Die vor kurzem eingebrachten Pakete

vdr-osdpip
vdr-filebrowser

im testing overlay

sind wegen Konflikten mit gleichlautenden Paketen im Main portage

zu -->
media-plugins/vdr-reelosdpip
media-plugins/vdr-reelfilebrowser
verschoben worden.

Alte Pakete wurden maskiert bis zum entfernen in ca. 2 - 3 Wochen.

Sorry für die Unanehmlichkeiten....

Hallo Quacks,
die 12384 ehd tools lassen sich auch nicht unter amd64 kompilieren.
Das ebuild sieht jetzt überhaupt nicht mehr amd64 tauglich aus.

src_unpack() {
    unpack ${A}
    cd "${S}"


    sed -i Makefile \
        -e "s:gcc-3.3:gcc:g" \
        -e "s:g++-3.3:g++:g" \
        -e "s:x86/driver::"


    if [ ! -z "$EHD_FRAMEBUFFER" ]
    then
        einfo "Changing framebuffer device to $EHD_FRAMEBUFFER"
        find . -type f -exec sed -i "s:/dev/fb0:${EHD_FRAMEBUFFER}:g" {} \;
    fi


}


src_compile() {


    emake clean || die "emake clean failed"
    emake x86 || die "emake x86 failed"
    cd x86/hdtsplay
    emake || die "emake hdtsplay failed"
}

Hast du hier auch eine schnelle Lösung parat?

Mich wundert, dass nicht noch mehr Leute gentoo-64 einsetzen. Ich habe sonst in keinster Weise Problem damit.

Gruß
Oghi

@ oghi

Ich habs gefixt und die amd64 keyword's nachgetragen.

Kleines Update, bugfix

media-video/reelbox-ehd-driver-12384-r1
media-video/reelbox-ehd-xine-12384-r1

// Edit

media-plugins/vdr-reelbox-3.12384-r1 nachgeschoben

Da sich der Treiber hdshm ziemlich unbeeindruckt von den per
EHD_FRAMEBUFFER übergebenen Parametern zeigt,
hab ich das mal in etwas andere Form gebracht.
Der Treiber an sich legt immer das nächste freie zur Verfügung stehende /dev/fb Device an.

In meinem Fall ist /dev/fb0 durch den Vesa Treiber für graphtft belegt.
Nächstes freies device ist /dev/fb1, welches auch beim laden angelegt wird, egal was ich vorher beim compilieren per EHD_FRAMEBUFFER übergeben habe.

Eine kleine udev.rules legt jetzt beim erstellen des devices nen link

/dev/fb_reel an.

Das reelbox-edh-xine verwendet dann genau dieses device.

Bitte eure Scripte, oder wofür ihr das framebuffer device auch verwendet, dementsprechend anpassen.

Falls noch ein anderes ebuild den ehd framebuffer benutzt, melden, ich passe das kurzfristig an.

Weiterhin erstellt das ehd-xine ebuild jetzt den
/usr/bin/xplayer

Danke an CR7, der mir das per mail vor einiger Zeit zukommen lies.

Zitat

Im letzten ehd-xine-ebuild habe ich den xplayer mit gebaut - damit
kann man ohne VDR direkt über Konsole Videos + Audio über die ehd-
Ausgeben.
VDR vorher stoppen. Sehr gut zum testen ...

Quacks

Zitat

damit zieh ich mich aus der Ebuild Bastelei zurück

ABGELEHNT!!!
Hab dich nicht so mimosenhaft,
bisschen Kritik kann nur in besserer QA resultieren.

Feierabend fuer ältere VDR versionen.

>> Hier gehts weiter <<