Beiträge von mikrosaft

hi mbc,

hab gerade mal das script ausprobiert...
Und ich muss sagen, da het der Ronny ganze arbeit geleistet. Ich bin natürlich nicht alle Optionen durchgegangen (weil nur auf die schnelle), aber das ganze macht wirklich den Eindruck eines "rundum sorglos"-paketes.
Deine Kritik kann ich allerdings bestätigen:
Das Menu ist wirklich ein wenig überfrachtet (je mehr Möglichkeiten man hat, desto mehr ist das Menu überfrachtet - logisch) - für Profis vielleicht nicht das schlechteste, aber für den Durchschnitts-Dau eher ungeeignet.
Eine Option ganz am Anfang (etwa in der Art

[] Dau-Freundliche installation 
[] Erweiterte Auswahl (Profi) )

mit einer Grundauswahl an Basispaketen bei ersterem wie bei der SuSE-Installation von YaST angeboten könnte nicht schaden. Mal schauen, vielleicht kann ich dem Ronny einen derartigen Vorschlag (mit entsprechender Vorlage) machen.
Allerdings ist das auch eine Frage der Sichtweise bzw. der Anwenderwünsche. Eine gute Doku des Install-Scripts kann natürlich den Nachteil der Unübersichtlichkeit aufwiegen (zur Doku kann ich noch nicht allzuviel sagen - gibts noch eine andere als die beim Script mitgelieferte?)
Nun ja, unterm Strich ist das Script auf jeden Fall ein mächtiges Werkzeug zur vdr-Installation und Verwaltung...

Gruss
ms

Genau das ist mit "Dreisatz" gemeint... (./configure && make && make install)

Ich gebe Dir völlig recht, es muss eine Menge Arbeit dahinter sein, das Script immer aktuell zu halten...
Und es ist wohl auch eher Sinnvoll das Script (in seiner bisherigen Form) weiterzuentwickeln, als in die andere Richtung (per rpm wie von mir vorgeschlagen) zu gehen. So wie ich das sehe ist das Script ja ziemlich Distributionunsabhängig.
Na ja wie schon gesagt, ich versuche gerade mich da reinzuarbeiten, aber bis dass ich soweit bin, dass ich da den Dreh raus habe, werden wohl noch ein paar Tage vergehen (ich tu mich mit fremden Code immer ziemlich schwer)...

Gruss
ms

p.s. Obwohl, den Gedanken an ein SuSE-vdr Script auf reiner rpm-Basis habe ich noch nicht ganz aufgegeben...

hier im DL-Bereich, ist der erste Download auf der Seite:
http://www.vdrportal.de/board/portal_download.php?lid=140&dbid=47&sid=

Gruss
ms

Zitat

Original von hjs
Womöglich lässt sich die Versammlung durch Verkauf auch wieder verkleinern

Aber nur, wenn du _nicht_ die *-hjs.rpm's nimmst. Die schalten nämlich den Prozessorlüfter aus, bevor der Kompiler angeschmissen wird...

Spass beiseite... Ich arbeite mich gerade durch Ronnys Install-Script. Und so wie es aussieht, stehe ich entweder vor einer Sysiphus-Arbeit, wenn das Script die Basis werden soll, oder aber das Projekt ist schon gestorben (sozusagen ne Totgeburt).
Weil, abgesehen von dem Makel (wenn es denn einer ist - was Ansichtssache wäre) dass das Script "Dreisatz"-basiert ist, kommt es der Definition von Perfekt schon ziemlich nahe. Ich glaub ich werd meine Spielwiesen-Platte mal leerputzen und das Script auf einer "jungfräulichen" 9.0 nur mal so zum Spass laufen lassen...

Gruss
ms

Zitat

Original von mbc
[...]
Mir sagte man mal das rpms nicht optimal sind, die "beissen" sich gerne mal gegenseitig.

Vor allem wenn man einen Teil als rpm und den anderen (als Abhängigkeit) als "source" installiert (wie du bemerkst hab ich da null Ahnung, alleine schon von der Ausdrucksweise her ...).

Hatte selber Probleme mit "imlib" gehabt, hab dann das rpm rausgeschmissen und von Hand nachinstalliert.

Generell wird von rpms abgeraten, soviel hab ich mitbekommen, aber der Rest ist mir zu kompliziert.
[...]

MFG
Marco

Alles anzeigen

Das siehst Du schon richtig, mit dem beissen. Und genau da wollte ich ja Ansetzen. Die ganzen rpms so aufeinander Abstimmen, dass sich da nix mehr "beisst".
Und wie Du schon vorhin in Deinem Post angemerkt hast ist das Installscript dafür wohl ideal geeignet (ich muss eingestehen, dass ich das install-Script nicht benutzt habe, ich schaue es mir aber gerade an...).

Gruss
ms

Hi Marco,

hmm, das ist natürlich ein Killerargument mit dem install-Script.
... aber genau deswegen habe ich auch diesen Thread ins leben gerufen, damit mir ggf. jemand sagt "warum einfach wenns auch kompliziert geht?".

Wobei noch ein kritikpunkt offen wäre: Warum nutzt man nicht die Möglichkeiten der Paketverwaltung, wenn man kann. Letztendlich wäre es schon von Vorteil, wenn nichts mehr per "Dreisatz" installiert werden muss. Damit hätte man auch ein absolut konsistentes System... Das könnte wahrscheinlich soger sehr gut über das Install-Script funktionieren. Allerdings müsste man da wirklich immer aktuell sein mit den Paketen.

Gruss
ms

Nein, Du hast mich (glaube ich) falsch verstanden.
Wenn ich mit checkinstall ein Paket erstelle, dann beinhaltet dieses Paket nur die binären Dateien (und Doku). D.h. das Paket wird wahrscheinlich nur auf dem System laufen, auf dem es kompiliert wurde (bzw. ein gleichartiges). Dann wird es schon schwierig, wenn derjenige der das Paket nutzen will, eine SuSE 8.2 benutzt, und der Paketbauer hat ein 9.0-System. Und checkinstall kann auch keine Abhängigkeiten handhaben. Das könnte sogar zum Abschuss des ganzen Systems führen (gerade bei einem Neuling).
Der Vorteil von echten rpm's wäre, dass das Paket durch rpm auf dem Zielsystem kompiliert (und auch einem Newbie kann man ein "rpm -rebuild" zumuten). Damit wäre jeder SuSE-User in der Lage die entsprechenden Pakete zu installieren (nicht nur diejenigen, die zufällig die gleichen Bibliotheksversionen im Einsatz haben wie ich), unabhängig von der SuSE-Version.
Ich garantiere Dir, dass ein von mir erstelltes checkinstall-rpm vom vdr auf höchstens 5% der SuSE-Systeme hier aus dem Forum laufen würde.
Wie ich schon in meinem Post etwas weiter oben angedeutet habe, habe ich ausserdem nicht unbedingt eine "vollständige" vdr-Ausstattung (=unbegrenzte Anzahl aller möglichen DVB-Karten, unterschiedliche Systeme, etc.).
Das heisst, wenn jemand das Paket z.B. erweitern will, damit es vielleicht mit dem mpeg-Encoder vom Epia läuft, kann er das jederzeit tun - wenn er die src.rpm's zur Verfügung hat. Und wenn das ganze funktioniert, werden (hoffentlich) mehrere Leute weiterentwickeln.
Das heisst nicht, dass jede Neu-/Weiterentwicklung hier aus der vdr-Szene sofort übernommen werden muss. Das wäre auch unfug und nicht das Ziel der Aktion.
checkinstall hat noch einen weiteren Nachteil: War Deine vdr-Installation nach dem "Dreisatz" fertig? Meine nicht. Die ganzen Änderungen an z.b. Bootscripten, Konfigurationsdateien, etc. willst Du ernsthaft über ein checkinstall-rpm durchführen? Zeig mir mal wie das geht...
Also, um das ganze noch einmal in einen Satz zu fassen:
Die rpm-Pakete sollen für die Zielgruppe Newbie sein, und anderen Entwicklern die Möglichkeit bieten Änderungen (für die Zielgruppe) durchzuführen.
Ich hoffe, das war verständlich.

Gruss
ms

*lol*
Versuch mal bei Packman ein checkinstall-rpm abzuliefern. Ich glaub das wär nicht so gut für Deinen Ruf...
Nein, mal im Ernst: Checkinstall ist bei dem Projekt ein klein wenig überfordert. Das ganze werden "echte" rpms werden, und die srpm's werden wohl auch gebraucht, um das ganze für die unterschiedlichen Prozessortypen lauffähig zu machen (ich denke da nur an VIA C3 u.ä.).
Und andere (Entwickler) haben bei checkinstall-rpms keine Möglichkeit, Änderungen einzuarbeiten. Ne ne, checkinstall kanst Du vergessen, wenn das ganze Portabel sein soll...

Gruss
ms

[edit]
checkinstall hab ich übrigens installiert und benutz es auch ab und zu...
[/edit]

Hmm, da werd ich aber eher weniger weiterhelfen können, weil wegen fehlender Hardware...
Ich hab leider nur ne FF und keine LowBudget insofern kann ich da nicht viel tun...
Man könnte vielleicht `ne "Basisversion" erstellen und anschliessend Zusatzpakete schnüren a la "SuSEvdr-Basic" und "SuSEvdr-Pundit-AddOn" oder so...
Da müssten dann aber Leute mit der entsprechenden Hardware (und vor allen Dingen Zeit) mitarbeiten...
Na ja, mal sehen wie weit ich mit meinem Vorhaben überhaupt komme...

Gruss
ms

... und die Faulheit anderer Leute soll man ja schliesslich auch nicht unterstützen, nicht wahr?
Andererseits denke ich, dass die (meisten) Leute die LinVDR (oder ct'vdr) einsetzen auf die Art und Weise niemals von ihrem M$ loskommen. Und gerade für diese Leute wäre das doch IDeal. Ein funktionierender vdr, mit dem man auch noch arbeiten kann...

Gruss
ms

Tach hjs,

ja, das ist in der Tat mein Plan, aber da wollt ich vorher lieber erst mal die Windrichtung testen, bevor ich da viel arbeit für die Katz habe...
Also frag ich hier lieber erst nach. Denn in der *nix-Gemeinde ist es ja so: Entweder eine bestimmte Software wird entwickelt (weil viele Sie brauchen/wollen) oder sie wird nicht entwickelt (weil sich keiner für interessiert).
Gruss
ms

Hallo Leute,

ich hab da mal ne ganz blöde Frage...
Gibt es einen besonderen Grund, warum es keine fertigen rpm-Pakete gibt für eine "rundum-glücklich-vdr-installation" unter SuSE?
Die meisten Sachen müssen ja aus den Quellen mit make && make install erstellt werden, wobei vorher noch ne Menge patcherei anfällt. Und wenn ich erst daran denke, wie ekelig die vdrconvert-Sache mit den ganzen Anhängigkeiten wurde...
Da ist doch (wie auch das Forum hier zeigt) der ein oder andere Neuling total überfordert.
Wäre da nicht eine vdr Installation nach dem Motto "Nimm die und die rpm-Pakete und installiere die, lern Deine Fernbedienung an und es läuft" die "Eierlegende Wollmilchsau"?
Da es noch kein derartiges Paket gibt, frage ich mich warum...

a) kein Bedarf (was ich nicht glaube)
b) nicht machbar (was zu Beweisen wäre)
c) ...

zu b) Natürlich ist es klar, dass so etwas nur in einer definierten Umgebung funktioniert. Aber ich denke trotzdem, dass man durchaus einen grossteil der möglichen Konfigurationen abdecken könnte. Und der "support" wäre auch einfacher, da der Neuling nur noch zu sagen bräuchte "Ich habe bei folgender Hardware das rundumglücklichpaket in Version 1 installiert", und man viele "Standartfehler" von vornherein ausschliessen könnte. Oder liege ich da falsch...?
Was sagt Ihr dazu?

Gruss
ms

Hallo Leute,

nachdem ich mehrere Nervenzusammenbrüche, Schreikrämpfe und mehrer Liter Kaffee hinter mir habe ist mir jetzt (endlich) der durchbruch gelungen...

Das Ergebnis ist (an dieser Stelle) ein Mini-HowTo für die o.a. Migration (welches noch zu ergänzen wäre...):

Systemvoraussetzungen:
SuSE 9.1 (prof.) mit folgenden SuSE-Paketen
-v4l
-lirc (!)
-dvb (!)
-km_dvb (die Sourcen des Treibers)
...und der ganze Krempel, der schon bei den älteren Releases dazugehörte...
dann wird noch der alte dvb-1.0.0 Treiber benötigt (der unter /usr/local/src/DVB liegen muss)
-vdr-1.2.6 (oder höher) mit den diversen Patches
-Homebrew Lircempfänger
-Nexus-S (wahrscheinlich läufts auch mit jeder anderen FF-Card)

Vorausgesetzt es lief auf dem alten System schon ein vdr, der frei nach Schmidinger installiert wurde, ist der neue vdr in kürzester Zeit lauffähig...

LIRC:
========

Änderung von /etc/rc.d/boot.local

#dies in /etc/rc.d/boot.local hinzufügen
/bin/setserial /dev/ttyS0 uart none #je nach COM-Port auch ttyS1

YaST -> System -> Sysconfig...:
Hardware -> LIRC ->
LIRCD_DRIVER="default"
LIRCD_DEVICE="/dev/lirc"
LIRC_MODULE="lirc_serial"

YaST -> Runlevel Editor...:
lirc auf RL 3 und 5
dvb auf RL 3 und 5

Jetz muss noch die alte lircd.conf nach /etc kopiert werden und es ist fast geschafft...

Überprüfen kann man das bisherige Werk mit

vdr@vdrbox:> rclirc start
vdr@vdrbox:> irw

Wenn jetzt die Fernbedienung malträtiert wird sollte eigentlich die zuordnung aus der lircd.conf über den Bildschirm rauschen...

vdr@vdrbox:> rcdvb start

...lädt den dvb-Treiber. In /var/log/warn sollte jetzt etwa folgendes stehen...

Jun 10 18:21:53 c3po kernel: saa7146: unregister extension 'dvb'.
Jun 10 18:21:55 c3po kernel: saa7146: register extension 'dvb'.
Jun 10 18:21:55 c3po kernel: saa7146: found saa7146 @ mem f0c6d000 (revision 1, irq 5) (0x13c2,0x0003).
Jun 10 18:21:55 c3po kernel: DVB: registering new adapter (Technotrend/Hauppauge PCI rev2.1).
Jun 10 18:21:55 c3po kernel: Technotrend/Hauppauge PCI rev2.1 adapter 0 has MAC addr = 00:d0:5c:21:3a:53
Jun 10 18:21:57 c3po kernel: DVB: AV7111(0) - firm f0240009, rtsl b0250018, vid 71010068, app 8000261a
Jun 10 18:21:57 c3po kernel: DVB: AV7111(0) - firmware supports CI link layer interface
Jun 10 18:21:57 c3po kernel: av7110(0): adac type set to 0
Jun 10 18:21:57 c3po kernel: videodev: "av7110" has no release callback. Please fix your driver for proper sysfs support, see [URL]http://l[/URL]
wn.net/Articles/36850/
Jun 10 18:21:57 c3po kernel: saa7146_vv: saa7146 (0): registered device video0 [v4l2]
Jun 10 18:21:58 c3po kernel: bt878 find by dvb adap: checking "Technotrend/Hauppauge PCI rev2.1"
Jun 10 18:21:58 c3po kernel: bt878 find by dvb adap: NOT found "Technotrend/Hauppauge PCI rev2.1"
Jun 10 18:21:58 c3po kernel: probe_tuner: try to attach to Technotrend/Hauppauge PCI rev2.1
Jun 10 18:21:58 c3po kernel: drivers/media/dvb/frontends/stv0299.c: setup for tuner BSRU6, TDQB-S00x
Jun 10 18:21:58 c3po kernel: DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)...

Nachdem man sich vergewissert hat, dass der alte (1.0.0) DVB-Treiber in /usr/local/src/DVB liegt können wir in /usr/local/src/VDR

vdr@vdrbox:/usr/local/src/VDR> make REMOTE=LIRC && make plugins

anschmeissen.
Wenn wir jetzt noch dafür sorgen, dass der neue vdr seine alte umgebung in /video findet können wir mit

vdr@vdrbox:/usr/local/src/VDR> ./vdr -w 60 -t /dev/tty8 REMOTE=LIRC

einen ersten Testlauf starten. Der vdr müsste jetzt eigentlich mit seinen altbekannten Einstellungen laufen und auf die FB reagieren.
Als letztes wäre noch die runvdr anzupassen (lirc und der dvb-Treiber werden ja jetzt über rcscripte geladen und nicht mehr mit insmod bzw. modprobe).
Wie das genau geht muss ich noch ausprobieren, aber das dürfte ja dann kein grösseres Problem mehr sein...

Gruss
ms

P.S.: Wenn mir jetzt noch einer erklärt, wie ich vdrconvert ans laufen kriege bin ich glücklich...

Mahlzeit Leute,

hab mal ein wenig gesucht, aber nicht allzuviel aufschlussreiches gefunden... Also hier meine Frage(n):
Laut changelog zu dvdauthor 0.6.1 heisst es, dass die libxml2 Anforderung auf 2.5.0 reduziert wurde. In allen folgenden changelogs 0.6.2-0.6.10 habe ich nirgendwo einen Eintrag gefunden, dass diese Anforderung wieder hochgesetzt wurde auf > 2.6.
Warum meldet also eine ./configure, dass meine libxml2-2.5.x nicht ausreichen würde? Haben die Entwickler einfach nur vergessen, die Abhängigkeiten zu aktualisieren und ich kann getrost selber Hand anlegen um dvdauthor zu kompilieren, oder wie sieht das jetzt aus?
Weil, auf die Probleme, die mit einem Wechsel der libxml2 auf 2.6.x einhergehen kann ich gerne verzichten...

Hat jemand dazu vielleicht weitere Infos bzw. Tips?

Gruss
ms

Mahlzeit Leute,

kurze Frage ... : Welches Netzteil ist für das Epia (zum Lüfterlosen, bzw. Lautlosen Betrieb mit dem Epia geeignet?
1. Astec AA21870 (pollin)
145 Watt-Schaltnetzteil mit eingebautem Lüfter, Kaltgeräte-Einbaustecker und Kaltgeräte-Einbaubuchse. Betriebsspannung 115/230 V umschaltbar. Abmessungen: 100x100x180 mm.
Ausgangsspannungen:
- +12 V/3,5 A (6 A/10 sec.)
- +5 V/10 A
- +3,3 V/8 A
- -12 V/0,4 A
- +5 V/2 A Aux.

oder 2. Minebea S26113-E463-V20 (pollin)
Eingang 90...137 V/180...264 V, 50-60 Hz. Ausgang +3,3 V/8 A, +5 V/6 A, +12 V/7,5 A, -12 V/0,4 A. Maße (LxBxH): 305x86x86 mm.

Gruss
ms

Jetzt fehlt nur noch jemand der LinuxBIOS auf dem Epia am laufen hat und ich bin glücklich...

@ Riser: Wäre die richtig? http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&category=3666&item=3453785594

Gruss
ms

Mahlzeit,

bin beim Bau meines VDR (siehe auch hier: http://www.vdrportal.de/board/thread.php?threadid=11190&sid=) und hatte mich schon fast auf ein MB festgelegt, ein ECS L7VMM3.
Beim stöbern hier im Board bin ich jetzt aber mehrmals über eine sog. PCI-Risercard gestolpert, und bin jetzt unsicher geworden.
Bisher bin ich immer davon ausgegangen, dass mit ebendieser Riser die Karte horizontal statt vertikal eingebaut wird. In mehreren Posts habe ich das jetzt aber so verstanden, dass man damit auch aus einem PCI-Slot 2 machen kann.
D.h. ich könnte dann z.B. auf dem Epia M10000 2 DVB-Karten einbauen? Wenn ja, dann werde ich wohl auf Epia umschwenken...

Grützlies
ms

[edit] Link geändert [/edit]

na ja, wenn die Kühlung teurer wird als das Board (http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=3452922730&category=23186&rd=1) dann stimmt aber irgendetwas nicht. Ausserdem soll das wie gesagt wohnzimmertauglich werden, und wenn ich da an meine Aquariumpumpe denke... die macht nen Krach, das hört man sogar durch ne geschlossene Tür.

Zur Überdimensionierung @XP2600+ muss ich Dir recht geben, aber weniger Leistung bekommst Du auch nicht unbedingt für weniger Geld, insofern schadet es auch nicht, denke ich.

Gruss
ms

Mahlzeit Leute,

bin beim Bau meines HTPC-VDR und stehe vor zwei Fragen:
Womit lässt sich der o.g. Proz. Kühlen, ohne dass man den Lüfter hört? Hab mal versucht ein wenig Infos zu sammeln, aber es scheint ja so, als ob für jeden Prozessor ein anderer idealer Küher existiert.
Da der VDR ja eher weniger Systemressourcen benötigt, denke ich, dass der Proz. meist im Idle verbringt, also nicht ganz so warm wird...

2.: Kann man beim ECS L7VMM3 Mainboard den Kühler vom OnBoardprozessor abwerkeln oder ist das ganze eine Einheit?

Gruss an alle
ms

hi burki,

nimm nicht die von conrad...
hab es zwei mal mit conrad probiert, aber die dinger sind absoluter schrott. die erste (cv-300, vorgängermodell der cv-250) war nach nem jahr tot. die zweite hab ich mir vor etwa nem halben jahr gekauft, die gibt jetzt auch langsam den geist auf. ich denke, dass es an minderwertiger qualität der bauteile liegt. bin jetzt auf ne philips FB umgestiegen. die sbc ru 545/00 funktioniert sehr gut. ich hoffe die hält etwas länger als der schrott von conrad...

gruss
m'saft