Beiträge von IcyA1

    Nochmal Dank an alle. Ich hab's jetzt an der ersten Dose ausprobiert. Zumindest mit dem derzeitigen 100Base-T-Netz funktioniert alles. Ich habe letztlich die Belegung nach T586-A gewählt, weil die auf dem Patch-Panel aufgedruckt ist (gegenüber B-Belegung werden ja nur zwei Adernpaare vertauscht). Das ist kein Problem, weil es sich nur um ein Hausnetz handelt, das einheitlich installiert wird.


    Ich habe aber noch Folgendes herausgefunden: Die Hersteller von meinen Dosen und meinem Patch-Panel haben die Aufspreizung des dritten Adernpaars auf Pins 3, 6 offenbar berücksichtigt und wohl diese Adern "intern" so "verdreht", dass die Reihenfolge der Pins auf der Buchsenseite (1 bis 8) nicht der Reihenfolge auf der Klemmenseite entspricht (1, 2, 3, 6, 4, 5, 7, 8). Es gibt in der Dose ganz kleine Aufdrucke auf der Platine hinter den Klemmen (aber auch nur da). Es findet also eine Aufspreizung statt, aber die Adern liegen auf Klemmenseite trotzdem nebeneinander. Das ist gut, aber am Anfang verwirrend.


    Für Anfänger wie mich ergibt das folgendes Fazit: Am besten man beachtet die Farbcodierungen der Hersteller. Man sollte sich an Teile halten, die gut beschriftet und/oder dokumentiert sind. Aber man sollte es nicht so machen wie ich und möglichst Dosen und Patch-Panel vom gleichen Hersteller nehmen, weil die im Zweifel gleich belegt werden und gleich beschriftet sind.


    Al

    Zitat

    Original von lola
    Also nach meinen Erkenntnissen sollte man die Twisted Pair also die verdrillten Aderpaare nicht aufheben. ... Ich würde also 3/6 für ein Paar nehmen.


    Aha. Auch die Profis (lola und acid70) würden also nach dem EIA/TIA-Standard belegen. Anstatt alle Paare brav "nebeneinander" zu legen (wie der Dosenhersteller vorgibt), ist es also besser, ein Adernpaar (egal welcher Farbe, z.B. weiß-grün / grün nach EIA/TIA-568-B) auf 3 und 6 zu legen. Und das, obwohl ja dadurch dieses "gespreizte" Adernpaar an den Enden etwas weiter "entdrillt" werden muss, ja?


    Danke jedenfalls an alle.
    Al

    Danke für die Links. Aber genau von solchen wunderbar gemachten Seiten rührt mein Problem her, SiRo und tueftler17. Denn die Hersteller von meinen Dosen (Rutenbeck) und meinem Patch-Panel (Telegärtner) machen es jeweils anders. Und da die sich ja auch was gedacht haben, kostet es einige Überwindung, sich vierundzwanzig Mal über diese Vorgaben hinwegzusetzen (weil ich nämlich 12 Kabel anzuschließen habe).


    Al

    Etwas off-topic, aber vielleicht kann trotzdem einer helfen:


    Ich habe Cat.7-Kabel im Haus liegen. Das Ganze soll zukunftssicher sein für Gigabit-Ethernet, auch wenn der jetzige Switch und die Netzwerkkarten nur 100-BaseT können. (Das Ganze dient unter anderem dazu, die Daten von meinem VDR auf den Windows-PC und die MediaMVP zu verteilen.) Ich bin dabei, Cat.6-Dosen einzubauen und die Kabel auf ein Patch-Panel zu legen. Ich komme aber mit den Anschlussbelegungen nicht klar. Der Standard EIA/TIA-568-B sieht eine andere Farbreihenfolge vor als die Farbcodierung in der Dose, und die weicht wiederum ab von der Farbcodierung auf dem Patch-Panel (Cat.6, aber anderer Hersteller).


    Der Farbcode nach EIA/TIA-568-B besagt nach allen verfügbaren Infos, dass das Adernpaar 1 (blau / weiß-blau) "innen" auf die Klemmen 4 und 5 gelegt wird und das Adernpaar 3 (weiß-grün / grün) "darüber" gespreizt wird auf die Klemmen 3 und 6, also so:
    1 - weiß-orange
    2 - orange
    3 - weiß-grün
    4 - blau
    5 - weiß-blau
    6 - grün
    7 - weiß-braun
    8 - braun


    Die Installationsanleitung zu den Dosen und die dortige Farbcodierung (für Anschlussbelegung nach Standard "B", also nicht etwa EIA -568-A)sieht im Gegensatz dazu vor, dass das Adernpaar 3 (weiß-grün / grün) nebeneinander auf die Klemmen 3 und 4 gelegt wird. Adernpaar 1 (weiß-blau / blau) rückt dafür auf Klemmen 5 und 6, d.h. blau und grün sind getauscht, also so:
    1 - weiß-orange
    2 - orange
    3 - weiß-grün
    4 - grün
    5 - weiß-blau
    6 - blau
    7 - weiß-braun
    8 - braun


    Die Hersteller-Hotline von Fa. Rutenbeck sagt dazu nur, man wolle damit erreichen, dass die Adernpaar möglichst lange nebeneinander geführt werden, um Störungen vorzubeugen. Ich müsse nur darauf achten, dass die Klemmen auf dem Patch-Panel in der gleichen Farbreihenfolge belegt werden.


    Das Patch-Panel hat - wie gesagt - nochmal eine andere Farbcodierung.


    Ich frage mich, ob denn die Netzwerkgeräte klarkommen, wenn ich der Herstelleranweisung folge und das Adernpaar 3, 6 sowohl in der Dose als auch auf dem Patch-Panel nebeneinander lege statt es zu spreizen. Ich habe mir bisher keinen Kabeltester geleistet, und da ich mit dem 100-BaseT-Netz nur 4 Adern nutze, kann ich vorläufig selbst durch trial & error gar nicht herausfinden, ob alle Adern richtig angeschlossen sind. Weiß jemand, ob es z.B. dem Switch wichtig ist, dass die Adern auf den Klemmen 3 und 6 zum gleichen Adernpaar gehören (was bei der Installation nach dem Standard der Fall ist, aber nicht bei der Installation nach meiner Hersteller-Anweisung)?


    Äh, kürzer konnte ich das leider nicht loswerden ...


    Danke im voraus.
    Al

    Hallo beagle,


    vielen Dank für die Mühe. Mir hat das für mein Windows 2000-System wenigstens was gebracht, weil ich schleunigst den EnableBigLba-Schlüssel in der Registry erzeugt habe. Als die c't 9/04 'rauskam, hatte ich noch eine kleinere Platte drin. Mit dem Ausprobieren unter Linux muss ich warten, bis ich die Daten anderweitig versorgt habe.


    Al

    Äh, zu langsam geantwortet. Meine obige Antwort bezog sich auf den Beitrag von skvn.


    beagle
    Danke, beruhigende Auskunft. Ich habe linvdr 0.7 so eingerichtet, dass von einer 1GB-Partition am Anfang der Platte gebootet wird. Die restlichen 159 GB (/dev/hda5) sind als /video1 gemountet und werden vom VDR mitverwaltet.


    Al

    Das dachte ich auch mal. Das würde aber auch für die aktuellen Windows-Versionen Win2000 und WinXP gelten, denn die können auch große Platten adressieren. Trotzdem hat bei mir Win2000 mehrmals die FAT überschrieben, sobald der Schreibzugriff in einen der "hinteren" Plattenbereiche erfolgt ist.


    Rein physikalisch muss die Adresse ja über den IDE-Controller an die Platte weitergereicht werden. Wenn der aber nur 40 Bit-Adressen kann statt der nötigen 48 Bit, dann nützt auch ein intelligentes OS wie Linux nichts, oder? (Die Frage ist für mich auch deswegen aktuell, wei ich in dem aktuellen VDR-Rechner, vgl. Sig., auch eine 160GB-Platte an einem Rechner mit "altem", nicht updatefähigem BIOS betreibe und nicht warten möchte, bis alle Aufnahmen futsch sind.)

    M. Keller hat im VDR-Wiki hier vorgeschlagen, einen IBM PC 300 PL als VDR einzusetzen. Dazu habe ich zwei Fragen:


    1. Gibt es bei einer so alten Hardware, dazu mit einem BIOS von 1998, nicht ein Problem mit dem IDE-Controller? Ich gehe mal davon aus, dass der Controller die Festplatte allenfalls bis 128 GB adressieren kann und die 160GB-Festplatte im Bios daher mit 137 GB oder so erkannt wird. Ich selber hatte mit einem Epox-Motherboard aus dem Jahr 2000 die letzten Tage das Problem, dass ab einem gewissen "Füllstand" die FAT überschrieben wurde und die Partitionen "futsch" waren (unter Windows). Hat jemand Erfahrung, ob diese Hardwarekombination auch noch mit voller Platte funktioniert? (Ja, ich habe hier im Forum schon diverse Beiträge dazu gelesen einschließlich der Glaubens-Diskussion von HJS, arghgra u.a. dazu; entscheidend ist doch aber, was in der Praxis funktioniert). Oder braucht man dazu zwingend einen gesonderten IDE-Controller (wie Promise Ultra 100 TX2 o.ä.), der wiederum einen PCI-Steckplatz verbraucht?


    2. Bei Ebay finde ich keinen IBM PC 300PL, sondern nur "300GL". Weiß jemand den Unterschied? Die IBM-Supportseiten sind absolut mies und helfen nicht weiter.


    Vielen Dank.
    Al

    Hallo Klausi,


    entweder Du kopierst die Datei klassisch per Diskette (Fußgänger) oder etwas moderner per USB-Stick (Fahrrad) oder eben per Netzwerkkabel (Motorrad). Netzwerkkonfiguration und Samba für den Zugriff vom Windows-Rechner ist in LinVDR eingebaut und über's Setup zugänglich. Wie Du Floppy oder USB-Stick an's Laufen kriegst ("mountest") weisst Du, ja?


    Al

    Oha, jetzt isses wohl raus. Nein, von dem Patch wusste ich bisher nichts. Danke für den Hinweis, SDU.


    Das bedeutet ja, der vdr muss gepatcht und neu übersetzt werden. Also ist an dieser Stelle LinVDR zu Ende? Ich kann's nicht fassen, dass alle mit zwei TV-Karten und nur einem SAT-Kabel im Wohnzimmer LinVDR gar nicht benutzen (können).


    Na prima! Und dabei war ich als Linux-Grundschüler froh, mit LinVDR mal was gefunden zu haben, was ohne langes Herumprobieren funktioniert. (Mit dem c't-vdr hatte ich nämlich schon bei der Installation Schwierigkeiten.) Und dabei hätte ich beim Neubau letztes Jahr (also vor meinen VDR-Ambitionen) ohne weiteres zwei SAT-Kabel ins Wohnzimmer legen können! Vielleicht bleibt die 2. TV-Karte dann doch lieber in einem anderen Rechner im Arbeitszimmer, am eigenen LNB.

    Wie oben beschrieben ist die erste Karte eine FF-Karte (Technotrend 1.3), die zweite eine Budget-Karte (Skystar2). Die TT hängt am LNB, die Skystar2 hängt am IF Out der TT (durchgeschleifter Anschluss). Tauschen kann ich daher nicht.


    Jetzt sagt bloss nicht, die TT "siebt" das Bouquet des Transportstreams und bei der Skystar kommt nur ein Teil an! Wenn der VDR mit nur einer Karte (TT) am durchgeschleiften Anschluss des normalen digitalen Sat-Receivers hängt, habe ich ja auch kein Problem.


    Der VDR ist der VDR 1.3.17 aus LinVDR 0.7 (unverändert).


    Al

    beagle
    Der logread-Auszug steht in meinem anderen Thread (siehe Hyperlink oben). Dass die Skystar für sich genommen funktioniert weiss ich aus dem Einsatz in zwei anderen Rechnern (unter Windows und unter LinVDR 0.7). Hin- und Hertauschen und messen probiere ich heute abend mal aus.


    Ulf
    Ich nutze die unveränderte LinVDR 0.7. Laut Beschreibung auf linvdr.org sind das die "DVB-Treiber dvb-kernel CVS2004-12-03".


    Al

    Ich habe nach wie vor das Problem, dass in meinem Siemens Scovery 250 LinVDR mit einer DVB-Karte (Technotrend FF 1.3) richtig funktioniert, aber keine Aufnahmen mehr macht, wenn ich eine Skystar2 zusätzlich drin habe ("device 2 has no lock", vgl. anderer Thread hier). Jetzt kommt mir der Verdacht, dass es an der der Stromversorgung liegen könnte. Kann es sein, dass das System als solches läuft, aber dann anfängt zu spinnen, wenn man aufnehmen will? Hat da jemand Erfahrung?


    Der nette kleine Rechner hat ein nettes kleines und schön leises Netzteil (AcBel API-6117L), das nach meiner Internet-Recherche aber nur 75 Watt leistet. Wenn ich mal überschlage (lauter Annahmen): Mini-ATX-Mainboard (10 Watt?), PII-400 (20 Watt?), Samsung SV1604-N (15 Watt?), Technotrend FF 1.3 (20 Watt?), dann bleiben für die Skystar 2.6C rechnerisch und als Dauerleistung nur noch 10 Watt. Das dürfte sehr knapp sein und würde erklären, warum eine Karte geht, die zweite nicht. Nachmessen konnte ich die Stromaufnahme allerdings noch nicht.


    Al

    Probier' ich gern mal aus. Aber verlegene Frage: Wie stelle ich einen Sender fix auf die 2. Karte ein?


    (Seltsam ist, dass die beiden Karten je für sich funktionieren. Sie sind in anderen Rechnern problemlos gelaufen.)


    IcyA1

    Beim Versuch, linvdr 0.7 auf einem Siemens Scovery 250 (mit Siemens-Board, Bios von 1999) zum Laufen zu bringen mit einer Technotrend FF 1.3 und einer Skystar2.6C , kriege ich keine Aufnahmen, sondern obige Fehlermeldung. Die Verzeichnisse für die jeweilige Aufzeichnung werden angelegt, die jeweilige 001.vdr ist aber leer. Fernsehen und sonst alles scheint zu gehen. In einem noch älteren Rechner (HP Pentium I-166, mit 30GB-Platte) funktionierte alles einschließlich Aufnahmen mit einer DBV-Karte. Was ist jetzt falsch?


    Erst dachte ich, das System kommt mit der 160GB-Platte nicht klar. Bios und IDE-Controller sind überfordert, und daher konnte Grub erst nicht booten (mit 32GB-Clip-Jumper ging's natürlich). Daher habe ich in eine primäre 1GB-Partition installiert und den Rest der Platte nach /video1 gemountet. Das scheint o.k. zu sein.
    hdparm -tT /dev/hda gibt:

    Code
    /dev/hda:
     Timing buffer-cache reads:   128 MB in  1.18 seconds =108.86 MB/sec
     Timing buffered disk reads:  64 MB in  3.07 seconds = 20.88 MB/sec


    Mit hdparm /dev/hda sieht's so aus:


    cat /proc/interrupts sagt:


    Logread sagt Folgendes (gekürzt):


    Ich bin dankbar für jeden Tipp, nachdem mich langes "Suchen" nicht weitergebracht hat.


    Al

    Zitat

    Probiers mal mit:
    apt-get remove vdr-addon-screenshot


    Könnte es vielleicht auch


    apt-get remove vdr-plugin-screenshot heissen?


    Im VDR-Wiki ist screenshot unter den Plugins aufgeführt, und ich meine, bei der Installation ist das auch unter den anderen Plugins abgefragt worden?


    Jedenfalls danke für den Tipp, wird heute abend sofort getestet.


    Al