Re: [eug-lug]grip problem
IIRC, ripped files are .wav, then encoded ones are .mp3 (or .ogg, etc) You can try running grip from the CLI, instead of the GUI, so that you see its stdout and stderr on your command line... that might help. Also make sure grip is running as a user which has permissions to write where you want (ie, is ~/mp3/ a symlink or owned by another user?). get a grip ;^)) Ben PS - sorry I'm away from my usual gripping box right now, or I'd pass along my file format for ya... On Tue, 30 Dec 2003 17:47:28 -0800 Dirk Ouellette <[EMAIL PROTECTED]> wrote: | t working for me after I changed the Rip File Format. It is | now set as ~/mp3/%A/%d/%n.mp3 and it begins to rip and encode then just | stops as though I hit Abort Rip & Encode. What should the Rip file | format be, or is that not the likely problem. Grip 3.0.7 on Fedora | Yarrow. | Dirk ___ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
[eug-lug]grip problem
Grip is not working for me after I changed the Rip File Format. It is now set as ~/mp3/%A/%d/%n.mp3 and it begins to rip and encode then just stops as though I hit Abort Rip & Encode. What should the Rip file format be, or is that not the likely problem. Grip 3.0.7 on Fedora Yarrow. Dirk ___ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
Re: [eug-lug]getting dumped
In somewhat-related news, I just found this project via freshmeat: http://freshmeat.net/projects/rsnapshot/?branch_id=43437&release_id=146249&topic_id=19%2C137%2C861 About: rsnapshot is a filesystem snapshot utility based on rsync. It makes it easy to make periodic snapshots of local machines, and remote machines over ssh. It uses hard links whenever possible, to greatly reduce the disk space required. Homepage: http://www.rsnapshot.org/ HOWTO: http://www.rsnapshot.org/howto.html IMHO: rsync is a good tool for this, since you can do an initial backup, then get incremental changes far more quickly via rsync's magic. ...'rsnapshot' uses ssh, and is written in perl. ciao, Ben On Tue, 30 Dec 2003 02:50:36 -0800 (PST) Horst <[EMAIL PROTECTED]> wrote: | Quoting: | """ | From: Hal Pomeranz | Date: Mon, 29 Dec 2003 18:25:29 -0800 | ... | Frankly, using GNU tar is probably a better option precisely because | it doesn't have this particular issue (tar is a "file at a time" | archiver, and is therefore relatively resistant to file system changes | during the archive process). And GNU tar can deal with various | "weird" files (sparse files, device files, etc.) that other versions | of tar tend to have trouble with. | """ | | I also like the above aspects of GNU tar. The only thing I found it | doesn't like is tar'ing /proc/ (what's the point, anyhow?) and some stuff | in /var/ that constantly changes. But for that I either use the -T option | to select, or -X option to exclude. | | As for the single user mode: frankly, if there are frequent insert | requests from httpd to /var/lib/mysql/someWebDB I wouldn't trust any | binary 'snapshot' of an unflushed DB and use the utility that comes with | the DB engine, like mysqldump; maybe I'm just paranoid, but the idea of | 'better safe than sorry' is worth that little extra time; it's scripted | anyhow. | | - Horst ___ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
Re: [eug-lug]getting dumped
Quoting: """ From: Hal Pomeranz Date: Mon, 29 Dec 2003 18:25:29 -0800 ... Frankly, using GNU tar is probably a better option precisely because it doesn't have this particular issue (tar is a "file at a time" archiver, and is therefore relatively resistant to file system changes during the archive process). And GNU tar can deal with various "weird" files (sparse files, device files, etc.) that other versions of tar tend to have trouble with. """ I also like the above aspects of GNU tar. The only thing I found it doesn't like is tar'ing /proc/ (what's the point, anyhow?) and some stuff in /var/ that constantly changes. But for that I either use the -T option to select, or -X option to exclude. As for the single user mode: frankly, if there are frequent insert requests from httpd to /var/lib/mysql/someWebDB I wouldn't trust any binary 'snapshot' of an unflushed DB and use the utility that comes with the DB engine, like mysqldump; maybe I'm just paranoid, but the idea of 'better safe than sorry' is worth that little extra time; it's scripted anyhow. - Horst ___ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
[eug-lug]dd / partition table / and restore on different device // EuG-LUG Digest, Vol 9, Issue 35
--- Bob Miller <[EMAIL PROTECTED]> wrote: > Larry Price wrote: > > This is kind of a borderline question; > > A disk was intentionally zero'd out using > > dd if=/dev/zero of=/dev/hda > > however the DOS fdisk utility couldn't rebuild the partition > table > > afterwards. This is shifting the subject a bit, but worth knowing: When I do: dd bs=100k count=1 if=/dev/hda of=hda_100k.dd dd bs=100k count=1 if=/dev/hda1 of=hda1_100k.dd (same for hdb and hdb1) and then use mc in hex mode to look at the four .dd files. I find that the hdX and hdX1 match at an offset of 7E00 hex (both drives are of different size and geometry) I see LILO in the MBR 0-1FF, then a few bits and lots of zeros in the range up to 7E00 hex. Q1: is the stuff after the MBR and below 7E00 hex the partition table ? Q2: if I'd just have a dd dump of some partition hdXN (like hdb1) how useful would this be if I try to restore it to another device? (assuming that one has enough space) Or in other words, is the stuff below 7E00 just 'metadata' concerning the organization of the drive as a whole with no relationship to the data that are on the individual partitions? In the past I have only used dd in the context of same_device <-> file transfer, but never across devices. Currently I have not enough room to test this in a safe way. Any feedback ? ... Horst ___ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
