Posts by schubsi

Ich musste wohl erst noch lernen, dass es klüger ist, den Firefox (hatte iwo noch nen alten) zu nutzen, wenn man das WFE aufruft

Ne recht aktuelle channels.conf hatte ich dann doch noch zu liegen von der letzten KD Umstellung und es ward Licht!

Nach einigem Suchen hatte ich auch was vom besten Freund in der Trefferliste und nach einigem "Basteln" (Einrichten) bin ich glücklicher yaVDR Betreiber.
Hätte nicht gedacht, dass es doch so cremig über die Bühne geht, ubuntu ist halt doch etwas mehr debian als ich vermutete insofern habe ich mich recht schnell zurechtgefunden...

Vielen Dank an die yaVDR-Macher für die gelungene Komposition und an die Schreiber für die mutmachenden Beiträge!

Ab heute abend ist der WAF wieder ganz doll weit oben

-==[Schubsi]==-
(der seinen Footer dann noch aktualisieren muss)

Habs geahnt ...

Unverändert: VDR läuft, ich seh aber nur nen Mauszeiger auf dunklem Hintergrund.
Das Web-Interface finde ich neckisch, nützt aber alles nichts...
Nervig: Darf per ssh das syslog nicht ansehen - ah ne, sudo vergessen, mc geholt, der unterstützt aber die lynx-artigen Bewegungen nicht ?
Wieso eigentlich...

Naja, beim ersten Versuch wars wie gesagt die 0.5.0beta64 und diesmal die 0.4.0-64

Vorschläge? Soll ich noch eine Stufe zurück?

Ich acker mal das syslog durch...

-==[Schubsi]==-

Quote

Niemand zwingt dich, ein Update zu machen.

Das ist schon mal vielversprechend...

Quote

Ansonsten kann man die vdr-Pakete auch pinnen und somit aus dem Update raushalten.

DAS kann debian auch, nützt aber nix, wenn andere Komponenten geändert wurden, die in Abhängigkeit stehen...

Quote

hab ich irgendwas verpasst? Gibt es jetzt schon ein 0.6 iso von yavdr?

Ja, sorry, war ein freud'scher Vertipper...

DL der 64er 0.4.0 ist inzwischen auf Scheibe gebannt und entlockt meinem alten DVD-Laufwerk rumpelnde Geräusche...

Bin gespannt!

-==[Schubsi]==-

Quote

hast sowas ähnliches wie Debian + e-Tobi

.

I will give it a 2nd try! (beim ersten Mal gabs kein Bild...)

Was mir wichtig wäre: Bei e-tobi gabs das Problem, dass sich der VDR ständig weiter entwickelte, man also alle Nase lang irgendwas updaten musste.

Wenn ich mich jetzt von meiner geliebten debian-Umgebung verabschiede (soooo schlimm ist es nun auch wieder nicht :)), hätte ich aber bitte die Erwartungshaltung, dass wenn eine neue Variante des yaVDR gestrickt wird, dafür auch ein neues Release genommen wird (ein yaVDR 0.6 bleibt ein yaVDR 0.6). Ich meine: "Never touch a running system!"... wenns grad so gut funktioniert (und es keinen Grund für ein Update gibt), warum dann immer der neuesten VDR-Entwicklung hinterher hecheln?!?!
e-tobi*s Drang nach "Fortkommen" in allen Ehren, aber es hat nun dazu geführt, dass ich mich vor einem Scherbenhaufen wieder finde. Nochmal möchte ich das nicht...

Hoffe das ist verständlich rüber gekommen (kein böser Unterton oder so!).

Kann ich mich drauf verlassen, dass wenn mein yaVDR "spielt", dass er das bis in alle Ewigkeit machen wird? Falls nicht, dann muss ich mich nämlich durchringen, bei debian zu bleiben und mich mit dem Kompilieren, Debianisieren und Patchen und "was weiß ich noch" vertraut machen, hab zwar nen gewissen Horror davor (Ich hab doch immer keine Zeit!)...

LG

-==[Schubsi]==-

Erstmal Danke fürs antworten, es tut gut, nicht allein zu sein...

Quote

...ich glaube das was du suchst heißt yavdr...

Das war mein allererster Gedanke, hab die 0.6 runter geladen und bin beim Blick hinter die Kulissen ins Grübeln gekommen. Ist eben doch was anderes als das, was ich so gewohnt bin. Ich vermutete eine zu lange Einarbeitungszeit und entschied mich dann zu einem neuen Versuch in der mir bekannten Umgebung (debian), ging ja früher auch - irgendwie...

Quote

Die Frage ist, ob YaVDR seine Anforderungen erfüllen wird

Große Ansprüch habe ich gar nicht: LIRC mit selbstgelötetem Empfänger, EPG-Search, Mplayer (für AVI, MPEG, DVD-ISO), früher hatte ich VDRadmin-AM, könnte aber auch mit Live-Plugin gut leben, das wars fast schon. Die KNC-Clone-DVB-C Karten wurden vom 2.6.30-bpo Kernel gut unterstützt, lediglich die drei Schnittstellen für die Hardware-CA musste ich regelmäßig löschen, hab da keine CIs dran (da muss ich also manuell eingreifen, weiß nicht, ob das bei yaVDR möglich ist, so tief habe ich nicht geschaut). HDMI zum 37er Panasonic-Plasma 1024x720 (inkl. Audio). Anspruch: Das Ding muss richtig ratzfatz durchstarten (war in der alten Konstellation rattenschnell dank SSD), man will sich ja nicht verschlechtern. EnigmaSkin ist mein Favorit. Mehr fällt mir spontan nicht ein...

Quote

Bitte das erste Posting nochmal editieren und Schriftgröße auf Standard.

Erledigt! So besser? Wow, was habt Ihr alle für Bildschirme, klebe schon mit der Nase an meinem 19er...

Quote

Wenn Du schon Debian nutzt, kannst Du den VDR auch noch selbst bauen.

debian != selber bauen
aber
debian = irre stabil

Das sind bestimmt andere Distris, bei denen "make" eine alltägliche Rolle spielt
Vielleicht hast Du das verwechselt, ich liebe dselect, welches mir seit Anbeginn meiner Linux-Experimente immer gute Dienste leistete. Solange die Pakete alle "sauber" sind und zueinander passen, ist 1fix3 ein stabiles System aufgesetzt...

Quote

Das sind keine Plugins, sondern Pakete, die man braucht, um Plugin-Pakete zu übersetzen.

Das ist eben der Weg, den ich mal - autodiaktisch - gelernt habe, irgendwie bekäme ich es vielleicht auch hin, manuell zu "maken", aber ich scheitere momentan daran, dass mein System jetzt durch den 3.2.0 Kernel und die deshalb erforderlichen (?) Backport-Pakete total verwurstelt ist.

Back2Topic

Außer dem Vorschlag, yaVDR zu nutzen, kam kein alternativer Vorschlag. Muss ich davon ausgehen, dass der e-tobi-vdr 1.7.16, so wie er bei mir lief, nun im Datennirwana verschwunden und nicht mehr verfügbar ist? Hab garnicht nachgesehen, welcher vdr nun eigentlich von squeeze mitgeliefert wird (war zu sehr auf e-tobi fixiert). Die Idee mit dem "Selbermachen" bring ich wohl nicht, dazu habe ich zu wenig linux-knowhow...

In der Hoffnung auf die rettende Lösung verharrend...

-==[Schubsi]==-

Hallo, meine lieben...

Nach langer, langer Zeit der Abstinenz hier im Forum bitte ich um Hilfe!

Was ist passiert?

Mein vor Jahren (?) aufgesetzter HD-fähiger WoZi-VDR lief bis letzten Montag zuverlässig, bis die SSD aus mir nicht erfindlichen Gründen den Geist aufgab, kein Zugriff mehr möglich, kein aktuelles Backup verfügbar

Und nun?

Neue SSD gekauft, neue HD für die Aufnahmen, machen wir ihn eben neu:

debian Squeeze
e-tobi Dingens mit VDPAU
Plugin fürs Abo -> fertig!

Fertig? Nix da!

Nach -3- Tagen Haare raufen muss ich aufgeben: Backport-Kernel 3.2.0 und die Vermischung von sid mit stable rauben mir den letzten Nerv. Dabei will ich doch gar nicht immer das allerneueste auf dem Markt haben, sondern eigentlich nur wieder meinen VDR, der so schön stabil lief, es war meine ich die Version 1.7.16 auf nem squeeze (upgrade von lenny), kanns aber nicht mehr genau sagen. Die Darstellung der freien HD-Sender sah gut aus, ansonsten habe ich sowieso keine HD-Pakete in meinem Abo (Sky und KDH), SD lief auch sehr flüssig und mit niedriger Systemlast - absolut für den täglichen Gebrauch tauglich. Wenn da nun beim 1.7.27 nicht die Probleme mit diesem doofen Plugin wären, welches ich ja unbedingt brauche. Bild und Ton habe ich in der momentan aufgesetzten Konfiguration schon hinbekommen, aber eben nur FTA. OpenSSL ist installiert, das Plugin meint beim Kompilieren - nach Durchführung der "tobi-Vorgehensweise" - , dass da irgendwas nicht geht, crypt.c? md5? keine Ahnung (ging früher, bin ich sicher)...

Was möchte ich nun eigentlich von Euch?

Nen Schubser in die richtige Richtung:

Ein blankes debian squeeze mit fluxbox und nodm kriege ich alleine hin, LIRC und ALSA habe ich auch im Griff. Der Kernel 2.6.32 kennt meine knc-clone-TV-Karten (DVB-C) und beherrscht mit dem mitgelieferten Nvidia-Kernel meines Wissens auch VDPAU. Aber wo bekomme ich nun einen VDR (1.7.16?) her, der nach e-tobi-Manier vorkompiliert in mein System reinpasst, inkl. der Möglichkeit, dieses ominöse Plugin erstellen zu können (vdr-dev, debianize-vdrplugin).

Gibts von e-tobi vielleicht ein "frozen archive" oder ähnlich?
Gibts ein ähnliches Repository für squeeze, auf welches ich zurückgreifen könnte?

Oder sehe ich gerade den Wald vor lauter Bäumen nicht?

Ich stecke gerade in einer Sackgasse und benötige Eure Unterstützung!

Vielen Dank fürs Lesen und evtl. Lösungsvorschläge...

-==[Schubsi]==-

Moins...

nach nem Zwangs-Upgrade von lenny auf squeeze schimpft epgdata2vdr mit mir:

/usr/bin/epgdata2vdr: error while loading shared libraries: libWand.so.10: cannot open shared object file: No such file or directory

Ebenso wurde libMagick.so.10 angemahnt...

Stell ich mich nur zu dusselich an?

Hab graphicsmagick-libmagick-dev-compat gefunden, das ist das einzige, was irgendiw nach libWand gerochen hat:
...
/usr/lib/libMagick.so
/usr/lib/libWand.so
...

Habe dann einfach mal passende Symlinks drauf gemacht, Fehlermeldungen kommen keine mehr, die Bilder interessieren mich nicht (mehr), insofern... ?

-==[Schubsi]==-

Tadaaaaah!

Hallo Wolfgang und alle anderen, die sich für die Problematik interessieren:

Ich habe mich mal an einer Anleitung von Martin orientiert: In der Tat ist es so, dass die Locales eine Rolle spielen.

Mein Lösungsweg:

dpkg-reconfigure locales
- folgende auswählen:
de_DE (iso88591)
de_DE.iso885915@euro
de_DE.utf8
en_US (iso88591)
en_US.iso885915
en_US.utf8

Default für das system locale auf en_US.UTF-8 einstellen

/etc/profile editieren und folgendes eintragen:
export LC_CTYPE=de_DE

Nach nem Reboot des VDR funktioniert die Einstellung des OSD (Größe und Position) einwandfrei...

-==[Schubsi]==-

Quote

Original von massi
fragt mich nicht warum, jetzt geht's auf einmal, irgendwie habe ich manchmal so das Gefühl neue Hard- und Software muß sich erstmal an einen gewöhnen...:D

Ich wärm das Thema mal auf, weil ich selbst (seit heute nacht) daran RUMknabber und nicht weiterkomme...

Liegts an den Locale - Einstellungen? (Punkt vs. Komma in der Dezimal-Punktierung?)

-==[Schubsi]==.

Naja, ich weiß ja nicht, war meine Frage zu dämlich oder gibts hier tatsächlich niemanden mehr, der nen anderen User mal auf die richtige Spur schickt?

Egal, ich gebe wenigstens noch meinen Lösungsweg zum Besten:

Dist-Upgrade auf squeeze...

Den Rest zusammenpfriemeln, die Tipss von Martin sind recht hilfreich, um sich daran entlang zu hangeln...

Ursache meines Disasters? Wahrscheinlich das Abschalten von http://e-tobi.net/vdpau-xine1.1 ...

-==[Schubsi]==-

Hülfe!

Asche auf mein Haupt, ich war lange nicht mehr hier, mein VDR lief jetzt seit einem Jahr prima...

Ich wollte ja bloß pureFTP installieren und habe dazu dselect benutzt, so wie ich das sonst bei meinem debian-server auch mache (klappte ja bisher gut).

Da wurde aber ziemlich viel auf den aktuellen Stand gebracht, und nun "regnets" segfaults, immer dann, wenn der Desktop auf Vollbild-VDR-Ausgabe umspringen soll

Die Config ist so gestaltet:
debian lenny
Linux bpo Kernel 2.6.30, weil damit meine 3 Mystique DVB-C Karten prima laufen
VDR 1.6 mit nem eigens eingebauten PUTE-Patch, für EPG-Import
Onboard NVIDIA GF 8300 mit HDMI an den Fernseher
NVIDIA Treiberpaket 190.53

dann erinnere ich mich noch an ein
libxineliboutput-sxfe.so.1.0.90-cvs und
libvdr-xineliboutput.so.1.6.0

Wie das damals zusammengestellt wurde, kriege ich nicht mehr zusammen, habe es schändlicherweise nicht dokumentiert und es ist zu lange her (Febr. 2010).

Nun steh ich da und mein geliebter VDR spielt nicht mehr mit mir.

Wer hat vielleicht nen Tipp für mich auf Lager, wo ich ansetzen könnte?

Ich habe auf dem Bildschirm im "Vorbeifliegen" gesehen, dass von e-Tobi eine Quelle wohl nicht mehr erreichbar sei, der passende Eintrag aus der Source.list:

deb http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch
deb-src http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch

deb http://e-tobi.net/vdpau-xine1.1 lenny base backports vdr-multipatch
deb-src http://e-tobi.net/vdpau-xine1.1 lenny base backports vdr-multipatch

Nochmal genauer:
Fehl http://e-tobi.net lenny/base Packages 404 Not Found
... etc
W: Konnte http://e-tobi.net/vdpau-xine1.1/…y-i386/Packages nicht holen 404 Not Found
... usw.

Das Log der Updates habe ich bei Pastebin hinterlegt, da steht drin, was alles aktualisiert wurde...

Inzwischen habe ich folgendes versucht:
1. Das Binary vdr (mit PUTE-Patch) wieder nach /usr/bin
2. NVIDIA Treiber, neuere Version "NVIDIA-Linux-x86-195.36.31-pkg1.run"

Beides ohne Erfolg!

Bin verzweifelt!

Vielleicht erinnert sich jemand von Euch an irgendeine große Umstell-Aktion, seit der irgendwas anders gemacht werden muss?

Bin für jedwede Hilfe dankbar!

-==[Schubsi]==-

Hallo VDPAU-Gemeinde...

Bevor ich mich wieder in die Nesseln setze, frag ich lieber vorher!

Mein WoZi-VDR (siehe Sig) läuft schon ganz prima:

- VDR 1.6.0-13ctvdr3 (?) aus Tobi's Repo (vdr-multipatch) mit zusätzlichem PUTE-Patch für den EPG-Import per epgdata2vdr (bin ganz schön stolz drauf, dass ich das mit Hilfe dieses Forums hinbekommen habe :-))
- Nvidia Closed-Source-Treiber 190.53
- Per HDMI wird auf einem Panasonic Plasma 37" (nativ 1024x720) ausgegeben

Plugins:
libvdr-xineliboutput
libxineliboutput-sxfe
epgsearch
wirbelscan
femon
libvdr-skinenigmang

außerdem:
acpi-wakeup
epgdata2vdr

Mit nodm startet der VDR flux bis zur Bildausgabe durch, bin begeistert!

Man hat mir geflüstert - und auch am Anfang dieses Thread wurde das berichtet - dass die Bildausgabe mittels VDPAU auch bei SD sehr schick ausschaut und auf einem großen Flachfernseher quasi Pflicht wäre.
Mit HD habe ich erstmal überhaupt gar nichts am Hut, mein Plasma ist eh nicht full-HD, mein Kabel-Abo gibt da nicht viel her, aber die Geschichte mit VDPAU reizt mich, weil ich eine max mögliche Darstellungsqualität anstrebe...

Da ich selbst begeistert von der Stabilität des 1.6er VDR bin, keinen zusätzlichen Schnickschnack benötige und meine Frau mit dem 1.6er inzwischen prima klarkommt, möchte ich den auf alle Fälle weiter betreiben!

Wenn ich das jetzt richtig hier gelesen habe, müsste es einen 1.6er VDR geben, der VDPAU unterstützt.
Ist der source.lst-Eintrag

deb http://e-tobi.net/vdpau-xine1.1 lenny base backports vdr-multipatch

für meine Bedürfnisse korrekt und ausreichend? Habe schon versucht mir anhand Tobi's Links in seiner Signatur einen Überblick zu verschaffen, habs aber nicht gerafft...

Bekomme ich Ärger, weil ich die Closed-Source-Treiber von der Nvidia-HP installiert habe? Wenn ja, wie biege ich das gerade, oder muss ich alles neu installieren?

Habe mir extra einen "develop" Rechner zusammengeschustert, mit dem ich vorher testen und üben kann, bevor ich den bereits im Produktivbetrieb befindlichen WoZi-VDR auf VDPAU umrüste.

Eure Meinung bezüglich Stabilität und Nutzbarkeit des VDPAU wäre mir noch wichtig: Ist meine Initiative richtig und gut oder sollte ich es lieber sein lassen?

Danke fürs Lesen!

-==[Schubsi]==-

Nachtrag:

/var/cache/vdr/epg.data gehört dem user vdr, das ist soweit ok...
Möglicherweise darf mein user vdr nicht downloaden?

Ich vermute, er darf das. Ein Userwechsel schein aber trotzdem angesagt zu sein...

Anachron hat mir ne Mail geschickt (mit den Logs des Datenimport):

Quote

...
Encoding detected: ANSI_X3.4-1968

Ich vermute mal, dass es unsinnig wäre, dem user "cron", der offensichtlich das script (mit root-rechten) auszuführen scheint, ein UTF-8 auf die Nase zu drücken...

Mmmmh, also gut, dann werde ich jetzt das Script mit 755 für den User vdr ausführbar machen und den Userwechsel wieder aktivieren.

Der nächste automatische Lauf ist nächste Nacht um 03:15, ich werde berichten.

-==[Schubsi]==-

Edit: Ich habe den Befehl /etc/cron.daily/epgdata2vdr-update spasshalber mal an der Konsole eingegeben, da passiert nix. Nehme ich das su ... vdr weg, funktionierts. (am-Kopf-kratz - versteh ich nicht)

Edit 15.02.2010:

Habe nun in der /etc/vdr/epgdata2vdr.conf folgendes hinzugefügt

export LANG=de_DE.UTF-8
export LC_ALL=de_DE.UTF-8

Mit dem Userwechsel funktionierts leider immer noch nicht, aber dafür nach wie vor ohne su...vdr, mit den exports wird aber nun die Codierung richtig als UTF-8 erkannt.

Rechte und Besitzverhältnisse scheinen beim VDR eh nicht ganz sauber zu sein: Bei meinen Experimenten musste ich feststellen, dass ein
chown -R vdr:vdr /usr/lib/vdr
chmod -R 777 /usr/lib/vdr
gar keine gute Idee waren, weil der VDR dann keine Chance mehr hat, ordnungsgemäß herunter zu fahren :-/ Da wurde wohl etwas herum getrixt, damit der VDR den Wakup-Alarm schreiben darf (darf sonst nur root) sowie den Shutdown-Befehl ausführen darf. Habe lange gesucht, um meinen Fauxpas wieder gerade zu biegen (Stichwiort: Set UID/GID bei Ausführung).

Hui...

Is ja schick, bisher schauts gut aus, und ich habe nicht so ein RIESEN-Hammer-Teil wie tvmovie2vdr zu laufen.

Bin zufrieden und spreche hiermit ehrfürchtig meinen Dank aus!

Ich hätte da noch was:

Bug oder Feature?

su -c '/usr/bin/epgdata2vdr.sh >> /var/log/epg-update' vdr

in der cron-Datei macht bei mir, außer das Datum in die LogDatei zu schreiben nichts.

Entferne ich den Userwechsel, löwt's...

Die CRON-Sachen werden doch von 'root' ausgeführt, also dürfte da kein Rechte-Problem auftauchen. Der Datentransfer erfolgt doch über das svdrp-Protokoll, da dürften Rechte eigentlich keine Rolle spielen, da der VDR selbst die Daten in die /var/cache/vdr/epg.data reinschiebt, oder?

Bei mir scheiterte es bestimmt daran, dass /usr/bin/epgdata2vdr.sh root/root und 750 gesetzt hatte, klar, ich mein nur dass der Userwechsel eigentlich gar nicht nötig wäre.

Oder irre ich? Dann nehme ich alles zurück und behaupte das Gegenteil!

-==[Schubsi]==-

Was mich an der ganzen Sache so verwundert hat, dass ein schlichtes 'make" im Source-Verzeichnis zu den merkwürdigsten Fehlern führte... Mmmmh, naja, ich habe eine Vermutung: Das Makefile dieses für debian modifizierten Source-Pakets ist etwas "ungepflegt", klar, braucht ja auch keiner, weil der debian-way ja ein anderer ist (dpkg-buildpackage)...

Da muss man als Laie - wie ich meine Wenigkeit einstufe - aber erst mal drauf kommen, weil man sehr viele Treffer bei Guckle durchgeschmökert hat und immer wieder auf Wege wie
"make && make install ... und gut ists"
verwiesen wird.
Auch der Tipp, den Source mit apt-get source... zu erhalten, war goldeswert, wäre ich nie und nimmer drauf gekommen!!!

Nun ja, egal wie, ich bin Dir unendlich dankbar für Deinen Hinweis, ohne den ich die Tischkante hier wieder um einige Zentimeter kürzer gemacht hätte...

-==[Schubsi]==-

Quote

Original von steffen_b
Die Bilder werden nach png umgewandelt und verkleinert. IIRC brauch das irgendein Part damit er die Bilder darstellen kann. Geht zumindest hier in Live. wenn vdradmin das anders braucht ...

Hoppla, sorry, dass ich evtl. die Pferde scheu gemacht habe: Nachdem ich den kompletten EPG geleert und neu importiert hatte, tauchten doch tatsächlich kleine Bildchen auf...

Nix für ungut, gell...

-==[Schubsi]==-

Hallo Carsten...

Vielen Dank für Deine Empfehlung, Du hast 100% richtig gelegen!

Habe es zuerst mit einem 'make' versucht, was aber scheiterte.

Mit einem freundlichen dpkg-buildpackage liefs dann nach Installieren von fehlenden deb-Paketen einwandfrei.

Die Sache mit dem "mach mal ein debian-patch, trage es ein und aktiviere es" habe ich nicht geschnallt, aber die betroffene svdrp.c lies sich problemlos manuell patchen und nun steht mir die erweiterete PUTE-Funktion (EPG-Daten aus einer Datei übergeben) zur Verfügung.

TOP! 5 Sterne in alle Kategorien

-==[Schubsi]==-

Huhu...

ich habe es mit der Hilfe von user slime (siehe hier) geschafft, den e-tobi vdr (-13ctvdr3) plus multipatch inklusive PUTE-Patch nach zu bauen, hab ganz schön lange für gebraucht, aber die Funktion steht nun zur Verfügung...

Der EPG-Import scheint fehlerfrei über die Bühne zu gehen.

Irgendwie vermisse ich die Bilderchen noch (vdradmin-AM), aber eben habe ich festgestellt, dass die Pics im PNG Format abgelegt werden. Ich werde mal versuchen, nach zu lesen, warum das so ist (in den Paketen von epgdata.com sinds JPGs).

Das NoEPG-Plugin habe ich vorerst noch weg gelassen, stand IIRC hier irgendwo m Thread, kuck ich nochmal.

Frage: Werden vorhandene Einträge von der VDR-eigenen EPG-Funktion nun überschrieben? Nicht dass da ein Konkurrenzkampf entsteht???

Vorerst bin ich zufrieden...

-==[Schubsi]==-

Nun bin ich doch wieder da angekommen, wo ich bei der Planung meines neuen VDR Bedenken hatte, nämlich von fertigen VDR-Paketen abzusehen und alles selber zu bauen... Man hatte mir damals abgeraten, nun bin ich wieder an der Stelle angekommen, wo ich nicht weiterkomme:

Für den Import von EPG Daten (Abo bei epgdata.com) möchte ich gerne epgdata2vdr nutzen. Dieses wiederum benötigt einen Patch der PUTE Funktion (SVDRP).

Ich nutze das etobi Repos

deb http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch

weil mir das so empfohlen wurde.

In diesem "vdr-multipatch" ist der Patch für PUTE nicht enthalten.

Wenn ich das richtig verstanden habe, benötige ich nun

1. Den Ur-Code von VDR 1.6.0-2
2. den Patch auf ...-13ctvdr3 (ist das = vdr-multipatch?)
3. den Patch für PUTE

damit ich nach einem MAKE eine VDR-binary habe, die als Ersatz für die originale VDR-binary eingesetzt werden kann.

Falls ich irgendwie völlig daneben liege, möge man mich bitte in die richtige Richtung schubsen!

Hat irgendjemand hier ne Idee, wie ich an den "vdr-multipatch" von Tobi rankomme? Ich such mir hier die Finger wund, Millionen Treffer in Guckle, aber keiner bringt mich auf den richtigen Weg.

Ich bin am Verzeifeln! :-S

-==[Schubsi]==-

MegaV0lt

Gute Testmöglichkeit! Es kommt leider kein [@file] dahinter, es ist also nicht enthalten...

Mmmmmhh, also wenn ich das jetzt richtig verstanden habe, muss ich mir nun die VDR-Sources holen, die Patches von e-Tobi darauf anwenden, dann das PUTE-patch, anschließend ein MAKE und die originale VDR-DATEI dann mit der neuen ersetzen. Kann das funktionieren?

-==[Schubsi]==-