cat beschränken oder Alternative

Errorsmith

Kompiliertier
Hi

Das es für die PVR Karten von Hauppauge (TV Karten mit MPG Encoder Chip) immer noch kein sinnvolles TV Programm gibt, nutze ich im Moment immer noch cat um fern zu sehen und aufzunehmen. Das funktioniert indem ich "cat /dev/cxm0 > /data/datei.mpg" mache und die erzeugte Datei mit (g)mplayer öffne.

Ich suche nun nach einer Möglichkeit den "cat" Befehl auf eine bestimmte Dateigröße zu beschränken, also zum Beispiel festzulegen das er nur 2 oder 4 GByte aufnehmen soll und danach abbricht. Falls dazu ein anderes Programm als "cat" notwendig ist soll mir das auch recht sein.

Sinn der Aktion ist das aufnehmen auf eine FAT32 Partition die sich mein BSD mit einem installierten Windows teilt. Von dort aus möchte ich die Videos dann weiterbearbeiten. Ich will mir ein Script schreiben das die Aufnahme in 3.9GB Blöcke zerlegt so das ich nicht mit dem FAT32 Limit für maximale Dateigröße in Konflikt komme.

Gruß, Errorsmith
 
Die Lösung ist Split:
cat /dev/cxm0 | split -b 4096m - ausgabedate.mpg.

Die Manpage zu Split erleutert näheres.
 
Eine andere Möglichkeit ist es, statt Fat32 zubenutzen, eine ext2 Partition zu nehmen. Darauf kann mit windows und bsd drauf (auch schreibend) zugegriffen werden. Ich mach das so, da ich mit fat32 immer wieder an genau diese Grenze gestossen bin, und auch immer mal wieder das Filesystem defekt war, nachdem ich mit bsd raufgeschrieben habe. Mit ext2 habe ich diese Probleme nicht mehr.
Gruss, Marten
 
Hi

Danke für den Tip mit "split", das werde ich nachher mal ausprobieren.

@marten: Ich wußte garnicht das Windows ext2-Partitionen r/w mounten kann? Wie geht das?

Ich benutze Win2k, das letzte mal als ich das versucht hab mußte ich mit externen Tools darauf zugreifen, konnte nur lesen und stabil war das auch nicht gerade. Hab ich irgendwas verpasst?

Im Gegensatz dazu hatte ich noch nie Probleme mit Fat und BSD, daher nutze ich das ja.

Gruß, Error

/edit: Es funktioniert mit Split! Danke für die Hilfe :)
 
Last edited:
Warum lässt du nicht mplayer direkt aus dem Device lesen und verzichtest auf den Umweg über eine Datei?
 
Hi

Aus mehreren Gründen:

1. Meist nehme ich auf wenn ich nicht am Rechner bin bzw. nicht die ganze Zeit am Rechner bin oder etwas anderes zu tun habe. Mit cat habe ich eine Datei auf dem Rechner die ich auch später ansehen kann.

2. Um während dem Fernsehen "Pause" drücken zu können bzw. Werbung zu überspringen.

3. Weil ich nicht wußte das mplayer vom cxm0 Device lesen kann. Mit dem bktr Treiber geht das, das weiß ich. Das mplayer mit dem cxm0 umgehen kann ist mir neu.

4. Weil ich öfters auch Videodaten von einer Kamera aufnehme und diese dann weiterverarbeite.

Gruß, Errorsmith
 
3. Wenn das Device einfach einen mpeg Stream liefert kannst du mit mplayer daraus lesen, wei aus einer Datei. Einfach mit mplayer file:///dev/cxm0 auf das Device zugreifen.
 
Hi

Hab ich mal ausproiert gerade. Es funktioniert nur bedingt: Das Bild ruckelt "wie Sau" und nach ein paar Sekunden ist der Ton weg. Die Aufnahme in eine Datei scheint auch ne Art Pufferfunktion zu erfüllen. Aber da ich meist die File eh auf der Platte haben möchte ist das auch ok und stellt kein Problem dar. Danke dennoch für die Info :)

Gruß, Error
 
Dem könnte man bestimmt mit irgendeiner form des Caching entgegenwirken. An deiner Stelle würde ich jedoch auf cat verzichten. Das ist nicht binary safe.
 
Hi

cat ist nicht was? Bisher hatte ich keine Probleme damit. Und ich mach das schon seit ca 2 Jahren auf diese Art und Weise...

Gruß Error
 
Die Daten die es ausgibt sind nicht vollkommen identisch mit denen die es erhält. Das haben wir hier herausgefunden als ich auf die Idee kam mit cat Images von CDs zu erstellen. Je nach verwendeter shell macht cat andere Fehler. Jedoch ist es in keiner Shell fehlerfrei. Als alternative würde ich cp oder dd ausprobieren. Oder direkt split mit dem < verwenden.
 
Hi

Ach so. Nun weiss ich was du meinst. Nun, wie gesagt, bisher hatte ich keine Probleme. Das dd hatte ich schon mal getestet, dies hat nicht funktioniert, ich weiß jedoch nicht ob es an dd lag oder ein Bedienungsfehler war. cp habe ich noch nicht probiert, kann ich aber bei Gelegenheit machen. split direkt aus dem Device lesen zu lassen ist auch eine nette Idee, das werde ich später mal antesten.

Gruß, Error
 
Ich denke split wäre für dich die beste Lösung. Bei dd würde ich einfach
# dd < /dev/cxm0 > stream.mpg
probieren.
 
Die Daten die es ausgibt sind nicht vollkommen identisch mit denen die es erhält. Das haben wir hier herausgefunden als ich auf die Idee kam mit cat Images von CDs zu erstellen.
das halte ich fuer ein geruecht. hast du eine beispieldatei, die cat veraendert ausgibt?
 
cat arbeitet zeichenorientiert, dd bitweise. Wenn man nen binaeren Strom mit cat ausliest, kann es also zu Problemen kommen.
 
das halte ich fuer ein geruecht. hast du eine beispieldatei, die cat veraendert ausgibt?
Kein Gerücht, ich hab's Stundenlang mit verschiedenen CDs ausprobiert. Cat liefert reproduzierbar immer das gleiche, falsche Ergebnis. Probier's selbst aus.

# cat /dev/acd0 > image.iso
# md5 < /dev/acd0
# md5 < image.iso

Du wirst sehen, dass sich die Prüfsummen unterscheiden. Außerdem wirst du feststellen, dass in einer anderen Shell image.iso eine andere Prüfsumme haben wird.
 
Kein Gerücht, ich hab's Stundenlang mit verschiedenen CDs ausprobiert. Cat liefert reproduzierbar immer das gleiche, falsche Ergebnis. Probier's selbst aus.

# cat /dev/acd0 > image.iso
# md5 < /dev/acd0
# md5 < image.iso

Du wirst sehen, dass sich die Prüfsummen unterscheiden. Außerdem wirst du feststellen, dass in einer anderen Shell image.iso eine andere Prüfsumme haben wird.
schonmal daran gedacht, dass das am device-treiber fuer acd0 liegen kann, der evtl. feste blockgroessen braucht?

wenn ich eine datei mit cat ausgebe, dann kriege ich 100% auch wieder die datei, egal was da drin steht.

sag eher, dass cat nicht geeignet ist, um von bestimmten devices zu lesen und nicht sowas pauschal falsches wie "Die Daten die es ausgibt sind nicht vollkommen identisch mit denen die es erhält."
 
Woher soll ich die Ursache erkennen. Eindeutig ist lediglich, dass cat nicht in jeder Situation unveränderte Daten liefert.
 
Ich komme zwar aus der Linux-Welt, aber ich kann mir ehrlich gesagt weder vorstellen, dass cat beim Auslesen einen Fehler macht, noch, dass eine MD5-Checksumme in einer anderen Shell anders berechnet wird.

Unter Linux liegt es nur an der Blockgröße. Wenn ich also ein ISO-Image mit cdrecord auf eine CD brenne und zum Zweck der Verifizierung diese CD wieder auslese, um dann die beiden Images zu vergleichen, dann kann es tatsächlich sein, dass die MD5-Checksummen unterschiedlich sind. Aber das liegt nur daran, dass die Dateien unterschiedlich groß sind und nicht daran, dass cat einen Fehler gemacht hat.

Es gibt drei mögliche Lösungen:

1. Verzicht auf md5 und verwendung von cmp: cmp wird nicht sagen, dass die Dateien sich bei Byte x unterscheiden, sondern wird nur sagen, dass eine Datei früher "zuende" gewesen ist als die andere.

2. Verwendung von dd mit der korrekten Blockgröße (die ich nicht auswendig weiss).

3. Brennen des Images im DAO-Modus (cdrecord -dao ...), dann stimmen auch bei Verwendung von cat die MD5-Checksummen.
 
Back
Top