On Monday 09 May 2005 05:08, Tom wrote: > > An all the time, I thought sharing by torrent was supposed to > check as the d/l progresses (the tracker ?) > The downloaded file did match the md5sum, so any problem must be in the burn.
> OK, it occurs to me now I can't remember back to 2.6.8. Mea > culpa. I vaguely remember Linus mandated increased security startin > with 2.6.9 Actually he suggested it for all 2.6, but it didn't > happen till late 2.6.8 or 2.6.9 Many distros, not just Mandrake > injected work arounds... but no longer. Be assurred that 2.6.9 or > later Mandriva kernels' comply to no more user space access in areas > like cd burning (the rr-scheduler and setpriority). Actually CAE > probly knows the particulars better than me. I sort'a think LSB was > involved to coerce kernel.org dictates. I have no idea if any GUI > frontends reflect this change. You know I don't use 'em ;) > I'll have to look into that, for future use. > > I don't understand that one, Tom. I presume -atip is a switch - on which > > command? > > We've had this conversation before ;) Sorry, but I have a *really* good excuse ;-) I always intended getting all the cli info that I collect into text files, but one way and another I fall behind, so I have habitually saved and marked important emails that have info useful to me. Until recently this worked well, because kmail could search across all folders with multiple search criteria, so I usually found the message I was looking for. When I changed to imap I lost that facility. Now, I dip around a bit, and if I can't find it I have to go to the server, open the most likely mbox file in a text editor, use 'find' on one term at a time, and repeat across as many boxes as necessary until I find what I was looking for. Not only is it time-consuming, but I often don't find it, even though I know I saved something. > There's _many_ more > brand names for media, than are are manufacturers. It's not unusal > in a 100 spindle from one "brand", to find the disks come from > different vendors. For example, I've been usin a lot of "Memorex" > blanks lately. The actual manufacturers (Memorex doesn't make any) > have been Ritek, CMC Magnetics, Prodisc, and even a few from a > non-Orange Forum Indian outfit. I forget the name. Non-Orange means > they don't pay to subscribe an be compliant to CD industry specs. > It also produced one'a my rare coasters, failed to fixate properly. > > -atip is a cdrecord switch to find out who really made the > media. With a blank in the burner (as an example, this is from a > "Memorex"); > > tom # cdrecord dev=ATA:1,1,0 -atip > Cdrecord-Clone 2.01.01a01-dvd (i686-pc-linux-gnu) Copyright (C) > 1995-2004 J�rg Schilling > > << big snip>> > > ATIP info from disk: > Indicated writing power: 4 > Is not unrestricted > Is not erasable > Disk sub type: Medium Type A, low Beta category (A-) (2) > ATIP start of lead in: -12508 (97:15/17) > ATIP start of lead out: 359845 (79:59/70) > Disk type: Short strategy type (Phthalocyanine or similar) > Manuf. index: 22 > Manufacturer: Ritek Co. > ^^^^^^^^^^^^^^^^^^^^^^^ > OK. Since you also asked about the hardware, I've left that bit in: Vendor_info : 'LITE-ON ' Identifikation : 'DVDRW LDW-451S ' Revision : 'GSB6' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE FORCESPEED Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11634 (97:26/66) ATIP start of lead out: 359846 (79:59/71) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation It does seem odd that it doesn't mention DAO - is that normal? > That was one'a the last few disks on a 100/spindle. One sampled > from about the first twenty on the spindle reported that CMC > Magnetics made it. I burn about 100 cd's a month. > I've had very few coasters in the 3 years since I switched to linux, and before this drive I was using a very old burner. The batch of disks I mentioned in our last conversation about this is the only one where I've had real problems, so I assume they were from a sub-standard batch to start with. It can happen, in any manufacturing base. > > >>and if a simple 'cdrecord -v -eject speed=4 dev=ATA:X,Y,Z -dao > >>xxxxxx.iso', still produces an uncheckable md5sum CDr. > So my X,Y,Z is 1,1,0 for my Plextor. From reading, an in my > experience it's better to use dev=ATA:X,Y,Z than to use the pointer > to it, dev=/dev/hdX when burning. I only use /dev/hdX when > checking the md5sum in my DVDrom (cheap teac). When the md5sum > checks in that cdrom, an it always does, I'm confident enough to > send'em overseas to some friends that duplicate 'em an share. > I'll bear that in mind, but as I said, I've had very few bad burns. > BTW, you should also check to see if your burner has a bios > update available. My Plex was 1.02. Flash from a lvl 3 prompt > updated it to 1.05 Current firmware can also be a factor in > burning an reading, hence checkin md5sums also. OK - thanks for that advice also. I'll try the cli record now and let you know what happens. Anne -- Registered Linux User No.293302 (http://counter.li.org/) Have you visited http://twiki.mdklinuxfaq.org yet? Mandrake at all levels
pgpToPtnx0PPx.pgp
Description: PGP signature
