Re: Cdrecord!
Rüdiger Greeb [EMAIL PROTECTED] writes: Joerg Schilling wrote: You are a victim of unplanned changes in the Linux kernel and it may be that you run software that is not used on Linux by default. Is there a plan about Linux changes? I just found a 'final word' about udev vs. devfs that was written almost two years ago. (*) This is not about udev, but more about the handling of ATAPI drives in the kernel. Search for Jörg's name on the LKML if you want to know more. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: c2scan of DVDs??
Thanos Kyritsis [EMAIL PROTECTED] writes: On Wednesday 01 December 2004 01:54, Joerg Schilling wrote: As Plextor is the only company that includes a reliable way to check the errors, Yet, I cannot understand why it is Plextor specifically the only one that includes a reliable way. Plextor first supported it on the 712 model. Other recorder drives support this feature months before Plextor implemented it. That's because tests showed that the Plextor drives are the only ones giving significant results, that correlate with the results given by really professional equipment. Instead of using the LiteOn drives you can also use a random number generator ;-) regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recover DVD written too fast?
Gregoire Favre [EMAIL PROTECTED] writes: What way could I know if my media is low quality? In all cases I think my DVD could go to the thrash, yes? dvd+rw-mediainfo gives me: INQUIRY:[SONY][DVD RW DRU-500A ][2.0h] GET [CURRENT] CONFIGURATION: Mounted Media: 11h, DVD-R Sequential Media ID: VIVASTAR Yes it is bad quality. Try to get original Verbatim (Media ID: MCC..) Ritek aren't bad either or Maxell, Tayo Yuden. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recover DVD written too fast?
Gregoire Favre [EMAIL PROTECTED] writes: What way could I know if my media is low quality? In all cases I think my DVD could go to the thrash, yes? dvd+rw-mediainfo gives me: INQUIRY:[SONY][DVD RW DRU-500A ][2.0h] GET [CURRENT] CONFIGURATION: Mounted Media: 11h, DVD-R Sequential Media ID: VIVASTAR Yes it is bad quality. Try to get original Verbatim (Media ID: MCC..) Ritek aren't bad either or Maxell, Tayo Yuden. regards Markus
Re: Canon EF 80-200 L
Hallo Hendrik! Hendrik Hoeth [EMAIL PROTECTED] writes: Du hattest von etwa zwei Wochen auf drf Dein 80-200/2.8 angeboten. Gibt's das noch, oder ist es schon verkauft? Das ist leider schon weg. In der Newsgroup hatte sich damals aber niemand gemeldet. Servus Markus PS: Sorry, dass ich an diese Adresse schreibe, aber sowohl impressum@ als auch news-2004@ sind zurueckgekommen: local part unknown. Da hat Schlund wohl ein Problem?!? Wohl eher ich. Ich bin mir sicher, dass ich die mal angelegt hatte. Habe ich jetzt nachgeholt. Danke für den Hinweis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canon EF 80-200 L
Markus Plail [EMAIL PROTECTED] writes: Sorry.. that wasn't meant to show up here -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pioneer DVR-106D issues
[EMAIL PROTECTED] writes: Markus Plail [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Just curious, what does CSS have to do with read speed? Some drives limit the reading speed for CSS scrambled discs. For some there are firmware hacks available to cirumvent them. I had always assumed CSS was just a file problem, that is, that the content was scrambled but the disc itself was world-readable. It is. There is no physical reason for limiting the reading speed, but some firmware does it when it recognizes CSS scrambled discs. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pioneer DVR-106D issues
[EMAIL PROTECTED] writes: Markus Plail [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Just curious, what does CSS have to do with read speed? Some drives limit the reading speed for CSS scrambled discs. For some there are firmware hacks available to cirumvent them. I had always assumed CSS was just a file problem, that is, that the content was scrambled but the disc itself was world-readable. It is. There is no physical reason for limiting the reading speed, but some firmware does it when it recognizes CSS scrambled discs. regards Markus
Re: Pioneer DVR-106D issues
[EMAIL PROTECTED] writes: Just curious, what does CSS have to do with read speed? Some drives limit the reading speed for CSS scrambled discs. For some there are firmware hacks available to cirumvent them. regards markus
Re: linux 2.5/6 and cdrecord
[EMAIL PROTECTED] writes: A bit OT. But I received an email from someone who asserted that dev=x,x,x breaks on kernel 2.5, which requires dev=/dev/blaa. Is this by any chance true? Does cdrecord dev=0,0,0 cdrom.iso still work under linux 2.5+? It works if you use ide-scsi. If you don't and use ide-cd instead you have to use dev=/dev/hdX regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux 2.5/6 and cdrecord
[EMAIL PROTECTED] writes: A bit OT. But I received an email from someone who asserted that dev=x,x,x breaks on kernel 2.5, which requires dev=/dev/blaa. Is this by any chance true? Does cdrecord dev=0,0,0 cdrom.iso still work under linux 2.5+? It works if you use ide-scsi. If you don't and use ide-cd instead you have to use dev=/dev/hdX regards Markus
Re: cdrecord starts slow and speeds up later
Gil Disatnik [EMAIL PROTECTED] writes: I have a dvd/cdrw combo on my D600 laptop, when using cdrecord to burn cds the burning process starts at x10 speed, after 168MB it goes up to x16 speed and only after 502MB it finally reaches x24 speed. That's normal behaviour for certain cd writers. It's a question of the write strategy. This one is named Zone-CLV, which means that it writes a constant linear velocity in certain zones (0-168, 168-502, 502-end in your case). There's also CAV which means constant angular, which means that the drive will rotate at the same speed throughout the whole burn process. And thus the writing speed will increase with every written MB. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord starts slow and speeds up later
Gil Disatnik [EMAIL PROTECTED] writes: I have a dvd/cdrw combo on my D600 laptop, when using cdrecord to burn cds the burning process starts at x10 speed, after 168MB it goes up to x16 speed and only after 502MB it finally reaches x24 speed. That's normal behaviour for certain cd writers. It's a question of the write strategy. This one is named Zone-CLV, which means that it writes a constant linear velocity in certain zones (0-168, 168-502, 502-end in your case). There's also CAV which means constant angular, which means that the drive will rotate at the same speed throughout the whole burn process. And thus the writing speed will increase with every written MB. regards Markus
Re: TEAC DV-W50D
Catalin BOIE [EMAIL PROTECTED] writes: I want to buy a TEAC DV-W50D. Do you know any problems with this drive? I think Pioneer's and thus (most of) Teacs DVD writers are fairly well supported. I have the A05 clone from Teac (DV-W50E) and it works just fine. Plase name the Pioneer model number... How can I can get it? Via google search for example. It's the same as the A06. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TEAC DV-W50D
Catalin BOIE [EMAIL PROTECTED] writes: I want to buy a TEAC DV-W50D. Do you know any problems with this drive? I think Pioneer's and thus (most of) Teacs DVD writers are fairly well supported. I have the A05 clone from Teac (DV-W50E) and it works just fine. Plase name the Pioneer model number... How can I can get it? Via google search for example. It's the same as the A06. regards Markus
Re: writeable block device for dvd+rw under 2.6 kernel
On Mon, 3 Nov 2003, Csaba Halasz wrote: Are we talking about the same thing? I need a writeable _block device_. I have _no problems_ using cdrecord or growisofs (w/ poor man's access method). Ah.. sorry. No I meant with cdrecord. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: writeable block device for dvd+rw under 2.6 kernel
On Mon, 3 Nov 2003, Csaba Halasz wrote: If I understand correctly, the use of ide-scsi under 2.6 is deprecated. More or less, yes. However, I am unable to write to /dev/hdx directly under 2.6.0-test8. With what kind of errors? This works with the patched ide-scsi and sr_mod. Patched? With what patches? I have looked into ide-cd.c and I think it only supports writing for dvd-ram. Nope. It works just fine for CD-R and DVD+-R/W. regards Markus
Re: writeable block device for dvd+rw under 2.6 kernel
On Mon, 3 Nov 2003, Csaba Halasz wrote: Are we talking about the same thing? I need a writeable _block device_. I have _no problems_ using cdrecord or growisofs (w/ poor man's access method). Ah.. sorry. No I meant with cdrecord. regards Markus
Re: Cdrecord bug in DAO mode (version 2.01a19)
On Sat, 25 Oct 2003, Rob Bogus wrote: I don't think that's the whole story, honestly. I have been having problems with 2.01a19 and audio as well. This week I have burned 17 data CDs without *any* problem, and using the same media and burner had to try eight times to finally get one single audio CD. The media may not be great, but it works for data, so there is some other issue in place. Yes, I tried both default and the -dao option. System is a 1.4GHz Athlon, Linux 2.4.20 Redhat kernel, ASUS 20x burner. At what speed do you burn the audio CDs? With 2.4 kernels you can't use DMA while burning CDs with sector sizes != 2048. So perhaps the buffer underrun protection is kicking in all the time and it gets too much for the drive/media? You could try at 10-16x. That's about as fast as it can get without DMA. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cdrecord bug in DAO mode (version 2.01a19)
On Sat, 25 Oct 2003, Rob Bogus wrote: I don't think that's the whole story, honestly. I have been having problems with 2.01a19 and audio as well. This week I have burned 17 data CDs without *any* problem, and using the same media and burner had to try eight times to finally get one single audio CD. The media may not be great, but it works for data, so there is some other issue in place. Yes, I tried both default and the -dao option. System is a 1.4GHz Athlon, Linux 2.4.20 Redhat kernel, ASUS 20x burner. At what speed do you burn the audio CDs? With 2.4 kernels you can't use DMA while burning CDs with sector sizes != 2048. So perhaps the buffer underrun protection is kicking in all the time and it gets too much for the drive/media? You could try at 10-16x. That's about as fast as it can get without DMA. regards Markus
Re: DVD in dummy write works, but not real mode? (linux 2.6.0-test7 ide-cd)
On Sun, 12 Oct 2003, Volker Kuhlmann wrote: Cdrecord-ProDVD-Clone 2.01a11 (i586-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling Unlocked features: ProDVD Clone Limited features: This copy of cdrecord is licensed for: private/research/educational_non-commercial_use TOC Type: 1 = CD-ROM scsidev: '/dev/hdc' devname: '/dev/hdc' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. This should be your answer. Not really. Remember cdrecord needs a device specification like dev=X,Y,Z, with X,Y,Z being the SCSI parameters. Not when used with 2.6 kernels in ide-cd mode. The message above just shows that Jörg doesn't like the implementation at all. If you don't run your burner in SCSI-emulation mode, you can access it with some ATAPI but you'll still have to give the device as dev=ATAPI:X,Y,Z. Note the ATAPI is case-sensitive. Use cdrecord(-prodvd) dev=ATAPI: -scanbus to find out what numbers to use. IIRC that's just for some notebook burners. The dev= thing is clear in the man age, the ATAPI: is explained in some remote corner (i.e. some README file). And the dev=/dev/hdX is even more remotely in some announcement. ;-) regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD in dummy write works, but not real mode? (linux 2.6.0-test7 ide-cd)
On Sun, 12 Oct 2003, Volker Kuhlmann wrote: Cdrecord-ProDVD-Clone 2.01a11 (i586-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling Unlocked features: ProDVD Clone Limited features: This copy of cdrecord is licensed for: private/research/educational_non-commercial_use TOC Type: 1 = CD-ROM scsidev: '/dev/hdc' devname: '/dev/hdc' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. This should be your answer. Not really. Remember cdrecord needs a device specification like dev=X,Y,Z, with X,Y,Z being the SCSI parameters. Not when used with 2.6 kernels in ide-cd mode. The message above just shows that Jörg doesn't like the implementation at all. If you don't run your burner in SCSI-emulation mode, you can access it with some ATAPI but you'll still have to give the device as dev=ATAPI:X,Y,Z. Note the ATAPI is case-sensitive. Use cdrecord(-prodvd) dev=ATAPI: -scanbus to find out what numbers to use. IIRC that's just for some notebook burners. The dev= thing is clear in the man age, the ATAPI: is explained in some remote corner (i.e. some README file). And the dev=/dev/hdX is even more remotely in some announcement. ;-) regards Markus
Re: Burning audio disc literally 30x the system load of data disc
On Wed, 20 Aug 2003, Anssi Saari wrote: On Wed, Aug 20, 2003 at 12:17:36AM -0400, Rob Bogus wrote: No, there is a patch to the 2.4 kernel to use DMA when burning audio, at least for some earlier kernels. Where is that patch available then? I am quite sure that there's no such thing. There was one which made it possible to read audio CDs with DMA enabled, but it made quite a few problems and so it wasn't enhanced further or incorporated in the main kernel (neither stable nor unstable). Also 2.6 doesn't really fix the 2.4 problem when burning CDs with sctor sizes != 2048: In 2.6 kernels you have to use ide-cd in order to be able to burn at full speed, which isn't really supported (unintenmtional) by cdrecord and its author doesn't like it at all (to say the least). With regards to ide-scsi 2.6 isn't any better than 2.4, it's even worse (IMHO) and will probably be marked deprecated soon or replaced by libata (Jeff Garzik), which gets AFAIK also support from Jörg. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Matthias Schniedermeyer wrote: On Wed, Jul 16, 2003 at 12:54:03AM +0200, Norbert Preining wrote: I have two questions concerning burning with/without burn-free: The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Norbert Preining wrote: On Mit, 16 Jul 2003, Matthias Schniedermeyer wrote: With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. On Mit, 16 Jul 2003, Markus Plail wrote: That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). Does this mean * 2.6+ can talk to burner in DMA for all block sizes When using dev=/dev/hdX, yes, but Jörg doesn't like that implementation. or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. Yes, exactly. If the later, is there a kernel patch necessary for this? Generally, are there any patches which would increase the throughput? Nope, just compile in support for your chipset. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Joerg Schilling wrote: Let me make an example: A few weeks ago, Jeff Garzik announced a new SCSI interface for ATAPI. http://marc.theaimsgroup.com/?t=10539253612r=3w=2 If you read this thread, you see that Linus obviously does not understand the background and likes the implementation to be better than anything before, before giving Jeff a chance. As it should be obvious that a draft of a new implementation method never is made complete just in order to save time, a knowledgeable programmer would be able to understand whether a new idea could give problems in the future. What you don't tell is, that this implementation is in recent 2.4-ac kernels and thus it has a fair chance of being incorporated in plain 2.4 or 2.6 sometime. Of course you are right that Linus didn't like it. He just has *very* different view on this matter compared to yours. Let's just hope that this thing crawls into mainline. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Anssi Saari wrote: On Wed, Jul 16, 2003 at 10:24:37AM +0200, Markus Plail wrote: or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. Yes, exactly. Why is it then that this problem seems to affect only VIA 686b and Intel ICH4 southbridges? I'll have to admit I only run a 16x burner, but with my current SiS745 based motherboard I have no problems burning anything at 16x, while it was awful with my 686b based motherboard (effective speed 14x and computer totally bogged down during writing). I have no idea. I also didn't have any problems with my SiS735 and an acer2010, but there is simply no code in the kernel to allow DMA so it can't be used. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools update
On Wed, 04 Jun 2003, Andy Polyakov wrote: This is also a mystery... Why do 51s come in pairs... Test this: Great! Not 100% but I could successfully record a DVD and read it afterwards :-) Seems like fixation isn't yet 100% ready. /dev/hdd: FEATURE 21h is not on, engaging DAO... /dev/hdd: reserving 50032 blocks Well, fixation for 100MB DAO recording should take unreasonable time. As far as I understand DAO recordings should be at least 1GB and unit pads it to this limit. Exactly and growisofs seems to wait fro this and the light on my DVD writer is on. cdrecord just exits and the LED is off. This has to be the explaination for both timeouts and fact that drive remains unaccessible [for like 1/4 of hour]. Incremental (which is applicable to virgin [or fully blanked] DVD-RW media) and Restricted Overwrite recording strategies are/should be free from this limitation. With growisofs the disc can be written and it lasts long enough. With cdrecord fixation lasts only 1s, which is way to fast, Elaborate on this. Did you attempted to cdrecord -fix -force or something? Nope, but normally cdrecord doesn't exit before the drive has padded up to 1GB. I will try this again with ide-scsi to make sure I am not wrong. and my writer is completely blocked. Well, it makes sense (to me:-) in 97MB DAO context (see above). Once drive wakes up try to 'dvd+rw-format -force /dev/hdd' and then 'growisofs -Z /dev/hdd ...'. Note that there is new debugging utility, dvd+rw-mediainfo, which you can use to explore DVD structures such as TOC. I will have a look at that and make some more tests. At the moment I am compiling 2.5.70-bk with your latest patch applied. Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c340 Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c350 Could you show me excerpt with mixture of 51s and 50s? Yep: Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c080 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c090 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0a0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0b0 Jun 4 12:12:30 localhost kernel: decode_stat: 51 2a 00c0c0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 5c 00 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0c0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0d0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0e0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c0f0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c100 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c110 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c120 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c130 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c140 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c150 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c160 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c170 [snip] Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c270 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c280 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c290 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2a0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2b0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2c0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2d0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2e0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c2f0 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c300 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c310 Jun 4 12:12:30 localhost kernel: decode_stat: 50 2a 00c320 Jun 4 12:12:30 localhost kernel: decode_stat: 51 2a 00c330 Jun 4 12:12:30 localhost kernel: decode_stat: 50 5c 00 Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c330 Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c340 Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c350 Jun 4 12:12:31 localhost kernel: decode_stat: 50 2a 00c360 Jun 4 12:12:31 localhost kernel: decode_stat: 50 35 00 Jun 4 12:12:32 localhost kernel: decode_stat: 50 0 00 And you probably want to get rid of that debugging printout before you proceed with your first 1GB recording:-) Definitely ;-) regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools update
On Wed, 04 Jun 2003, Markus Plail wrote: [something that shouldn't have gone here, sorry.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools update
On Sun, 1 Jun 2003, Joerg Schilling wrote: From: Markus Plail [EMAIL PROTECTED] Seems to be the same as with cdrecord. The TEAC DV-W50E is a Pioneer A05 with only the inquiry string changed. I know. As the A05 is known to work perfectly with cdrecord, I have no idea what problems you have. The problem is linux kernel. With 2.4/5 ide-scsi everything is perfect, with 2.5 ide-cd it doesn't work although my acer cd writer works perfectly well. The error message you show us here is not very readable, cdrecord would in such a case write a readble message invalid address for write and add the hint that this is a buffer underrun. Yes, exactly. I didn't report that because I know it's not a problem of cdrecord. A more detailed report went to linux-kernel ML. If you read the README in ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ you see that you need to make sure that you have enough throughput on your system or use burnfree.. I know all that and I used burnfree. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does someone know how to cure the 2.5.59 kernel?
* Gregoire Favre writes: On Fri, Feb 07, 2003 at 03:19:06PM +0100, Joerg Schilling wrote: And I cannot help any further as long as I don't get more information why the scsi command did fail :-( Could I do something? Why do you use a development kernel in the first place? regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Add nero CD/DVD speed functionality to readcd
Hi all, especially Jörg!
As there is no such thing as C2-scans for DVD at the moment, I added an
analyze funtion to readcd. It displays a variable count of read speeds
when using readcd. In the end it can be used to display a nice graph
using gnuplot. This is at least a better indication of the
DVD+-R(W) write quality than the overall write speed.
The information is printed to stdout as opposed to all other messages
from readcd so that the essential data for gnuplot can be redirected
to a file and a simple
readcd dev=1,1,0 f=/dev/null -noerror retries=0 analyze=800 ~/Dokumente/readcd.dat
gnuplot plot /home/plail/Dokumente/readcd.dat w l
displayed a nice graph with 800 measure points.
The feature is disabled by default of course.
Any comments are welcome.
regards
Markus
--- cdrtools-2.1/readcd/readcd.c Sat Nov 30 17:43:53 2002
+++ cdrtools-2.0_analyze/readcd/readcd.c Sun Jan 19 18:10:10 2003
@@ -153,6 +153,7 @@
/*#define MAX_RETRY 32*/
#define MAX_RETRY 128
+#define DEF_ANALYZE -1
int help;
int xdebug;
@@ -168,6 +169,7 @@
BOOL nocorr;
BOOL notrunc;
int retries = MAX_RETRY;
+int analyze = DEF_ANALYZE;
struct scsi_format_data fmt;
@@ -199,12 +201,13 @@
error(\t-notrunc do not truncate outputfile in read mode\n);
error(\tretries=# set retry count (default is %d)\n, retries);
error(\t-overhead meter SCSI command overhead times\n);
+ error(\tanalyze=# print read-speed at # locations (default is %d)\n, analyze);
error(\n);
error(sectors=0-0 will read nothing, sectors=0-1 will read one sector starting from 0\n);
exit(ret);
}
-char opts[] = debug#,d+,kdebug#,kd#,timeout#,quiet,q,verbose+,v+,Verbose+,V+,x+,xd#,silent,s,help,h,version,dev*,sectors*,w,c2scan,fulltoc,clone,noerror,nocorr,notrunc,retries#,f*,speed#,overhead;
+char opts[] = debug#,d+,kdebug#,kd#,timeout#,quiet,q,verbose+,v+,Verbose+,V+,x+,xd#,silent,s,help,h,version,dev*,sectors*,w,c2scan,fulltoc,clone,noerror,nocorr,notrunc,retries#,f*,speed#,overhead,analyze#;
EXPORT int
main(ac, av)
@@ -250,7 +253,7 @@
fulltoc, clone,
noerror, nocorr,
notrunc, retries, filename,
- speed, dooverhead) 0) {
+ speed, dooverhead, analyze) 0) {
errmsgno(EX_BAD, Bad flag: %s.\n, cav[0]);
usage(EX_BAD);
}
@@ -513,6 +516,33 @@
return (1000*sec + (usec / 1000));
}
+/*
+ * Return milliseconds since start time, but be silent this time.
+ */
+LOCAL int
+prstats_silent()
+{
+ int sec;
+ int usec;
+ int tmsec;
+
+ if (gettimeofday(stoptime, (struct timezone *)0) 0)
+ comerr(Cannot get time\n);
+
+ sec = stoptime.tv_sec - starttime.tv_sec;
+ usec = stoptime.tv_usec - starttime.tv_usec;
+ tmsec = sec*1000 + usec/1000;
+#ifdef lint
+ tmsec = tmsec; /* Bisz spaeter */
+#endif
+ if (usec 0) {
+ sec--;
+ usec += 100;
+ }
+
+ return (1000*sec + (usec / 1000));
+}
+
LOCAL void
dorw(scgp, filename, sectors)
SCSI *scgp;
@@ -1033,12 +1063,15 @@
char filename[512];
char *defname = NULL;
FILE *f;
- long addr = 0L;
+ long old_addr = 0L, addr = 0L;
long num;
long end = 0L;
long start = 0L;
long cnt = 0L;
- int msec;
+ long next_measure = 0L;
+ long secs_per_measure = 0L;
+ double speed;
+ int old_msec = 0, msec;
int err = 0;
BOOL askrange = FALSE;
BOOL isrange = FALSE;
@@ -1121,6 +1154,13 @@
if (gettimeofday(starttime, (struct timezone *)0) 0)
comerr(Cannot get start time\n);
+ if (analyze != -1) {
+ if (end analyze)
+ secs_per_measure = 1;
+ else
+ secs_per_measure = end / analyze;
+ }
+
for(;addr end; addr += cnt) {
if (didintr)
comexit(exsig); /* XXX besseres Konzept?!*/
@@ -1128,7 +1168,24 @@
if ((addr + cnt) end)
cnt = end - addr;
- error(addr: %8ld cnt: %ld\r, addr, cnt);
+ if (analyze != -1) {
+ if (addr next_measure) {
+msec = prstats_silent();
+if ((msec - old_msec)== 0) /* Avoid division by zero */
+ msec = old_msec + 1;
+speed = ((addr - old_addr)/(1024.0/secsize)) / (0.001*(msec - old_msec));
+
+error(addr: %8ld cnt: %ld analyze:, addr, cnt);
+printf(%7ld %7.1f\n, addr, speed);
+error(\r);
+next_measure += secs_per_measure;
+old_addr = addr;
+old_msec = msec;
+ }
+ error(addr: %8ld cnt: %ld\r, addr, cnt, speed);
+ } else {
+ error(addr: %8ld cnt: %ld\r, addr, cnt);
+ }
scgp-silent++;
if ((*rfunc)(scgp, rp, Sbuf, addr, cnt) 0) {
Re: Status of ide writing?
* Gregoire Favre writes: is it possible to burn without idescsi under 2.5.56? It would be a good idea to tell us what command line options you used. You could also try to burn CDs and see if that works. All I can tell you is, that I succesfully burned some CDs without ide-scsi in 2.5 kernels. But why do you use 2.5 kernels? DVDs are are only written in 2048 bytes/sector mode so that the ugly effects the 2.4 kernel shows with unnormal sector sizes don't matter. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Condition to burn DVD in speed 2?
* Gregoire Favre writes: great, I thought I should change the license of cdrecord-prodvd... You can burn at least 4x with the free key provided in the README. That's mostly a limitation for the clone features of cdrecordPRODVD. regards Markus PS: I am quite sure you won't get the source code, as you only buy a better key. The reason Jörg isn't gtiving away the source is that his software is state-of-the-art and he don't want it to be stolen. That has happened already with parts of cdrecord IIRC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs DVD-Video problem Help wanted
* Joerg Schilling writes: as you might have noticed, there still is a problem in mkisofs: With at least one DVD-Video (ice age as sold in Germany) there is a problem when you try to create a UDF DVD from the file tree. If you call: mkisofs -o /tmp/DVD.out -dvd-video DVD-Video/ and get: The pad was 8 for file VIDEO_TS.BUP OBJ/sparc-sunos5-cc/mkisofs: Implementation botch. Video pad for file VTS_02_1.VOB is -13 OBJ/sparc-sunos5-cc/mkisofs: Either the *.IFO file is bad or you found a mkisofs bug. I received the *.IFO files from the person who reported the problem and I created sparse files for the rest of the files in the tree. If you like to help me, please first load the tar file with the files decribed above from: I have ICE AGE lying around here, so I copied it to my HDD (dvdbackup) and let mkisofs create the image - no problems Then I tried it with the files you provided and I got above mentioned behaviour. I then compared the two directories and the only difference was that dvdbackup didn't create the 0 byte VOB files. After deleting them from your directory it worked flawlessly. So it may not be a bug in mkisofs but perhaps the 0 byte VOBs are kinda invalid. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs DVD-Video problem Help wanted
* Andy Polyakov writes: BTW, Markus! Can you confirm that remaining files are not renamed. I mean when it deletes 0-sized VTS_02_00.VOB, does it rename VTS_02_01.VOB to VTS_02_00.VOB or is it so that VTS_02_00.VOB is not present at all? They are not present at all. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TEAC DV-W50E
* Joerg Schilling writes: From: Markus Plail [EMAIL PROTECTED] Today I got the DVD writer, which is a clone of the Pioneer A05. I could flawlessly burn an ISO to a DVD-RW at speed 1x. I got an error messages though. Don't know if it is of any interest. I cannot see error messages. Executing 'log sense' command on Bus 1 Target 1, Lun 0 timeout 100s CDB: 4D 00 71 00 00 00 00 00 FF 00 cdrecord-ProDVD: Input/output error. log sense: scsi sendcmd: no error CDB: 4D 00 71 00 00 00 00 00 FF 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 24 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.005s timeout 100s This looked like an error message to me. PS: Do you have already decided on how to handle the free license noncommercial after January 15th? Any comment on that one? PPS: Would it be possible to release a new binary with support for dev=/dev/hdX in development kernels? ??? /dev/hdX is not supported although it may work. Sorry for that. I forgot that cdrecord can handle dev=/dev/hdX already in a40 which is available as ProDVD version for linux. As for the Linux kernel: Does that mean that you will not bother to enhance support for the new interface provided in 2.5 kernels? I know you don't like the design of it and yes I read the threads on LKML about it. Do you know anything new from Jens Axboe? So far readcd doesn't work at all with the new interface. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* Markus Plail writes: * Len Sorensen writes: use 2048byte blocks, can't use dma on current linux kernels (supposedly it will be possible in 2.6 kernels). Audio would fit that category and hence use a lot more cpu. It is already possible in 2.5 kernels and I am still convinced that it's also possible with 2.4 kernels. Just tested it once again. Audio CD at 20x speed with less than 3% CPU load (user+system). My kernel must be doing something wrong ;-) Just a quick update. Today I bought a cd writer for a friend. It's an MSI 48x. Now I have the very same symptoms as everybody else. At 20x RAW it takes about 15% system load and when the drive switches to 30x it's getting unstable already, i.e. 0% idle and buffer getting low. I have no idea why I only have 3% system load with my acer 20x drive. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* Len Sorensen writes: On Wed, Nov 27, 2002 at 11:54:22PM +0100, Markus Plail wrote: Yes, ATAPI. acer CDRW 2010A (crappy), ECS KSS5A with Athlon XP1800+. SIS5513: chipset revision 208 SIS5513: not 100%% native mode: will probe irqs later SiS735ATA 100 controller As soon as I disable DMA I get the high loads reported everywhere. Are you disableing dma on the HD or the cd burner though? Haven't tried disabling the HD as well. I was refering to disabling DMA on the burner. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* Len Sorensen writes: On Tue, Nov 26, 2002 at 03:56:21PM -0600, David Bell wrote: On Tue, 2002-11-26 at 15:37, Len Sorensen wrote: I see NOTHING there that indicates if dma is on or off, only what is supported. The * does NOT indicate linux is using dma. /proc/ide/hd?/settings does, as might hdparm device, by itself. Your method most certainly does not. Sorry about that, It seems I wanted hdparm -v, not hdparm -i: [hdparm saying DMA is on] ...As you can see (I hope), DMA is enabled on all of these devices. Yep. Looks on. Can't think of anything else, other than maybe you are burning cds that are not plain iso data images. Anything that doens't Well, have a look at the subject ;-) use 2048byte blocks, can't use dma on current linux kernels (supposedly it will be possible in 2.6 kernels). Audio would fit that category and hence use a lot more cpu. It is already possible in 2.5 kernels and I am still convinced that it's also possible with 2.4 kernels. Just tested it once again. Audio CD at 20x speed with less than 3% CPU load (user+system). My kernel must be doing something wrong ;-) regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* Len Sorensen writes: On Wed, Nov 27, 2002 at 10:53:35PM +0100, Markus Plail wrote: It is already possible in 2.5 kernels and I am still convinced that it's also possible with 2.4 kernels. Just tested it once again. Audio CD at 20x speed with less than 3% CPU load (user+system). My kernel must be doing something wrong ;-) With an ATAPI cd burner? Which IDE chipset, which CPU and speed? Yes, ATAPI. acer CDRW 2010A (crappy), ECS KSS5A with Athlon XP1800+. SIS5513: chipset revision 208 SIS5513: not 100%% native mode: will probe irqs later SiS735ATA 100 controller As soon as I disable DMA I get the high loads reported everywhere. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* David Bell writes: [high system load when doing anything other than burning plain data discs] Is this an issue in the kernel or cdrecord? Kernel. Is it expected to be fixed soon? Kinda fixed since 2.5.47 IIRC. ide_scsi isn't needed anymore, but readcd doesn't work yet. If not, if I put the burner on a Promise IDE controller card, would the problems subside? Probably not. Promise controllers are known for not really liking devices other than hard discs. I seem to be one of very few people who got audio CD burning to work in 2.4 kernels. In the end I could write audio CDs at 20x speed in RAW96 mode with no more than 3% system load. You can contatc me personally if you want to know my settings (or google for them) but they don't seem to work for everyone and Joerg didn't even believe me I got it working ;-) regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High system load when burning audio CDs on VIA686B
* David Bell writes: Yes, DMA is enabled on all drives: [12:50:51][root@david:/home/david]# hdparm -i /dev/hda hdparm -i isn't really appropriate here. You should use -v. man hdparm: -i Display the identification info that was obtained from the drive at boot time, if available. This is a feature of modern IDE drives, and may not be supported by older devices. The data returned may or may not be current, depending on activity since booting the system. However, the current multiple sector mode count is always shown. For a more detailed interpretation of the identifica tion info, refer to AT Attachment Interface for Disk Drives (ANSI ASC X3T9.2 working draft, revision 4a, April 19/93). regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with readcd and Aopen CDROM drive
* Lourens Veen writes: On Friday 01 Nov 2002 10:42 pm, Tom Crane wrote: I followed up Jorg's suggestion of firmware updates for the Aopen but there appear to be none for that drive. Any suggestions for a workaround to force readcd to read only the true data/2048 sector-size? Failing that, perhaps you could create a small program based on libedc (be sure to take the libedc code from cdrdao, as the code distributed with cdrtools is _not_ GPL and may only be used as a part of cdrecord) If I understood Jörg correctly all of cdrecord is GPL now, including libedc. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux DMA-issues (was: cdrtools-1.11a37 ready)
Hi Frederick! * Frederick Page writes: Markus Plail wrote on Sat, Oct 12 2002: Again: the idle time is important. I'd say system time is important. I simply don't know (you might be right). I just watched the idle time and got quite a good feedback from it during my tests with the ATAPI writer. High system time normally means that something is wrong. In this case PIO is used instead of DMA. I guess many roads lead to Rome ;-) High system time (or low idle time) IMHO both indicate PIO. Not necessarily. If you write a RAW CD on a quite low-end system at high speeds, you might see low idle time due to to libedc calculation. This time is assigned to cdrecord. All with DMA enabled. If PIO is used the CPU usage should be assigned to system. of course - in the end - a low idle time is never good, but high system time almost surely means that something's wrong. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-1.11a37 ready
Hi Jörg! * Joerg Schilling writes: Note that the encoding speed is content dependant. Also note that due to a kernel design bug, Linux does not enable DMA for ATAPI drives if the sector size is != 2048 (as with RAW sector size 2448). This results in a high system load and may cause a buffer underrun even before the estimated maximum speed of the edc library has been reached. This is not true, at least not as a general statement. As I reported in a newsgroup, you are reading, I was able to burn a data CD with -raw96r at 20x speed with my ATAPI CD writer with less than 5% CPU usage with your closed source version. AUDIO CDs can be burnt with the same options with less than 3% CPU usage even with the open source version. So it's rather a bad setup than a general Linux problem. I tested this with 2.4.18 and 2.4.20-pre8-ac3, i.e. with the new and the old IDE subsystem. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-1.11a37 ready
Hi Jörg! * Joerg Schilling writes: From: Markus Plail [EMAIL PROTECTED] * Joerg Schilling writes: Note that the encoding speed is content dependant. Also note that due to a kernel design bug, Linux does not enable DMA for ATAPI drives if the sector size is != 2048 (as with RAW sector size 2448). This results in a high system load and may cause a buffer underrun even before the estimated maximum speed of the edc library has been reached. This is not true, at least not as a general statement. As I reported in a newsgroup, you are reading, I was able to burn a data CD with -raw96r at 20x speed with my ATAPI CD writer with less than 5% CPU usage with your closed source version. AUDIO CDs can be burnt with the same options with less than 3% CPU usage even with the open source version. So it's rather a bad setup than a general Linux problem. I tested this with 2.4.18 and 2.4.20-pre8-ac3, i.e. with the new and the old IDE subsystem. The fact that Linux does not use DMA with ATAPI has ben reported by may people! Having 3% load is a hint that there is no DMA You must be joking. If I disable DMA I can't even burn at 20x speed. And actually it's not been many people. I'd rather say a handful and considering that almost everybody has a CD writer these days, that's really few. It was also said, that doing c2 scans can't be done with DMA enabled. I can do them at 40x speed with only a few percent CPU usage. Also a sign for PIO? In addition, it may be that Linux does not report the load correctly when doing PIO to the drive. Why wouldn't it? It's all system time when PIO is disabled. Maybe this is a bug, but they load is showing at least correct numbers. If yout load was less than 5%, then you must have a PC with more than 2 Ghz. It the oad you reported is really correct, then try 1.11a37 With the new free cdrecord, you should be able to write in 24x with less than 15% load. I have about 18% load at 16x with the new version. It says libedc is able to do 147x speed. The closed source version does 422x and a36 was about 125x IIRC. I am using a Athlon XP1800+ with CL2 DDRAM. So I am *really* sure that I am using DMA with 'strange' sector sizes. One oddity also seems to be that the CPU usage seems to jump a bit. At 12x I have almost no load and then it's about 15% per 4x speed increase. That may explain my low CPU usage with the closed source version. I would expect it to make a jump, if I'd burn faster than 20x, which I can't unfortunately. regards Markus PS: You don't have to CC me. I am on the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-1.11a37 ready
* Joerg Schilling writes: From: Markus Plail [EMAIL PROTECTED] I have about 18% load at 16x with the new version. It says libedc is able to do 147x speed. The closed source version does 422x and a36 was about 125x IIRC. I am using a Athlon XP1800+ with CL2 DDRAM. Please run another test. Use 1.11a36 and replace sector.c by the sector.c version that comes with 1.11a37. Doe to the content dependance of the encoding speed, it may be that 1.11a36 will then only report ~ 100x. It still shows 147x, but the load is only about 13% now. Please note that the closed source version may even be slower than the latest open soruce version if you run it on CPUs that are slow and only have a small cache. The closed source version differs significantly from the open source version. The advantage of the new open source version is that it provides a speed advantage that is independant of cache size and other special CPU features. Well, seems my Athlon is neither slow nor has a little cache ;-) regards Mar - still being CCed - kus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux DMA-issues (was: cdrtools-1.11a37 ready)
Hi Frederick! * Frederick Page writes: Hi Joerg, Joerg Schilling wrote on Sat, Oct 12 2002: The fact that Linux does not use DMA with ATAPI has ben reported by may people! For example in the Linux Kernel Mailing List, and one would assume, that those guys know what's going on. Yes, they should, but it seems, that it's not the case. Or how would you explain my results? And then agaion it wasn't many people on LKML. In addition, it may be that Linux does not report the load correctly when doing PIO to the drive. This (sadly) is another issue, when using e.g. top, one should *not* look at the CPU-consumption of cdrecord, but have a look at the idle time. You will find, that cdrecord e.g. uses 5% resources, the other tasks maybe another 5%, but that idle-time (should be around 90% in this example) is only 10% or less. Well, I don't think this behaviour is wrong actually. What really eats up CPU time in PIO mode is the interrupt handling. So it's not cdrecord, that uses the CPU, but the system and that's they way it is shown in top. As system time. Meaning: the ressources shown in top do not add up when the kernel falls back to PIO mode. It's quite easy to get confused about the real ressources-consumption, when just watching the processes and/or system/user times. Again: the idle time is important. I'd say system time is important. High system time normally means that something is wrong. In this case PIO is used instead of DMA. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug in ide-scsi transport?
Hi Paul! * Paul R Culmo writes: I've been having some issues with CDrecord and cd burning in general with cdrecord and redhat 7.3 with the 2.4.19 kernel but it happens with the 2.4.18-3 kernel too. I have a HP CD-RW 24x10x40 and when burning at speeds higher than 8x the following error shows up CDB: 2A 00 00 03 7E 47 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 03 00 03 7E DF 0A 00 00 00 00 0C 09 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0 ^ This indicates a buffer underrun Sense flags: Blk 229087 (valid) cmd finished after 0.057s timeout 40s First of all: Do you have DMA enabled for the burner? Try 'hdparm -d1 -u0 -c3 /dev/your_writer'. If it still doesn't work after that, make sure that you don't use any -raw options and preferrably not -dao either. Linux has some severe lack of support for DMA on 'odd' blocksizes. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD-RW/DVD+RW
Hi Len! * Len Sorensen writes: I expect DVD+RW to die a quick death, or at least don't care if it survives. It hasn't delivered any of what it promised, and offers nothing as far as I can tell that DVD-R(W) doesn't already offer. The only advantage I see at the moment for DVD+R(W) is that M$ will directly support it in Windows and not DVD-R(W). Regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating .inf files
Hi Bill! * Bill Davidsen writes: I have some .wav files without and info files. These are not CD RIPs, the source predates CD by decades. Is there a good software to generate .inf files from the .wav files, other than the titles and artists, so I can fill them in? Platform is Linux. What I tend to do is to burn the wav files on a CDRW and extract it via cdda2wav. So you get the .inf files, edit them and burn the CD. HTH Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Errors in one of the last sectors
Hi! Burning CDs with the latest cdrtools (same behaviour with a13) I always get one unreadable sector. This sector is always one of the last and it's always only one defect sector. It's the same with two different CDR media (Kodak Ultima 80 (1-24x) and Memorex 80 16x) and two burners (Teac CDR-55S and ACER 20/10). When I searched the net I found some older messages which said something about read-ahead bug and about the -pad option. Using -pad or -nopad doesn't change anything either. There are no error messages from cdrecord. Burned with windows I don't have that problems. My system is: Linux plailis_lfs 2.4.18-ac1 Regards Markus readcd output: readcd dev=1,1,0 -c2scan Capacity: 360848 Blocks = 721696 kBytes = 704 MBytes = 739 prMB Sectorsize: 2048 Bytes Copy from SCSI (1,1,0) disk to file '/dev/null' end:360848 C2 in sector: 15270 first at byte: 332 (0x0F) total: 72 errors C2 in sector: 15271 first at byte: 188 (0x0F) total: 24 errors readcd: Input/output error. read_cd: scsi sendcmd: no error CDB: BE 00 00 05 81 34 00 00 5C FA 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 03 00 05 81 8E 0A 00 00 00 00 11 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x11 Qual 0x00 (unrecovered read error) Fru 0x0 Sense flags: Blk 360846 (valid) cmd finished after 1.750s timeout 40s readcd: Input/output error. Cannot read source disk readcd: Retrying from sector 360756. .. .~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~ ~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~ readcd: Input/output error. Error on sector 360846 not corrected. Total of 1 errors. Time total: 1100.198sec Read 932187.87 kB at 847.3 kB/sec. C2 errors total: 96 bytes in 2 sectors on disk C2 errors rate: 0.11% C2 errors on worst sector: 72, sectors with 100+ C2 errors: 0 example of cdrecord output (as per gcombust which calls cdrecord in that way (example): /usr/bin/mkisofs -graft-points -f -R -r -l -J -VGladiator_CD1_3 -- Gladiator-.avi=/video2/dvdrip/gladiator/avi/001/Gladiator-.avi /usr/bin/cdrecord -v -pad speed=20 dev=1,0,0 -dao tsize=340192s - ): Cdrecord 1.11a15 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.5' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'ATAPI ' Identifikation : 'CD-R/RW 20X10 ' Revision : 'H.JH' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO RAW/R16 RAW/R96R Drive buf size : 1630208 = 1592 KB FIFO size : 4194304 = 4096 KB scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Linux sg driver version: 3.1.22 /usr/bin/cdrecord: WARNING: Data may not fit on current disk. /usr/bin/cdrecord: Notice: Overburning active. Trying to write more than the official disk capacity. Track 01: data 704 MB Lout start: 809 MB (80:13/23) = 360848 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 4 Is not unrestricted Is not erasable Disk sub type: Medium Type B, low Beta category (B-) (4) ATIP start of lead in: -11579 (97:27/46) ATIP start of lead out: 359849 (79:59/74) Disk type:Short strategy type (Phthalocyanine or similar) Manuf. index: 9 Manufacturer: Kodak Japan Limited Blocks total: 359849 Blocks current: 359849 Blocks remaining: -999 Starting to write CD/DVD at speed 16 in write mode for single session. BURN-Free is OFF. Performing OPC... Sending CUE sheet... /usr/bin/cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Writing pregap for track 1 at -150 Track 01: 0 of 704 MB written. Track 01: Total bytes read/written: 739016704/739016704 (360848 sectors). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
