Beiträge von Brian Cohen

Servus,

da bist Du aber 'nen schönen (DOS und ähnlichen Unsinn) Irrtum aufgesessen.
Es gibt 2 Zeiten: die RealTimeClock (RTC), sprich interne batteriegebufferte Uhr
und die Systemzeit: bei allen mir bekannten Unicen o.ä., die verflossene Zeit in Sekunden seit 01.01.1970 00:00:00 Uhr.
Hab mal für Dich gegoogelt und das gefunden.

Servus,

Zitat

Original von e.b
hallo,
das hat meine Frage bezweckt, eine Empfehlung / Ratschlag zu bekommen.

cu -- e.b

na dann stelle doch die Frage auch so! Das Problem bei eine Fragestellung nach dem Besten etc. ist, daß man(n) oder frau ganz schnell einen flamewar lostreten kann, der niemanden nützt.
Nun meine Empfehlung: Du kennst Mandrake? Gut, nimm Mandrake.
Du kennst RH, gut nimm RH (jetzt Fedora) usw.usf.
Du kennst jemanden, der den VDR mit xyz nutzt? Gut, dann nimm xyz.
Du willst schnelle Erfolge? Gut, dann nimm z.B. LinVDR oder die ct.
Klar, worauf ich hinaus will, teste doch mal ein paar Sachen, lies immer die passenden, einschlägigen Foren durch und entscheide Dich dann. Für Fragen gibt es ja dann immer noch die docs, Google und das Forum (in der Reihenfolge). Und wenn Du für das /video Verzeichnis eine eigene Partition einrichtest, kannst Du Dein Aufnahmen auch über eine Neuinstallation retten.

Servus alle miteinander,

die Frage (welche ist Beste) ist völlig falsch gestellt. Es gibt keine Beste! Es gibt vielleicht eine Beste für Deine Bedürfnisse und dein Skill-Level. Das ist wie mit den Frauen, der eine bevorzugt welche mit großem Vorherz, der andere mag nur eine mundvoll.
Und für alle weiblichen Forumsmitglieder: Die eine steht auf den Macho, die andere auf einen Softie (kenne mich da aber nicht so aus)
Summa summarum, die Frage muß jeder für sich selbst beantworten und jede Empfehlung hier kann nur eine individuelle Meinung oder ein individueller Vorschlag sein.

Servus,

Phillips RC5, Probiere mal den Code 336

Servus, meine Zeile sieht so aus:
deb ftp://ftp.nerim.net/debian-marillat stable main

und die funktioniert tadellos.
Hast Du die sources.list mal irgendwie mit Windowskram bearbeitet??
Lösche mal hinter dem letzten sichtbaren Zeichen alles weitere und füge (wichtig) noch als letztes ein Return ein.

Servus,

zu 1. geht,

man mount

grobe Kurzfassung: mounte mit welchen Dateisystem welches Device auf welches Verzeichnis z.B. mount -treiserfs /dev/hda3 /mnt, wobei Verzeichnis existieren muß!. Und irgendwelche Dateisysteme unter /dev zu mounten, ist mal vorsichtig ausgedrückt 'ne saudumme Idee. Dafür gibt es doch das /mnt und es gibt auch 'nen Standard, genannt FHS<--hier klicken

Zitat

Original von Ottel
So das ist meine etc/apt/sources.list .
...
deb ftp://ftp.nerim.net/debian-marillat/ stable main

Servus,

dann laß mal spaßeshalber den letzten "/" hinter debian-marillat wech..

Ciao

Servus,

Dir und allen anderen, mit ähnlichen Problemen, kann geholfen werden.
Schaust Du hier oder hier.

Ciao

Servus,

fstab oder mount.sh

Aber ansonsten den Anweisungen, wie mein Vorredner Robsta schon sagte von Mr. Sandmann folgen (Abschnitt mp3).

Servus,

Du brauchst ja keine Aufnahmen verschieben, sondern nur das Verzeichnis umbenennen, so bleiben erst einmal alle Aufnahmen erhalten.
Mit einem Standardkernel, wo die gängigsten Treiber einkompiliert sind, sollte ein Umhängen auf ein neues Board eigentlich funktionieren. Muß man aber am konkreten Beispiel ausprobieren. Wichtig sind die Einstellungen im BIOS für die Platten: Adressierung Auto ist manchmal nicht die erste Wahl. Dort sollte man bei Problemen auch mal LBA oder CHS ausprobieren.

Und noch ein Ansatz (aber dann wird es eng)
Was sind denn alles für Patche installiert? Besonders interessiert mich die Farbtiefe Deines OSDs. Kannst Du mit

grep -i "define maxnumcolors"  <vdr-sources>osdbase.h

ermitteln.

Es schaut so aus , als würdest Du
[list=1]
[*]einen neueren Kernel (Sourcen) oder
[*]den V4L2 Patch brauchen
[/list=1]
Immer erst das README lesen, dann googlen und dann posten

Servus,

die CPU-Belastung ist zu gering, als das sie eine Rolle spielen würde. Ist bei mir sogar geringfügig höher, so etwa 10 %. Also weiter.
Ich vermute einmal, das in Deinem Wurzelverzeichnis /video0 existiert.
Da ist Die leider ein kleiner Designfehler unterlaufen. Ich hätte hda folgendermaßen partitioniert:

hda1 ca. RAM*2(Faustformel, kein Dogma) als swap (schnellster Plattenbereich für Performance)
hda2 ca. 64MB als /boot (stammt noch aus Zeiten der 1023Sektoren-Grenze, hat sich aber bewährt)
hda3 ca. 2GB (standalone vdr) - 30 GB (System für "Erwachsene") als /
hda4 den Rest als /video bzw. /video0

Tu mir mal den Gefallen, lege ein Verzeichnis /video an und mounte /dev/hdc auf dieses Verzeichnis. Benenne /video0 in irgendetwas um und kopier alle Daten, die der vdr braucht in das /video Verzeichnis. Sinn und Zweck der Übung ist es den vdr ausschließlich von /dev/hdc also aus dem Verzeichnis /video laufen zu lassen. Teste die Performance. Und immer daran denken, nix löschen, Daten sind Dein Betriebskapital. Mache zur Not ein Backup aller wichtigen Daten!

Servus,

Zitat

I2C is a bi-directional two wire bus that was developed by Philips for use in their televisions in the 1980s. Today, I2C is used in all types of embedded systems.

Besser kann ich es auch nicht formulieren, I2C wird hauptsächlich für die Hardwareüberwachung/-steuerung verwendet.

Mit den Sourcen machst Du genau das, was ich vorhin geschrieben habe:

cd /usr/src
bzip2 -cd dvb-driver.tar.bz2 | tar xvvf -

Für alle anderen Treiber äquivalent vorgehen.

cd /usr/src/linux
make-kpgk <Optionen> binary|kernel_image modules_image

Falls die Kernelquellen bereits übersetzt sind reicht auch ein

make-kpkg <Optionen> modules_image

That's the Debian-Way!

Die <Optionen> müssen identisch sein und /usr/src/linux ist ein symbolischer Link auf die aktuellen Kernelquellen.

Servus,

das kommt immer darauf an, was Dir denn Dein Kabelbetreiber anbietet. Ausschließlich analoge Kanäle oder auch digitale? Frage einfach mal bei Deinem Betreiber höflich nach.

Servus,

könntest Du vielleicht auch noch die Ausgabe von mount posten?

PS: Und warum machst Du soviele Threads zum eigentlich gleichen Thema auf?

Servus,

probieren wir mal 'nen anderen Ansatz, obwohl ich Deinen Datendurchsatz wirklich für etwas mies halte.
Was sagt den top bei Leerlauf und gestartetem Schnitt? Und wieviele 100.000e Aufnahmen befinden sich im /video Verzeichnis? Ganz wichtig: Ist das /video Verzeichnis eine separate Partition und/oder befinden sich dort auch andere Dateien (umfangreiche mp3-Sammlungen etc. pp.), oder gar das Wurzelverzeichnis. Der vdr verwendet IMHO nur einen find - Algorithmus, der bei vielen kleinen Dateien im video Verzeichnis dann natürlich bald einschläft, erst recht, wenn auf das Dateisystem zugegriffen wird. Aber ich glaube dafür gibt es dann den famd-Patch. Beim ähnlich gelagerten find-Patch wollte der vdr, die als zu löschend markierten Dateien nicht mehr wirklich löschen. Ist das vielleicht mittlerweile behoben?

Zitat

Original von baltasar

1. Alle hdparm Optionen können insbesondere bei älteren Boards/Controllern zu übertragungsfehlern und sogar stehenden System führen. Also vorsichtig testen.

OK. Zugegeben, aber wir sprechen hier von einem mir als sehr robust bekannten BX-Chipsatz und nicht von dem leidigen Via KT133. Optionen, die der Chipsatz/das Device nicht verarbeiten können, produzieren Fehlerausgaben. Die einzige Optionen, die IMHO etwas problematisch ist, ist -u1. Man sollte hdparm immer erst temporär testen, bevor man die Optionen dauerhaft speichert. Habe ich wahrscheinlich nicht deutlich genug klar gemacht. Asche auf mein Haupt.

Zitat

2. Einfach jemanden für etwas ( IMHO sehr wenig ) Performance zu raten das Journal abzuschalten, finde ich etwa fragwürdig. Das Filesystem wird dabei auf jeden fall anfälliger.

Diese Aussage ist aber definitiv falsch. ext3 ist nix anderes als ext2 mit dazuprogrammierten Journal. Also LinkedLists und nicht B-Tree-basierend. Und das Journal erfordert nun einmal etwas Overhead, der sich auch auf die Leistung schlägt. Im Umkehrschluß legt Deine Aussage aber nahe, daß ext2 anfällig ist und da muß ich aber heftigst protestieren. Ext2 zählt zu den meist getesteten und robustesten Filesystemen überhaupt. Natürlich kann ein standardmäßiger fsck bedeutend länger dauern, als bei einem ext3, aber bei einem forced-Check benutzen beide die gleichen Routinen (ext3 ohne Journal).

Zitat

3. Die KOMBINATION aus beiden Tipps ist schon fast fahrlässig zu nennen. Wenn die hdparm "kitzeleien" den Rechner schrotten kann man ohne journal nur noch hoffen das "fsck" es wieder hinbekommt. Sonst ist auch mal das Video-archive etc. futsch.

Servus,

Prian sagt: Werft den Purschen zu Poden
SCNR

Nein, mit Modulen meine ich Treiber, die den Weg in die offiziellen Kernelquellen (noch) nicht gefunden haben oder schlicht und ergreifend in den Kernelquellen einfach zu alt sind. Darunter zählen eben auch alsa, lirc, i2c, cdfs und last but not least dvb. Diese Pakete finden sich nach einer Installation im /usr/src Verzeichnis als gepackte Archive und müssen noch in das /usr/src/modules Verzeichnis ausgepackt werden. Danach existieren unterhalb von /usr/src/modules Verzeichnisse ala alsa, i2c etc. Diese wieder werden explizit mit make-kpkg modules_image übersetzt und erzeugen pro Modul ein eigenes deb-Paket unter /usr/src. Ich hoffe ich konnte mich jetzt etwas klarer ausdrücken.

PS: make-kpkg <optionen> binary|kernel_image übersetzt eben nur alle Module, die in den (offiziellen) Kernelquellen vorhanden sind.

Servus,

auch hier gilt mal wieder Geiz ist nicht geil. Warum 3 Folgen draufpressen bei Rohlingspreisen (DVD-R bis 4x) von mitunter unter 75 Teuronen für das 100er Pack? Überprüfe mal lieber, wieviele Tonspuren Du denn da hast (ac3:de und mp2:de)? Schmeiß doch dort eine weg.
Faktoren von 1.5 - 1.7 sind noch vertretbar. Alles über 2 sieht man schon recht deutlich. Ich verwende requant aber nur im Notfall und meist mit einem Faktor kleiner 1.25 Das ist aber nur eine persönliche Meinung und kein Dogma.

Servus,

und Schreck laß nach. 8-9 MB klingen ja gar schauderlich nach Steinzeit. Rüste, wenn es denn möglich ist, mal 'n bißchen RAM auf. Und dann kitzle alles aus den Tuningoptionen von hdparm raus (-u1 -m16 -d1 -c3). Drittens entferne, wenn Du denn ext3 benutzt, die Journalfunktion. Beende dazu vdr und vdradmin, danach solltest Du die hoffentlich eigenständige /video Partition unmounten können und mit tune2fs -O^has_journal <device> das Journal entfernen können. Danach ist es ein stinknormales ext2, das definitiv 'nen Tick schneller ist, als ext3.

PS. Hatte ich glatt vergessen: Eine schnellere CPU bringt gar nichts oder besser fast gar nichts, weil ja die Daten im Normalfall im DMA-Modus an der CPU vorbeigeschaufelt werden.