Henning: ich würde das /vtx Verzeichnis noch ein bsichen grösser machen. Bei mir schluckt das nach 2 Sendern schon fast 50% der Platte..
tmpfs 16384 7444 8940 46% /vtx
Da das tmpfs dynamisch ist und auch Swap Space
benutzt kann man das ruhig hochsetzen.
Kewl das das im Betrieb geht 
mount -o remount,size=64M /vtx/
gruss mad
da wirste um ein bsichen handarbeit nicht herumkommen.
die Sourcen liegen jetzt unter
./drivers/media/dvb/dvb-core und das müsste zumindest in das Configure Script eingebaut werden und ich glaube 2 .c Files müssten auch gepatcht werden. Ist aber nicht so wild. 
vi +2796 configure
vi +55 ./libvo/vo_mpegpes.c
vi +26 ./libao2/ao_mpegpes.c
viel spass ...
gruss Mad
Henning: yo, nicht schlecht. hab gesehen das es mehrere Plugins gibt die leider immer noch die vdr sourcen patchen. die könnte man damit erschlagen.
Martini: ich probier den mal aus. ich hatte den schonmal drin und da ist mir der vdr ständig abgeschmiert, lag aber dann nicht an elchi sondern an einem plugin.
@all: habt Ihr nach dem update auf 1.1.25-r2 auch probleme bei der widergabe von aufnahmen?? Bei mir hängt die Fernbedienung, und nach 5-10sec werden dann alle gedrückten tasten abgespult. Wie so ein Buffer. Wenn ich dann die Plugins rausnehme gehts...
Versteh ich allerdings nicht... ich werd mal die Plugins neu emergen.
gruss Mad
schon klar, ich denke er meinte .deb files, aber auch die dürften nicht so schwer zu erstellen sein. es müssten sich nur ein paar vdrdebianer finden die das gerade zusammenschustern.... und pflegen. Aber wenn die Paktete für das eigene System entwickelt werden, dann pflegt man das auch ordendlich.
M.
Naja, für Gentoo gibts so langsamm ein paar pakete (nein das isst noch kein Distrikrieg) und das funzt bis jetzt ganz gut ... siehe gentoo forum...
und ich denke die bleiben auch aktuell.
mad
hi,
da Elchi die vdrsourcen patched geht das nur über USE Variable, allerdings würd ich gerne auf ein Elchi-1.1.25 oder so warten. Oder läuft der 1.1.20Elchi wirklich ohne Probleme und superstabil? Warum gibts da eingendlich keine neuere Version? Der 1.1.20 ist ja schon 4 Monate alt ...
gruss mad
Kurze Howto wie ich ebuilds teste:
naja, erstmal eins haben:
dann ins ebuild Verzeichnis wechseln
Beim ersten Test wird ein Digest (MD5, Size ect) der Sourcen erstellt, also
"ebuild vdr-xx.ebuild digest"
aufrufen. Danach
"ebuild vdr-xx.ebuild compile"
läd die sourcen und compiliert das programm. Ruft also die Funktionen src_unpack() und src_compile() aus dem Ebuild auf.
---
wenn das glatt geht folgt ein:
"ebuild vdr-xx.ebuild install"
Dies installiert noch NIX im System, sondern nur ein Image in der Sandbox.
Also z.B. "ebuild epm-0.8.ebuild compile" ->
----
>>> md5 epm-0.8.tar.gz
>>> Checking epm-0.8.tar.gz's mtime...
>>> WORKDIR is up-to-date, keeping...
>>> It appears that epm is already compiled; skipping.
>>> (clean to force compilation)
>>> Install epm-0.8 into /var/tmp/portage/epm-0.8/image/ category sys-apps
man:
strip:
>>> Completed installing into /var/tmp/portage/epm-0.8/image/
----
danach kann man mit "find /var/tmp/portage/epm-0.8/image/" überprüfen was alles ordendlich installiert wird.
Falls das alles ok ist, kann man mit:
"ebuild epm-0.8.ebuild merge"
das Prog ins System installieren.
---
Vorsicht vor Makefiles die z.B. ein
"cp xybin /sbin" oder ein su -c "mv /usr/bin/tosvcd /usr/bin/tosvcd.old"
enthalten, diese Files tauchen dann nicht in der PKG datenbank auf!!!! Und werden bei einem unmerge auch nicht entfernt! also dann lieber kein "make install" sondern die Ebuild-Funktionen "doins, doexe, dobin ect" benutzen! siehe http://www.gentoo.org/doc/en/gentoo-howto.xml#doc_chap4
Deswegen hab ich in allen vdr-plugin ebuilds ein:
sed -i "/cp.*LIBDIR/d" Makefile
damit der cp Befehl da raus kommt. Evt. sollte man mal allen Plugin Programmieren stecken das es den befehl install gibt und desweiteren in Makefiles Variablen wie DESTDIR und PREFIX sinnvoll sind.
gruss Mad
um im dem board mal ein bsichen traffic zu machen und um nicht von SuSE Forum überholt zu werden hier die Ankündigung das ein neues EBuild im gentoo.de CVS ist. Die einzige Erweiterung ist ein Watchdogdaemon (bash script) der vdr und dvb module neu startet falls vdr abschmiert oder neustart im Menu angewählt wird.
Start mit /etc/init.d/vdrwatchdog start und permanent mit rc-update add vdrwatchdog default
gruss mad
hi,
also wenn dmxdev als erstes eingebaut wird muss MODOPTS[2] auf MODOPTS[3] geändert werden.
desweitern hab ich dmxdev nicht als modul geladen?!? Keine Ahnung woher das kommt.
ebenso bekomme ich die Fehlermeldung nicht:
tricorder init.d # /etc/init.d/dvb start
[ ok ]ng DVB Modules...
tricorder init.d #
hmmm, eigendlich war das nur bei den alten Treibern, die neuen sollten alle eine license haben:
"modinfo dvb-core"
description: "DVB Core Driver"
author: "Marcus Metzler, Ralph Metzler, Holger Waechtler"
license: "GPL"
falls das nicht so ist habt Ihr noch alte treiber an board! mal nen "find /lib -name dvb-core.o" starten und schauen wieviel dvb mods Ihr habt.
gruss mad
ich würde auf falsche cflags tippen:
make[3]: *** [my_ir_stuff] Ungültiger Maschinenbefehl (Speicherauszug erstellt)
ich würde es mal mit was ganz hamlosen versuchen.
Auf http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html gibts ein paar Flags, evt. sogar mal i386 versuchen. Ich habs bei mir auf einem Athlon 1700+ mit den fiesen (unsafe) Options ohne probleme kompiliert.
mad
naja, die sourcen in /usr/local/src/VDR/PLUGINS/src entpachen dann im /usr/local/src/VDR ein "make plugins" und fettich?!!
gruss Mad
also auch zuhause sollte man sich protokolle angewöhnen die "state of the art" sind also ssh.
2tens kommt zlib oder libz oder -lz (alles das gleiche) nicht von irgendeinem XYZ packet sondern von http://www.gzip.org/zlib/ und sollte bei jeder guten distrie zur Grundausrüstung gehören!
gruss Mad
jo,
hab das vdr.osdteletext so geändert das -r defaultmässig drin ist. /vtx und fstab funzte bei mir.
Und das Teletext Plugin ist echt kewl. Ich finds besser als das andere teletext, nur das Farbmapping ist bescheiden. Kann man da nicht ein bsichen mit Farbabstufungen arbeiten? Werde mal nachfragen...
Mad
hmmm, ob das konsistent durchzuhalten ist....
also, ich hab die datei deupped und das neue RC script.
Jetzt gibts die Möglichkeit über "_EXTRAOPTS" jedem Plugin Optionen zu übergeben die nicht nach der konvention "--name=value" (z.b. --epgfile=FILE ) funktionieren wie dies beim osdteletext der fall ist (--recieve oder -r) .
mad
habs gemacht, allerdings etwas geändert da ich die OPTION="-r" Geschichte nicht verstehe!?
Siehe Thread osd ebuild online.
mad
Bahnhof, wenn ich da
OPTION="-r"
einbaue gibts ne commandline für vdr die ungefähr so aussieht:
--plugin 'osdteletext --option=-r'
das kann ja nicht richtig sein, oder??
Zumindest mit dem initscript aus dem ebuild.
M.
HI,
die vdr.osdteletext brauchste doch nur ins files verzeichnis packen... und mit cvs add datei einbauen? Oder verstehe ich dich da jetzt falsch?
Das mit dem Startscript biege ich hin, dann gibts halt ein Feld _EXTRAOPTS="blah" welches einfach hinten angehängt wird
M.
naja, vielleicht sollte ich erstmal alles ausprobieren und dann schreiben.
Auf jedenfall funzt es jetzt, man muss dem Plugin "-r" mitgeben was aber leider mit meinem INIT Script nich ging..... mal fixen ...
gruss Mad
ok, das cvs prob hat sich erledigt (rtfm), ein typo in der downloadlocation war da noch und
doins ${FILESDIR}/vdr.osdteletext
schlägt fehl weil die datei nicht im files ordner ist.
Henning: bitte uppen
Da die Config nicht da ist gehts bei mir warscheinlich nicht?? Auf jedenfall findet er keine Seiten... Ist da noch was zu beachten?
mad
kewl, wollte das gerade mal testen, scheidere aber an meinen cvs kentnissen 
ein "cvs update" läd mir nicht die neuen Verzeichnisse runter ... ? Irgend ein Tip?
mad
