Beiträge von muellerph

    Nur ganz kurz:
    Du mußt sehen was schief geht. Das sieht man in den Log - Dateien:


    cd /var/log
    ls


    Hier stehen alle Logdateien.


    Interessant ist vor allem syslog.
    Kannst mit nem Editor ansehen oder auf der Konsole mit:


    cat /var/log/syslog


    Ein andere wichtiger log eintrag ist dmesg, hier stehen die Bootmeldungen gespeichert drin. Die steht genauso in diesem Verzeichnis, kannst aber auf der Konsole direkt anzeigen lassen mit


    dmesg


    Was noch interessant ist, ist ob die Module geladen wurden:


    lsmod


    Mit den 3 Informationen kannst Du was anfangen, z.B. hier posten und weiterfragen.

    Hallo Wilderigel,


    habe die Zeile ausprobiert (wie schaffst Du sowas nur aus dem Kopf hinzuschreiben..).
    Leider führt es zum gleichen Ergebnis, wenn auch die Fehlermeldung selbst nun zwischen Syslog und Befehlszeile aufgeteilt ist.
    Befehlszeile:

    Code
    vdr: warning - cannot set dumpable: Invalid argument
    vdr: no primary device found - using first device!


    Und im Syslog:


    Also wie schon befürchtet ein tieferes Problem mit Streamdev selbst.
    Interessant daß es nirgends erwähnt ist, weder Wiki noch in irgendeinem anderen Thread.


    Soll ich es ins Wiki schreiben, daß man ohne DVB-Karte das Sky-Plugin mitinstallieren muß/soll?

    Danke für die schnelle Antwort.


    Yepp, das Sky-Plugin half. Nun startet der Client, der Server bekommt den Request (Syslog) und ich kann weiter an den Einstellungen arbeiten.


    Das hat also das Symptom behoben, die Ursache ist es aber nicht.
    Sprich: Stand heute ist das Paket streamdev-client noch nicht ein vollwertiger DVB-Kartenersatz.


    Soll ich mich an den Autor wenden (Bugreport) oder ist es ein C't bzw. Paket bzw. runvdr-Problem?

    Bin gerade dabei mir einen Development Rechner aufzubauen. Hatte zuerst mit Kubuntu auf einer eigenen Partition experimentiert, bin aber nicht weiter gekommen . Habe nun C't6 in einer virtuellen Umgebung aufgebaut und stehe beim gleichen Problem fest. Sowohl mit den originalen als auch mit e-tobi.net Paketen habe ich das gleiche Problem.
    (Anmerkung: Ja ist ein Crosspost, aber das eine war Kubuntu, jetzt ist es die C't)


    Zum Problem.
    Der Rechner (naja, die virtuelle Umgebung) hat keine DVB-Karte, habe aber das streamdev-client Plugin installiert (als Ausgabe das vompplugin).


    Wenn ich den VDR starte kommt es zu folgendem Syslog-Eintrag:


    Der entsprechende Teil der setup.conf auf dem Client:

    Code
    streamdev-client.RemoteIp = 192.168.178.10
    streamdev-client.RemotePort = 2004
    streamdev-client.StartClient = 1
    streamdev-client.StreamFilters = 1
    streamdev-client.SyncEPG = 1


    Die IP-Adresse paßt. Der Port ist der selbe wie auf dem Server.


    Auf dem Server ist das streamdev-server Plugin installiert und 192.168.178.0/24 freigegeben. Via telnet kann ich vom Client darauf zugreifen und der Port 2004 antwortet. Hier wird auch auf dem Server ein entsprechender Eintrag im Syslog hinterlegt. Ist also weder ein Zugriffsproblem beim Server, noch eine Netzwerkproblem noch daß der Dienst auf dem Server selbst Schwierigkeiten macht.


    Beim Starten des VDR kommt auf dem Server gar kein Syslog-Eintrag.


    Was muß ich also beim Client noch machen? Bin jetzt ratlos.
    Nachdem ich jetzt 2 Installation probiert habe und sowohl Google als auch das Forum im einzelnen durchforstet habe, kommen bei mir Zweifel auf ob es nicht ein genereller Bug ist.


    Hat denn einer mit den aktuellen e-tobi.net bzw. C't6 Paketen einen DVB-Kartenlosen Client am laufen, der auch startet?


    Danke für die Hilfe.

    Bin gerade dabei mir einen Development Rechner aufzubauen.
    Der basiert nun auf Kubuntu 7.04 aber mit den e-tobi Paketen.


    Zum Problem.
    Der Rechner hat keine DVB-Karte, habe aber das streamdev-client Plugin installiert (als Ausgabe das vompplugin).


    Wenn ich den VDR starte kommt es zu folgendem Syslog-Eintrag:


    In der setup.conf (Client) steht folgendes zum Streamdev:

    Code
    streamdev-client.RemoteIp = 192.168.178.10
    streamdev-client.RemotePort = 2004
    streamdev-client.StartClient = 1
    streamdev-client.StreamFilters = 1
    streamdev-client.SyncEPG = 0


    Die IP-Adresse ist die des Servers.


    Auf dem Server ist das streamdev-server Plugin installiert und 192.168.178.0/24 freigegeben. Sowohl mit HTTP via z.B. Xine oder mit VTP via telnet kann ich vom Client darauf zugreifen / bzw. einen Kanal ansehen. Ist also weder ein Zugriffsproblem beim Server noch daß der Dienst Schwierigkeit macht.


    Was muß ich also beim Client noch machen? Bin jetzt ratlos.

    Hallo,


    die Warnung war nur ne Warnung, falls andere darauf einsteigen wollen - nicht als Kommentar an Dich.


    Da Du ja schon einiges an Erfahrung mit Linux hast, sind wir schon recht am Ende der pauschalen sowie nachvollziehbaren Eigenschaften von Distributionen und gehen in den Bereich der persöhnlichen Vorlieben.


    Also ganz persönlich meine Meinung ;)


    - Habe selber ein Fernwartsystem. Am VDR ist weder ein Fernseher noch ein Monitor angeschlossen.
    - Erfahrung mit Linux - SuSE und Debian. Die erste Disti war die SuSE 5.1
    - Ich verwende den Server auch noch für andere Zwecke (Email, Dateiserver)
    - Stabil ist für mich ein absolutes muß. Ohne VDR gar kein Fernsehen, entsprechend die Wichtigkeit für den Haussegen!


    Daher hier einfach mein Entscheidungsweg zur Distributionsfindung meines VDRs:
    1. Ich ziehe Debianbasierte Systeme für meinen Server vor, einfach deshalb weil er einfach fernwartbar sein soll. Bei SuSE kann man tolle Sachen mit YAST machen, allerdings ist es nicht so schön fernwartbar wie Debian mittels dpkg / apt / aptitude.


    Wenn ich einen Monitor am Server hätte, würde ich mir SuSE vielleicht sogar überlegen. Insbesondere Samba, DNS, Drucker, etc. sind mittels YAST ganz schick administrierbar. Von der Konsolenversion von YAST bin ich nicht so überzeugt - allein schon die Performance von YAST überzeugt mich hier nicht.


    Ob nun Mandrake, Fedora oder SuSE ist hier alles das selbe für mich. DEB ist für mich einfacher zu handhaben als RPM.


    2. Bei den Debian basierten Distribution kommt für mich nur Debian Etch oder Ubuntu Feisty Fawn in Frage. Ein aktueller Kernel ist zwingend und die DEB müssen aus einem Stable-Zweig stammen.


    Wenn nicht stable, so kann man es eh immer einzeln nachinstallieren.
    Der Server muß ein paar Jahre laufen, da kann ich nicht auf andere Debianbasierte zurückgreifen.



    3. Und hier kommt mein Problem mit Ubuntu: Feisty Fawn wird "nur" 2 Jahre unterstützt. Debian Etch sicher ein paar Jahre länger.
    Mit OpenSuSE, Mandriva, etc. ist es ein ähnliches Problem. Welche dieser Distis wird in >2 Jahren noch supportet?


    4. Daher ist mein Server ein Etchserver, basierend auf der C'T. Hier ist es eigentlich egal ob Du die C't 6 oder Etch selbst nimmst. Die Unterschiede sind wirklich marginal. C't installiert den VDR selbst einfach schneller. Alles alles andere ist pures Etch.
    Sollte mal Hardware kommen, die vom Etch-Kernel nicht unterstützt wird, steht immer noch Backports.Org zur Verfügung. Hat mir bei C't 5.5 auch schon geholfen - die Installation war trivial.


    5. Das kompilieren vermeide ich wo es geht. Grund: Stabil sollte es sein und durch die Distribution selbst supportet werden.


    Ich kann kompilieren (hab an KSpread mitprogrammiert), aber wenn es fertige Pakete gibt, behaupte ich mal pauschal, diese laufen immer stabiler als jeder selbst gezogener Quellcode. Daher ist mir eine Unterstützung wie Backports.org und Tobi.net so wichtig.


    6. Unterstützung in den Foren/Wiki:
    Wenn man die Anzahl der Beiträge nimmt, kommst Du auf folgende Distis:
    - LinVDR (76.000)
    - C't VDR (58.624)
    Abgeschlagen aber noch nennenswert sind Gentoo (11.605) und SuSE (8.541).
    Sprich, wenn Du Probleme hast findest Du bei LinVDR und C't am schnellsten die Antwort, allein schon mit der Suche-Funktion.


    LinVDR habe ich nie ausprobiert.
    Einfach deswegen, weil LinVDR primär eine reine VDR-Disti ist. Natürlich kann man bei LinVDR auch viel mehr machen (Samba, etc.), allerdings ist für ich mich die Unterstützung besser bei Debian für diese Zwecke. Auch ist hier das Internet selbst der größte Fundus an Hilfestellung. Bei LinVDR ist man hier eingschränkter.

    Gemeine Frage, kann sich leicht in einen Disti-Flamewar wandeln.


    Egal,


    generell gilt: Eine Distribution hat zu 80% den Zweck ein lauffähiges System zu installieren. Das hast Du nun erreicht - eine andere Disti macht hier nichts anderes.


    Wenn Dich die 20% interessieren, dann kommt es einfach auf Deinen Anwendungsfall an.


    Wenn Du einen reinen VDR betreiben willst, ohne daß er sich über die Zeit großartig ändert (Hardware, Zusatzdienste), dann brauchst Du nicht wechseln - da Du ja einen lauffähigen VDR hast, was soll man da ändern?


    Sollte sich was ändern, dann wäre es gut zu wissen, was sich ändert?
    1. Willst Du an dem Rechner auch arbeiten - z.B. unter KDE/Gnome?
    2. Willst Du die Hardware ändern/erweitern?
    3. Willst Du ihn auch für andere Dienste verwenden, vom einfachem Dateiserver über Mailserver bis hin zu Sachen wir Router mit FW oder virtuelle Boxen installieren?
    4. Willst Du immer auf dem letzten Entwicklungsstand des VDRs bleiben, oder reicht Dir ein VDR, der nur möglichst stabil läuft?


    Und generell:
    5. Wie ist Dein Wissensstand zu Linux? Hast Du Probleme auf der Konsole zu arbeiten oder ist das etwas was Du möglichst vermeiden willst?


    Je nach Anwendungsfall ergibt sich hier eine andere Empfehlung.


    Einen reinen VDR hast Du und die C't alias Debian Etch ist ne feine Sache dafür. Kann auch sehr viel mehr, falls 1.-5. für Dich wichtig sind.
    Aber wenn 3. und 5. sehr wichtig sind, wären andere Distis vielleicht besser geeignet. Kommt halt auf Deinen Fall an.

    Hättest keinen neuen Thread starten brauchen, denn der originale hat schon gereicht.


    Egal:
    So wie ich beim Googlen gesehen habe, unterstützt die Alsaversion vom Etch-Kernel (hier der 2.6.18) diesen Soundchip noch nicht.


    Aber mit einer altualisierten Alsaversion bekommst Du ihn zum laufen.
    Da bist Du aber schon beim Kernelpatchen und selberkompilieren.
    Nicht katastrophal aber eben auch nicht trivial. Anleitung in Englisch auf der Alsahomepage


    Wenn Du Dich scheust den Kernel zu patchen, hättest Du noch die Möglichkeit einfach einen fertigen neuen Kernel zu nehmen. Ob der aktuelle 2.6.20 den Chip unterstützt kann ich aber auch nicht sagen. Ein Test wäre es Wert, versuch mal www.backports.org oder eine andere zu Debian passende Quelle.

    Locker bleiben.
    Eigentlich steht hier nur "You need to reboot soon".


    Und das ist alles was zu machen ist.


    Grund ist hier, daß der Kernel aktualisiert wurde. Halt wegen eines Sicherheits- oder Bugfixupdates.


    Der Kernel selbst könnte sich ja geändert haben und andere Bindungen haben.


    Daher muß die modules.dep neu gebaut werden.


    Und das passiert dann beim Neustart.


    Also steht hier viel Text (der eher verwirrt) und eigentlich geht es nur darum: "Bitte nach dem installieren Neustarten"


    Kennen wir doch vom anderen OS zu genüge ;)

    Zitat

    der Eintrag in die fstab heißt dann in etwa so:


    //WindowsRechnerName/FreigabeName /mnt/mp3s smbfs auto,username=WindowsUserName,password=WindowsPasswort 0 0


    Genau hier hast Du "auto" angegeben. Wie gesagt, das macht nur Sinn wenn der andere Rechner immer läuft, bzw. zumindest immer dann wenn VDR auch läuft.


    Ohne wäre es wie folgt zu machen:
    //WindowsRechnerName/FreigabeName /mnt/mp3s smbfs noauto,username=WindowsUserName,password=WindowsPasswort 0 0


    Sobald sichergestellt ist, daß der Windowsrechner läuft, reicht auf der Konsole ein
    #mount /mnt/mp3s
    und schon ist das Verzeichnis verfügbar


    Wenn man den Windowsrechner ausschaltet, dann ein
    #umount /mnt/mp3s


    Solche Kommandos lassen sich auch per Menü im VDR steuern.

    Interessant ist hier nur die Frage, ist der Rechner mit den Dateien ständig am laufen oder nur bei Bedarf.


    Wenn er ständig am laufen ist, dann trägst Du ihn einfach in die /etc/fstab ein.


    Wenn nicht auch in die fstab, aber hier mit der option noauto.
    Danach mußt Du ihn immer manuell mounten, wenn er verfügbar ist. Ansonsten versucht der VDR-Rechner beim Booten den anderen Rechner zu mounten, was ja dann fehlschlägt und später die Daten trotzdem nicht verfügbar sind. Aber das Probieren dauernd sehr lange und solange hier kein Abbruch passiert ist, bootet der VDR nicht fertig (das Booten dauert so >1min länger).


    Ich würde es generell erst einmal mit NFS probieren. Dazu am anderen Rechner die /etc/exports bearbeiten.


    Alle Details findest Du dann unter der Suchmaschine Deiner Wahl mit z.B. "Howto NFS noauto debian /etc/fstab"

    Es gibt auch noch das Script


    /etc/init.d/bootmisc.sh


    Dieses Script wird sogesehen als letztes ausgeführt.


    Hier kann man auch Befehle eintragen, die nach dem Booten ausgeführt werden sollen.


    Dies ist aber nur sinnvoll, wenn die Reihenfolge im Bootprozess nicht so wichtig ist, laden von Modulen halte ich da für nicht geeignet - da ist wie von wilderigel geschrieben die update-rc Methode zu verwenden.

    Ich sag mal so - hab allerdings den Standardkernel verwendet ohne Schnickschnack wie WoL oder NVRAM, etc.


    Hatte den VDR zuerst auf einem Epia MII-6000 Mainboard.


    Das Board/der Prozi ist mir abgeraucht, da habe ich (aus verständlicher Zeitnot) einfach die Festplatte in einen Rechner mit Asus-MB mit Athlon 500 Prozi gesteckt und ist sofort gelaufen (klar die DVB-Karten mußte ich auch mit reinstecken und die Netzwerkkarte war nun nicht mehr Onboard sondern eine PCI-Karte).
    Mein Gott, hätte das den Haussegen zerstören können, wenn Linux hier nicht so flexibel wäre.


    Nun habe ich das MB und den Prozi gegen ein MB mit Geode-Prozi ausgetauscht (Stromverbrauch). Ist auch sofort gelaufen, aber mußte nun um mein Syslog nicht vollmüllen zu lassen in Grub noch "noapic" eintragen - ein wahrlich erträglicher Zusatzaufwand.


    Alle 3 haben verschieden Chipsätze. Wenns also nicht zu exotisch ist, reicht der Standardkernel für alle MBs. Ich habe leider keine Erfahrung mit Deinen Chipsätzen/MB, kann also nur sagen: Ausprobieren.

    Zitat

    Original von BlackWizard
    -rw-r--r-- 1 root root 26730 2007-05-03 23:05 2_41microcode0.bin
    -rw-r--r-- 1 root root 26498 2007-05-03 23:05 2_41microcode1.bin
    -rw-r--r-- 1 root root 26670 2007-05-03 23:05 2_41microcode2.bin


    Sieht doch schwer nach einer Zugriffsberechtigungsproblem aus.

    Zitat

    Original von Schmattek
    Verstehe folgende Zeilen nicht:


    "vi /etc/ntp.conf # ggf. eigenen Server eintragen
    vi /etc/default/ntp # NTPD_OPTS='-g -x'
    /etc/init.d/ntp restart"


    Was genau bewirken die und wie bediene ich den Editor?


    Genau genommen sind die Zeilen nicht so wichtig für den VDR, nur wenn Du einen Zeitserver zur automatischen Synchronisation der Zeit eintragen willst benötigst Du diese Einträge. Hilfreich aber nicht vorraussetzung für einen VDR.


    Ich kann sehr gut verstehen, daß vi gerade für Nicht-Eingeweihte leicht verdaulich ist.


    Ich nehme statt vi immer den midnight commander.


    apt-get install mc


    Dann kannst Du in den obigen Zeilen das "vi" mit "mcedit" ersetzen und Du hast einen "normalen" Editor.
    Mit "mc" kommst in die normale Midnight Commander Ansicht - dort kann man zuerst eine Datei auswählen und dann mit "F4" mcedit selbst aufrufen.
    Mit "mcedit" auf der Konsole kommst Du direkt in den Editor mit der entsprechenden Datei.


    vi ist cool, aber hat ne steile Lernkurve. Für ne flache einfach nano oder eben mc/mcedit verwenden.

    Nicht die Antwort die Du hören willst, aber bei einem Neuaufbau kannst Du doch gleich zu Edge greifen und VDR aus E-Tobi dazuspielen.
    Die nächste C't Version basiert eh auf Edge und wenn die draussen ist, wird der Support für die alte früher oder später einschlafen.


    Edge hast Du sicher noch ein paar Jahre, zumindest mit Support von Debian.