Beiträge von Elian

    Schließe mich Papsi erster Antwort an. Wenn du *vielleicht* *irgendwann mal* an den Server einen TV hängen willst, dann geb das Geld doch dann aus, wenn du es brauchst. Ein reiner Server braucht keine FF - nimm lieber mehr "normale" Karten.
    Das hardwareencording "hilft" nur dem Rechner, ein Bild auf einen Bildschirm zu bringen. Beim Schneiden "schaut" der Rechner nicht die Aufzeichnung an, sondern schneidet einfach nur - da hilft dir eine FF-Karte exakt 0.


    Zu dem CI-Problem: Bin kein Österreicher, aber es geht doch wahrscheinlich nur um ORF, oder? Alle anderen (deutschen ÖR- und Privaten) bekommst du doch auch (ohne einheimische Werbung) über Astra unverschlüsselt. Also Empfehlung: Nimm (je nach Aufnahmeaufwand) 1-2 Satkarten und für die österreichischen Sender zusätzlich eine DVB-T. Da du sowieso Sat-Kabel irgendwo hinlegen musst (oder kommt die Schüssel auch in den Keller ;-)), kannst du ja (wen du mit der DVB-Antenne im Keller nicht die nötigen Sender empfängst) ja die Antenne mit bei der Schüssel dranschrauben.


    Elian

    So, ich bin wieder aus dem Urlaub zurück mit neuen Ideen und Tatendrang.


    Vielleicht liest das hier ja noch jemand mit und kann mir beim Verstehen helfen: Also, Problem mit "Firmware not found" bei einer TT-FF-DVB-S-Karte, das Ganze unter dem Ct-Server2 mit Xen 3.1 (Debian).
    Einmal habe ich aus dem Debian mit Debootstrap einen Ct-VDR6 als DomU installiert - dort gibt es kein Problem a la "Firmware not found" - der VDR läuft.
    Dann in einer anderen DomU LinVDR Mahlzeit 4 Beta 2 installiert und den ct-Server-2-Kernel reinkopiert und in Grub aktiviert -> Firmware not found". Mit dem Dummydevice läuft der VDR.
    Ich gehe also mal davon aus, dass da was bei meinem LinVDR nicht mag. Die Firmware habe ich nochmal neu runtergeladen und den symlink überprüft, firmware in beide Ordner kopiert, in denen gesucht wird etx pp. Bringt alles nichts, "Firmware not found".


    Was läuft da schief? Kann es sein, dass die DomU die Firmware im Dom0-rootverzeichnis sucht? Sollte doch eigentlich nicht möglich sein, oder? Aber irgendwas macht der VDR unter meiner LinVDR-DomU scheinbar anders als der unter der ct-VDR-DomU. Immerhin benutzen beide den selben Kernel... Ich bin ratlos.


    Vielen Dank schonmal für Ideen...
    Elian

    Schieflaufen kann beispielsweise noch das mit der Firmware... steht ja schon ein paar Seiten weiter vorne, aber das hilft leider nicht weiter: dvb-ttpci verweigert seinen Dienst: could not load firmware.
    Ich habe wie es "der-brumm-baer" vorgeschlagen wurde (Seite 3 glaub ich) ein Modul in eine blacklist eingetragen (die war bei linvdr leer, im XenServer steht da ne Menge drin) und linvdr runtergefahren, dann den gesamten Server neu gestartet - kein Unterschied.
    Auch das selbe mit ge-chmod-deter Firmware bringt keine Besserung, und neue Firmware sowohl nach /lib/firmware als auch in /usr/lib/hotplug/firmware bringt nix.


    Die selbe Karte läuft auf dem selben Rechner unter dem selben Xen-Dom0 im ct-vdr übrigens einwandfrei. Also passt irgendwas mit dem LinVDR nicht... kann mir jemand weiterhelfen? Hat linvdr eine andere "blacklist" für module (rmmod sagt, das dieses Paket nicht existiert) oder was läuft da schief?!


    Gruß,
    Elian

    Hallo,


    ich habs auch geschafft. Die Anleitung von VirtuaDZ war brilliant...
    EDIT: Ich habs etwas ausführlicher beschrieben und kann es dann auch (wenn es denn funktioniert, also Rückmeldung bitte!) im Wiki ergänzen. An ein paar Stellen hab ich sicherlich unabsichtlich einige Umleitungen genommen, die nicht nötig sind - manchmal hab ich einfachnicht rausgefunden, wie's direkt gehen könnte. Also bitte auch verbessern!


    Mein Server benutzt also als Dom0 den c't-Server2 - gibts leider noch nicht als Download. Ich habe wie vorgeschlagen auf ein LVM installiert - also nix mit Images, da weicht diese Beschreibung etwas ab. c't-Xen hat auch etwas andere Namen für die virtuellen Bridges als das bei XenSource vorgesehen ist - also in den Code-Blöcken nicht wundern.


    Also, Xen-Dom0 läuft, hat Internet und keine Probleme. Jetzt braucht es ein Image oder eine 1:1 Kopie des Dateisystems von linvdr. Mangels besseren Wissens habe ich das ziemlich umständlich gemacht und erstmal die Mahlzeit-Iso (4Beta2) unter Xen in eriner HVM-DomU installiert - ich wollte keine zweite Platte in meinen normalen VDR-Client hängen. Erstes Problem: in der Startdatei muss die zu verwendende LVM-Partition als "hda" und nicht als "hda1" angegeben werden, sonst wird keine Platte vom Setup erkannt. Dummerweise lässt sich eine HVM-bespielte Partition (zumindest im LVM) nicht einfach mounten - das HVM-Betriebssystem glaubt ja, es sein eine richtige, ganze reale Festplatte und stellt weiß der Geier was damit an - mounten geht nicht mehr so einfach (schreibt c't in Ausgabe 17, ich hab das einfach geglaubt). Also hab ich mit dd ein DiskImage (image.img) auf eine zweite LVM-Partition gemacht (muss natürlich vorher, aber erst nach der Installation in der Startdatei mit angegeben werden!). Dann die HVM-LinVDR-Instanz beenden, das LV kann gelöscht werden. Die Partition mit dem Image drauf mounten, das Image auch mounten (weiß nicht, wie man das Image direkt reinkopieren kann) und dann den Inhalt kopieren. Hier war MC ein sehr hilfreicher Genosse...
    [An dieser Stelle die Frage, ob man nicht vielleicht einfach aus der Installations-CD die Dateistruktur extrahieren kann - da ist doch eigentlich auch nur eine einzige Archivdatei, in der alles drin ist - oder? Aber ich kenn mich mit den ganzen Befehlen für die Packprogramme nicht aus...]


    Diesen Verzeichnisbaum dann also auf ein neu eingerichtetes LV kopieren - Mahlzeit verwendet in der 4.0 Beta zwei Partitionen: eine für / und eine für /Data mit video, pub, video0. Ich hoffe, dass 3 GB für / groß genug sind - ansonsten läst sich das ja bei einem LVM schnell ändern... lvcreate -L 3G -n lvname vgname
    Das LV für die Data-Partition kann später erstellt werden. Erstmal weiter mit dem Einrichten.


    Dann: den Kernel, die Config und system.map aus Dom0's /boot ins Linvdr-Boot kopieren und die Symlinks im linvdr-boot anpassen. Angepasste symlinks ersparen das Verändern von grub. [Hier ist allerdings vielleicht Mahlzeit nochmal gefragt, ob es nicht besser wäre, doch lieber grub anzupassen, damit zukünftige Updates mit dem linvdrupdater an dieser Stelle ins Leere laufen. Aber erstmal geht es so.] Dann /lib/modules aus der Dom0 nach linvdr's /lib/modules kopieren.


    Dann: die fstab im linvdr-/etc anpassen. Ich habe dort für den ersten Test die /data -Partition auskommentiert und weil ich es nicht brauche am Server die DVD-Einträge. Dann startet zwar VDR nicht, aber es reicht mir erstmal, wenn überhaupt die DomU mit linvdr startet.


    chroot und depmod wie oben beschrieben (fuser kenn mein Debian nicht - hab ichs halt weggelassen... hat wohl nicht geschadet).


    Dann das Linvdr-Dateisystem unmounten. Eine Startdatei für linvdr anlegen - dort ist als Kernel der neu reinkopierte Xen-Kernel anzugeben! Und natürlich das LV mit der Rootpartition als hda1 angeben.

    Code
    kernel='/boot/vmlinuz-2.6.18-4-xen-686'
    ramdisk='/boot/initrd.img-2.6.18-4-xen-686'
    memory='256'
    name='linvdr_xen'
    root='/dev/hda1 ro'
    disk = [ 'phy:/dev/XenServer/linvdr_root,hda1,w' ]
    vif = [ 'bridge=intern' ]


    xm create linvdr_xen (oder wie die Datei halt heißt) - und dann rödelt er los. mit xm console linvdr_xen kannst du direkt von deiner Xen-Dom0-Konsole umschalten auf die Linvdr - und siehst ihn dort noch booten, wenn du schnell genug bist. Ich bin begeistert, dass sogar der grüne Fortschrittsbalken angezeigt wird...


    Nach login wird logread jetzt mosern, dass der vdr kein video-Verzeichnis gefunden hat, aber das war ja klar. Wenn sonst alles läuft, dann nochmal kurz mit ifconfig eth0 die MAC-Adresse merken (kommt in der Startdatei bei "vif= [ 'mac=00:00:00:...,bridge=intern'] mit rein, weil Xen wohl bei jedem Start neue MACs verwendet und ein Linux sonst gerne meint, es gäbe eine neue Netzwerkkarte - muss ja nicht sein. [Da ist udev für verantwortlich, läuft das bei linvdr?]
    Dann gleich noch in der fstab das Data-Verzeichnis wieder aktivieren und dann die virtuelle Kiste runterfahren. Entweder per "poweroff" oder einfach in der Dom0 mit xm shutdown linvdr_xen oder (weiß nicht, ob brutaler - klingt so) xm destroy linvdr_xen.


    Jetzt das Video-LV anlegen, mit mkfs auf ext3 formatieren und dann zusammen mit der MAC-Adresse in die Startdatei eintragen.


    Fertig. Jetzt sollte VDR auch starten (zumindest wenn per Setup das dummydevice ausgewählt worden ist!) und damit ist erstmal gut.
    Mangels DVB-Karten im Rechner kann ich noch nicht sagen, ob das jetzt 100%ig funktioniert - aber immerhin startet der VDR schon mal mit dem Dummydevice unter Xen. Was kann da noch schieflaufen?


    Jetzt fehlt "nur" noch das Durchschleifen der DVB-Karten in die DomU - da erklärt dieser Wikibeitrag genauer, wie das gemacht wird.


    Alle Klarheiten beseitigt? Läuft es jetzt bei dir? Wenn ja, was hattest du vergessen/falsch gemacht?


    Grüssle,
    Elian

    kurz von mir eingestreut: nach diesem Kopiervorgang hast du ja einmal Linvdr quasi original in einem VM gesperrt. Aber der LinVDR-Kernel ist ja nicht mit Xen "behandelt" - der kann nur in einer HVM-DomU so laufen.


    Du musst also in dein Image eine Xen-Kernel reinkopieren (Mahlzeit meinte, es würde oft einfach der Xen-Dom0-Kernel ausreichen) und die entsprechenden Module natürlich auch. Und, damit deine LinVDR-DomU auch schön brav diesen Kernel benutzt, musst du natürlich Grub anpassen.


    Probier mal... so hab ich das verstanden bis jetzt.


    Gruß,
    Elian

    Joe: das war ganz einfach. Ich bin beileibe kein Linux-Freak und nach ein paar Tagen rumbasteln mit Xen unter Ubuntu Feisty hab ich mich entschlossen, einfach den c't-Server 2 zu nehmen. Ich will eigentlich nur einmal Windows mit HVM und eben nen VDR - später zusätzlich irgendwann vielleicht mal Asterisk.
    Wegen HVM und Windows war mir Xen 3.1 wichtig, da sind ja ein paar Verbesserungen in der Richtung drin. Unter Ubuntu gibt es das aber noch nicht fertig, dafür halt von der c't. Also hab ich eben das genommen.


    Nachdem der Server installiert war, hab ich den VDR nach der Anleitung im ct-server-Wiki auf heise installiert - im Grunde nur mit dem ctdombuilder eine neue DomU erstellen und dann mittels debootstrap ein Minimaldebian installiert. Das passiert alles automatisch. Danach die apt-sources.list für den c't-vdr angepasst und den ctvdrcfg geholt - in dem ich dann die entsprechend gewünschte Konfiguration ausgewählt habe und er hat sie installiert. Fertig. Die VDR-DomU läuft (der VDR mangels DVB-Karte im Server noch nicht, aber ich vertraue da ganz der Anleitung), aber ich bin halt kein Linux gewöhnt und mag mich jetzt auch nicht umstellen vom LinVDR auf c't. Und wenns nur so Kleinigkeiten wie logread sind... Außerdem hab ich das Gefühl gehabt, dass mit den c't-VDR jede Menge Müll installiert wird, den ich nicht haben will... ich wüsste nicht, welches Paket unbedingt X braucht - Xine hab ich nicht installiert - aber ich kann es in einer DomU doch eh nicht gebrauchen. Und so weiter.


    Ich werd mich jetzt mal dran versuchen, eine neue HVM-DomU zu erstellen und dort ganz normal von CD die Mahlzeit-Beta zu installieren. Danach will ich die von HVM auf paravirtualisiert umstellen - eben die Xen-Startdatei umschreiben und nen Xen-Kernel reinkopieren. Mal sehn, ob ich das hinbekomme - eigentlich sollte es ja gehen... da ist in der aktuellen c't wieder ein Artikel drin, der das ähnlich macht: In einer DomU ein EisXen installiert mit HVM (ist also DomU vom Grundsystem aus und spielt Dom0 für seine eigenen DomUs), um dann die DomUs des EinXen (an die man wohl sonst nicht rankommt) als DomU des "Basissystems" laufen zu lassen - also ohne EisXen dazwischen.
    Ich bin gespannt.


    Gruß,
    Elian

    super interessante Frage - leider kann ich dir kein Stück weiterhelfen.
    Ich versuche mich grade am selben Problem, bin aber mit dem (bei mir unter Xen laufenden) ct-vdr nicht zufrieden und will gerne wieder linvdr, da kenn ich mich wenigstens aus.
    Nur bin ich zu blöde, um zu verstehen, wie ich das Mahlzeit-Iso überhaupt in eine DomU packen kann... Aber nachdem du das ja scheinbar zumindest soweit gepackt hast, dass es bootet... wie hast du das so weit hinbekommen?


    Wir sollten mal dran gehen, das von Mahlzeit angefangene Thema im Wiki fertig zu stellen...


    Gruß,
    Elian

    entweder ich hab was verpasst, oder du bist auf dem Holzweg.
    Wie kommst du darauf, dass die Versionen übereinstimmen müssen? Wenn überhaupt, dann kommt das nur auf die verwendete Version des Streaming-Plugins an - aber die sollten untereinander auch kompatibel sein.


    In meinen Augen also: Lass G2V auf deinem "Server" und installier LinVDR auf deinem Client. Wenn du die Mahlzeit (reicht auch die 3.2) nimmst, hast du auf beiden Rechnern einen einigermaßen aktuellen VDR mit allen nötigen Plugins. Mit der Original-LinVDR7.0 wird es natürlich schon wegen der Pluginauswahl Probleme geben... da sind sicher weder Xine, noch ffnetdev oder softdevice mit dabei gewesen. Nur streamdev.


    Elian

    hoffentlich liest hier noch jemand mit... ist ja schon etwas staubig, das Thema:
    Dank c't hab ich auch mal angefangen, mich über xen zu informieren. Und wenn Mahlzeit dabei ist, wird das ja auch mit dem VDR recht leicht klappen ;)
    Meine Frage zum Einstieg, ganz allgemein zu Xen: funktioniert unter XEN eigentlich auch Speedstep & Co, also dass sich der Prozessor runtertaktet, wenn nichts zu tun ist? Und natürlich auch wieder hoch, wenn wieder Arbeit da ist?
    Habe mittels Google 2 widersprüchliche Einzelmeinungen gelesen und kann beide nicht wirklich nachvollziehen. Wenn die Dom0 das ACPI-Controlling übernimmt, dann müsste das doch funktionieren, oder?


    Zweite Frage, gehört eng zur Ersten: trotz 24/7-Betrieb soll das gute, noch anzuschaffende Stück relativ stromsparend sein. Intel oder AMD? Jemand einen Tipp? Was ich bsiher gelesen habe, wird AMD wohl energieeffizienter sein? Sind die X2-Athlons eigentlich deutlich langsamer also Core2 Duo's?


    Viele Fragen, vor allem die Erste ist für mich wichtig. Ohne Stromsparen kein all-in-one-dafür-dauernd-laufender-server.


    Gruß,
    Elian

    Ah, eine Antwort :mahlzeit
    Danke dafür erstmal.
    Problem: fbtv bringt mir doch nur was, wenn ich eine FF-Karte drin habe, oder seh ich das falsch? Die will ich aber nicht opfern dafür. Ich möchte nur einen Client mit maximal DXR3, aber ohne jegliche SAT-Karte. Die DXR3 dürfte mir aber nichts dabei bringen, weil ich ja schließlich den VGA-Ausgang der Onboard-GraKa nehmen will.


    Danke trotzdem,
    Elian

    Servus,
    ich bin auf der Suche (und sicher nur zu blöde, dei richtige Suchanfrage zu stellen) nach einer Distribution o.ä., die mir folgendes macht:
    - ich möchte meinen alten VDR-Client nach wie vor als Client benutzen, aber nicht am TV mittels DXR3, sondern am TFT über VGA also Onboard-Grafikkarte.
    - der Client bekommt sein Programm über LAN vom Server (Streamdev oder anderes, mir egal)
    - der Client soll mit seiner integrierten Grafikkarte laufen - da bekomme ich zZt noch nicht mal Framebuffer hin. Ist ein alter IBM Netvista mit irgendeinem Intel-Chipsatz mit Onboard Grafik. Bei Bedarf kommen weitere Angaben.
    - der Client soll den Ton über die Soundkarte analog ausgeben, ist onboard.
    - der Client soll vollständig per LIRC fernsteuerbar sein, so wie er es als VDR am TV auch war. Also ohne Tastatur und Maus!


    So. Meine bisherigen Überlegungen (Softdevice, Xine) scheitern am fehlenden Framebuffer, den ich nicht hinbekomme. Natürlich könnte ich eine stinkenormale Distri ala Ubuntu draufziehen und dann mit VLC beispielsweise den Streamdev-Server abfragen, aber bekomme ich so die Fernbedienbarkeit hin?
    Mehr außer VDR-Streams und -Aufnahmen muss er nicht können, also kein komplettes Mediacenter oder sowas.


    Jemand einen kleinen Schubs in die richtige Richtung für mich?


    Danke,
    Elian

    Ja, soweit war ich auch gekommen.
    Ich hab zwar glaub ich einen Logikfehler (bedeutet "Schnittmarken setzen" ernsthaft "noad starten" oder nicht vielleicht eher "schneiden"?) aber (aaber!) er will ja auf jeden Fall nur schneiden und nicht exportieren :versteck

    Mahlzeit,


    das spdif für die Activy würde ich jetzt nicht auf hohe Priorität setzen (auch wenn ich es selber haben wollen würde).
    Ich habe mir das Post nicht genau durchgelesen von arghgra, aber - der em84 funktioniert doch jetzt in deinem Iso. Halt mit Analogton. Wer Digitalton haben will, der kann doch das Skript entweder selber starten oder etwas anfängerfreundlicher unter der Rubrik "weißt du wirklich, was du tust" im setup aktivieren.
    Dann hast du keine Activy oder sonst einen Rechner auf dem Gewissen (ok, hast natürlich nicht du, aber ich seh schon den Post "Mahlzeit Iso und Rechner raucht"), wenn was bei der automatischen Erkennung schief läuft.


    Gruß,
    Elian

    mahlzeit:


    Danke für Netzwerk-geht-nicht-mehr-Infos und -Update: jetzt funktioniert alles wieder.
    Ich werd heute Abend nochmal den Updater laufen lassen und mich melden, sollte es wieder Probleme geben.
    Ansonsten läuft das ISO bei mir jetzt richtig rund.


    Was ich natürlich noch vermisse, ist da WOL. Aber ich hab gesehen, du bastelst eine Seupt-aktivierbare Lösung - dann will ich nicht weiter drängeln. Funktioniert ja so auch schon super!


    Gruß,
    Elian