Some dvd+rw-mediainfo of failure DVD+R DL
Hello, I would be very happy to try growisofs from my little script, could someone told me how to modifiy it in order to have more chance of sucess when burning DVD+R DL media on my burner ? I don't remember which disk is "what", I now just wrote number on top of each so if anyone want more info on any of those, please ask ;-) 1 : INQUIRY:[LITE-ON ][DVDRW LH-20A1S ][9L09] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RICOHJPN/D01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s Write Speed #3:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 3.2x1385=4432KB/[EMAIL PROTECTED] -> 0] Speed Descriptor#0:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#3:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2086912*2KB=4273995776 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2086912*2KB, can no longer be set READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete "Next" Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible Track Start Address: 0*2KB Next Writable Address: 2086912*2KB Free Blocks: 2086912*2KB Track Size:4173824*2KB ROM Compatibility LBA: 262144 READ CAPACITY: 0*2048=0 2: INQUIRY:[LITE-ON ][DVDRW LH-20A1S ][9L09] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RICOHJPN/D01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s Write Speed #3:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 3.2x1385=4432KB/[EMAIL PROTECTED] -> 0] Speed Descriptor#0:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#3:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2086912*2KB=4273995776 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2086912*2KB, can still be set :-[ READ DISC INFORMATION failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error 3: INQUIRY:[LITE-ON ][DVDRW LH-20A1S ][9L09] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RICOHJPN/D01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s Write Speed #3:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 3.2x1385=4432KB/[EMAIL PROTECTED] -> 11.9x1385=16496KB/[EMAIL PROTECTED] Speed Descriptor#0:00/4167103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/4167103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/4167103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#3:00/4167103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2083552*2KB=4267114496 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2083552*2KB, can no longer be set READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:4167104*2KB ROM Compatibility LBA: 262144 FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 4167104*2048=8534228992 4: INQUIRY:[LITE-ON ][DVDRW LH-20A1S ][9L09] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RICOHJPN/D01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s Write Speed #3:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 3.2x1385=4432KB/[EMAIL PROTECTED] -> 0] Speed Descriptor#0:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descri
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > Hi, > > i wrote: > > > the official Linux world rather settled with wodim. > Joerg Schilling wrote: > > They will stop doing this stupid move after they realized that > > this move did create them dozens of unfixed bugs and that there is no > > maintanance for "wodim". > > What maintenance would it need for its > core purpose to write CDs ? > If ever then i expect that i needs to be > adapted to some future new kernel interface. They added a lot of bugs that are not in the original software. You thus cannot think about cdrecord but talk about wodim. Cdrecord would not soon need new CD related features but wodim is also based on a 3+ year old cdrecord version that misses features that are present in cdrecord for a while. Look at the bug list I send you to find the obvious problems. It nicely also shows up many bugs "cdrkit" added to it's mkisofs version: e.g. broken support for Joliet, broken support for UTF-8 based locales and a broken "implementation" for files > 4 GB. Of course, the real problem is that there have been changes in libscg and wodim that are a result of a hostile attitude against a platform-neutral CLI and a result of denying the need for extended privileges to write CDs/DVDs. These changes make wodim harder to use than the original and hide problems that are reported early in the original - in wodim the resulting problems are reported late and in a hard to classify way. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi, i wrote: > > the official Linux world rather settled with wodim. Joerg Schilling wrote: > They will stop doing this stupid move after they realized that > this move did create them dozens of unfixed bugs and that there is no > maintanance for "wodim". What maintenance would it need for its core purpose to write CDs ? If ever then i expect that i needs to be adapted to some future new kernel interface. For DVD it is usual to employ growisofs. My own backup tool still prefers it over any other burn program for DVD when it comes to automatic choice. (But it has to operate it correctly. Pffft.) > > What precaution in cdrecord might avoid or > > compensate a 3 0C 00 WRITE ERROR ? > Now that we know a primary problem, let us asume that the drive reports > incorrect error messages and try again ;-) Problem number 2 can occur only if the burn program does not align its writes to 16 block boundaries. Both, growisofs and cdrskin do align to 16. Both did not show the error at the end of L0 but substantially within L1. Problem 2 and 3 are clearly distinct. I expect cdrecord to run into 3 after 2 is solved. If 3 does not happen, then i want to know why. But "happen" and "not happen" is a matter of measurement and statistics. We still have a probability of about 4% that all observations around problem 3 are just statistical noise. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
On Fri, May 16, 2008 at 03:34:52PM +0200, Joerg Schilling wrote: > I'll write a fix for cdrecord soon, tghen he may try again ;-) Oh great :-) I am quiete used to cdrecord which I would be pleased to be able to use for DVD+R DL also ! Thank. -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > > Could you explain why writing a new program should > > help to "fix" the hostile habbit of some Linux kernel > > developers? > > I see this as a more complex system of animosity. > To exchange one component might change that > system completely. > But for now, the official Linux world rather settled > with wodim. So the quarrel ended anyway. They will stop doing this stupid move after they realized that this move did create them dozens of unfixed bugs and that there is no maintanance for "wodim". Wodim "development" stopped more than a year ago on May 6th 2007. The changes that have been made later just try to hide this fact. All wodim changes in total made after May 6th 2007 sum up to less than what I change in cdrtools in a lazy week. Look e.g. at https://bugs.launchpad.net/ubuntu/+source/cdrkit None of the problems listed there is present if you use the unmodifies offcial cdrtools. Some Linux people are strange. They e.g. complain about compile problems with star on some Linux distributions (calling star junk) but forget that these problems are a result of the fact that star support Linux specific features. If those Linux distros would be installed in a consistent way, the compile problems would go away. GNU tar on the other side does not support _any_ Linux specific feature. It seems that the reason why some people don't like my software is because I am supporting Linux too well ;-) What we need is people who understand why problems occur and that help educating others to avoid to repeat the same mistakes ever and ever again. Libscg is based on 22 years of experiences with SCSI transport on many _different_ platforms. This is why it is portable ;-) > Joerg Schilling wrote: > > I'll write a fix for cdrecord soon, tghen he may try again ;-) > > You make me curious. > What precaution in cdrecord might avoid or > compensate a 3 0C 00 WRITE ERROR ? Now that we know a primary problem, let us asume that the drive reports incorrect error messages and try again ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
[-dvd-compat] will still allow you to pad DVD+R, DVD-R Incremental, even DVD-R DL recordings, not to mention rewritables.. Yeah. That's why this development glitch could stay undetected for quite a while. It is harmless if the image comes from a regular disk file, i understand from reading your builtin_dd(). Correct. There is also possibility that some/their units require layer break to be set but stranger things were observed... Hm. I shall prepare libburn for explicite setting of that address. For now i left it out because the specs do not call it mandatory by any means and because i do not fully understand the consequences. (E.g. may i set the L0 capacity to hundred MB and still write the full 4+ GB on L1 ? No. How much you can write to L1 will always be less or equal to L0 capacity. Do i need to call RESERVE TRACK ? ...) No. I.e. not according to specification. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi,
Andy Polyakov wrote:
> [-dvd-compat] will still allow you to pad DVD+R,
> DVD-R Incremental, even DVD-R DL recordings,
> not to mention rewritables..
Yeah. That's why this development glitch could
stay undetected for quite a while.
It is harmless if the image comes from a regular
disk file, i understand from reading your builtin_dd().
I am currently testing the new "stable" and
unstable uploads of scdbackup. Now there are
precautions that -dvd-compat and -Z ...=/dev/fd/0
will not get together again.
Andy Polyakov wrote:
> There is also possibility that some/their units require layer break to be set
> but stranger things were observed...
Hm. I shall prepare libburn for explicite setting
of that address.
For now i left it out because the specs
do not call it mandatory by any means
and because i do not fully understand the
consequences.
(E.g. may i set the L0 capacity to hundred MB
and still write the full 4+ GB on L1 ? Do i
need to call RESERVE TRACK ? ...)
Joerg Schilling wrote:
> It [Gregoire's problem] is most likely a combination
> od 2 and 3.
Yep. Quite surely Gregoire's drive has a problem with 2,
the write command which touches both layers.
As for number 3, the write error far after the
layer break, anything is possible.
I estimate the probability for the observation
that 2 runs of growisofs and cdrskin failed and
6 runs of Nero succeed by incident as about 1/28 :
The first hit has probability 2/8, the second 1/7.
One can hardly state that this is not suspicious
of being systematic.
> Could you explain why writing a new program should
> help to "fix" the hostile habbit of some Linux kernel
> developers?
I see this as a more complex system of animosity.
To exchange one component might change that
system completely.
But for now, the official Linux world rather settled
with wodim. So the quarrel ended anyway.
Joerg Schilling wrote:
> I'll write a fix for cdrecord soon, tghen he may try again ;-)
You make me curious.
What precaution in cdrecord might avoid or
compensate a 3 0C 00 WRITE ERROR ?
The usual list of causes is
{"bad media", "automounter interference", "bad drive"}
Do you know more ?
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > Hi, > > > _all_ other OS forbid to send SCSI commands > > from a normal user account. > > There are obviously workarounds for that restriction. > As soon as the demand occurs i will try to learn. > In worst case i would propose some client-server > architecture. ASPI is no workaround, it undermines the privileges of the basic host system. > > Please start explaining why you did not use libscg which grants portability > > for software that likes to send SCSI commands to arbitrary targets. > > That is because the reason for starting cdrskin was > my wish to have a CD burn program which has no > hostile relationship with Linux kernel people. > Zero cdrecord ancestry is a design goal. > (We have had enough clones, hadn't we ?) Could you explain why writing a new program should help to "fix" the hostile habbit of some Linux kernel developers? > It is not bad to have multiple burn programs. > They allow us to explore drive peculiarities. > If only Nero had the politeness to misburn one > or two of Gregoire's DVD+R DL. Grrr. I'll write a fix for cdrecord soon, tghen he may try again ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: It is most likely a combination od 2 and 3. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The future of mkisofs
mkisofs is a program that has been originally writen in 1993 by Eric Youngdale and that has been extended by many people. In 1997, after Eric Youngdale mostly stopped working on mkisofs, I added mkisofs to the cdrecord source tree and started working on bugs and important extensions. After 2 years (in 1999) Eric Youngdale transferred the complete code reporitory to me. At that time, several people helped to enhance mkisofs. The most active one was James Pearson - he is unfortunately no longer reachable since he became a father years ago. Since that time, more than 5 years ago, I am the main mkisofs maintainer. Being now able to decide myself in mkisofs since 1999, I spend half a year only with bug fixes and code restructuring to make the code prepared for the future Now more than 8 years later, mkisofs has a lot more features than in 1999 and needs another code lifting. As mkisofs is very powerful and supports many OS and filesystem-hybrids, it has become a de-facto standard for creating ISO-9660 based filesystem images. We are currently a short time before the next "stable" release of cdrtools and I am planning to start a bigger code clean up after that time. The current plan is to do it the following way: - cdrtools-xxx.zzz-final (the next "stable" release) will be the last release that includes all features that are currently in mkisofs. People who need these features (e.g. because they own old hardware) need to keel the version of mkisofs that is included in the next stable version of cdrtools. - The ability to create "Apple-Hybrid" filesystem images causes problems since many years already because the "Apple HFS" filesystem type does not support files > 2 GB and includes other limitations. - Support for this old filesystem is only needed for owners of Mac OS 9 systems and for people who like to boot Apple PPC based systems. These Apple PPC based systems are out of production since 3 years already. - Recent Apple systems boot using El-Torito extensions and understand UDF + Apple extensions. Both is supported in mkisofs since a while. It seems that support for "Apple HFS" is no longer needed in mkisofs and removing the support could help to clean up the code. I am planning to remove the "Apple-Hybrid" support with the developer versions for cdrtools that follow the next stable release of cdrtools. People who believe that this change would cause problems are called to explain their arguments. Please comment. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
- Problem number 1: Rob and CJ have drives which do not like any other layer break address than the one which is their default. Thus growisofs and cdrecord fail if their automatically computed layer breaks get set. The remedy is to enforce the drive's default layer break address and override the programs' computations. (This would mean that cdrskin has no problem with those drives. I would appreciate confirmation.) There is also possibility that some/their units require layer break to be set and to be set to value embossed into media information zone. I mean not setting layer break might fail too, just as setting it to non-default value. I know it sounds crazy, as unit knows where to set layer break, and shouldn't need a reminder, but stranger things were observed... Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [cdwrite] Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Thomas Schmitt wrote: > Problem number 1: > Rob and CJ have drives which do not like any > other layer break address than the one which > is their default. ... > (This would mean that cdrskin has no problem > with those drives. I would appreciate > confirmation.) Yeah, no problem. I'm heading out for the weekend, but I'll make the time to run some tests in the beginning of next week. -CJ -- WOW: Flemmy| "Happiness isn't good enough for me! I [EMAIL PROTECTED] | demand euphoria!" 24.24.2.3171 | - Calvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Question is if above is actually complete growisofs command line? Very good question, indeed. Somehow -dvd-compat sneaked into the growisofs_wrapper of scdbackup since i made the last round of media tests. The command line is most probably this: growisofs -use-the-force-luke \ -dvd-compat \ -use-the-force-luke=bufsize:16m \ -use-the-force-luke=noload \ -Z /dev/sr0=/dev/fd/0 which is well entitled to assume the ISO size as full image size if no other hint is available. Note that in last post I've said "... the only case that would cause the same error..." It holds true even for -dvd-compat recordings. I.e. -dvd-compat would cause the problem in question *only* in DVD+R DL and DVD-R[W] DAO context. It will still allow you to pad DVD+R, DVD-R Incremental, even DVD-R DL recordings, not to mention rewritables... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi, Andy Polyakov wrote: > Question > is if above is actually complete growisofs command line? Very good question, indeed. Somehow -dvd-compat sneaked into the growisofs_wrapper of scdbackup since i made the last round of media tests. The command line is most probably this: growisofs -use-the-force-luke \ -dvd-compat \ -use-the-force-luke=bufsize:16m \ -use-the-force-luke=noload \ -Z /dev/sr0=/dev/fd/0 which is well entitled to assume the ISO size as full image size if no other hint is available. Sorry for confusing. -- So there remains one big riddle: Why does Nero show no write errors on Gergoire's drive ? Is it more modest in speed ? > it would be possible to re-run the > exact command and complete recording. Can it be that Nero catches the error and immediately does such a re-start ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Question is if above is actually complete growisofs command line? It comes out of a wrapper script that converts cdrecord options into runs of dvd+rw-tools. The write command is supposed to be: growisofs \ -use-the-force-luke \ -use-the-force-luke=bufsize:16m \ -use-the-force-luke=noload \ -Z /dev/...=/dev/fd/0 Eventually there is also option speed=... Then it's very strange... Point is that growisofs does *not* set layer break, if you don't pass -dvd-compat [or -dvd-video] Hmm. That would also make questionable my argumentation about Problem 2. No, not at all. So if growisofs did not issue a layer break position then Gregoire's drive may or may not have Problem 1. But in Gregoire's scripts i do read -dvd-compat. Right... So probably the theory about number 2 still stands. But in either case problem 2 is about WRITE command crossing layer break position. As far as I understand it doesn't matter where is is, default or explicitly set [to lower value]. As for scdbackup: I am quite sure that the failed growisofs run for scdbackup was not with -dvd-compat or any other option which causes a fixed size. The growisofs wrapper works fine for sequential DVD-RW where such a setting would cause the same error. Not necessarily. The only case that would cause the same error is if minimally blanked DVD-RW so that DAO gets engaged or DAO is explicitly engaged on command line. If DVD-RW media is fully blanked or formatted for restricted overwrite, the you will not suffer from this problem (unless of course image really fills the media till the very edge, so there is not place for your additional data). Obvious is the relation of error position, error message and size of the plain ISO image. Regrettably i cannot get that user to make more experiments which each eat up one DL media. The problem will have to wait for the next occasion to show up. As usual collect versioning information, dvd+rw-mediainfo for resulting recording, exact command line and exact output. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [cdwrite] Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Gregoire Favre <[EMAIL PROTECTED]> wrote: > Hello, > > I have tried with > mkisofs $OPTS -V $1 $2|cdrecord driveropts=layerbreak=2086912 $COMCD > tsize="$SIZE"s - > > Which I am not sure of the syntax... I don't fully understand cdrecord > man page. > > Unfortunately : > > Track 01: 4041 of 8124 MB written (fifo 100%) [buf 99%] 8.4x. 61.66% done, > estimate finish Thu May 15 22:44:57 2008 > Track 01: 4051 of 8124 MB written (fifo 99%) [buf 99%] 8.4x. 61.78% done, > estimate finish Thu May 15 22:44:56 2008 > Track 01: 4061 of 8124 MB written (fifo 99%) [buf 99%] 8.3x. 61.90% done, > estimate finish Thu May 15 22:44:55 2008 > Track 01: 4070 of 8124 MB written (fifo 99%) [buf 99%] 8.5x. 62.02% done, > estimate finish Thu May 15 22:44:55 2008 > Track 01: 4075 of 8124 MB written (fifo 99%) [buf 99%] 8.2x.cdrecord: > faio_wait_on_buffer for writer timed out. > cdrecord: Input/output error. write_g1: scsi sendcmd: no error > CDB: 2A 00 00 1F D7 E9 00 00 1F 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 72 0B 00 00 00 00 00 0E 09 0C 00 00 00 03 00 00 > Sense Key: 0x0 No Additional Sense, Segment 11 > Sense Code: 0x00 Qual 0x03 (setmark detected) Fru 0x0 > Sense flags: Blk 0 (not valid) > cmd finished after 255.841s timeout 100s > cdrecord: No such device or address. Cannot send SCSI cmd via ioctl. This is the first useful error message. It finally lead to the underlying problem. When I started to add Dual Layer support to cdrecord, I intended to follow the standard that requires to align writes at the layer break. It got somehow forgotten during the work and several people reported that cdrecord worked fine for them. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi, > Question > is if above is actually complete growisofs command line? It comes out of a wrapper script that converts cdrecord options into runs of dvd+rw-tools. The write command is supposed to be: growisofs \ -use-the-force-luke \ -use-the-force-luke=bufsize:16m \ -use-the-force-luke=noload \ -Z /dev/...=/dev/fd/0 Eventually there is also option speed=... > Point is that growisofs does *not* set layer break, > if you don't pass -dvd-compat [or -dvd-video] Hmm. That would also make questionable my argumentation about Problem 2. So if growisofs did not issue a layer break position then Gregoire's drive may or may not have Problem 1. But in Gregoire's scripts i do read -dvd-compat. So probably the theory about number 2 still stands. As for scdbackup: I am quite sure that the failed growisofs run for scdbackup was not with -dvd-compat or any other option which causes a fixed size. The growisofs wrapper works fine for sequential DVD-RW where such a setting would cause the same error. Obvious is the relation of error position, error message and size of the plain ISO image. Regrettably i cannot get that user to make more experiments which each eat up one DL media. The problem will have to wait for the next occasion to show up. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi, > _all_ other OS forbid to send SCSI commands > from a normal user account. There are obviously workarounds for that restriction. As soon as the demand occurs i will try to learn. In worst case i would propose some client-server architecture. Another approach would be to create a new interface level inside libburn and to make use of an external MMC library rather than of our own MMC command functions. (I have seen man pages for MacOS describing such a thing.) There would still remain a lot of own functionality above its SCSI oriented source modules mmc.c, spc.c, sbc.c. > Please start explaining why you did not use libscg which grants portability > for software that likes to send SCSI commands to arbitrary targets. That is because the reason for starting cdrskin was my wish to have a CD burn program which has no hostile relationship with Linux kernel people. Zero cdrecord ancestry is a design goal. (We have had enough clones, hadn't we ?) My DVD adventures came only later. It would indeed be worthwhile to implement on libscg an application which makes full use of contemporary DVD specs. But actually, i leave that to you. It is not bad to have multiple burn programs. They allow us to explore drive peculiarities. If only Nero had the politeness to misburn one or two of Gregoire's DVD+R DL. Grrr. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
So the current consolidated theory would be about like this: - Problem number 1: - Problem number 2: - Problem number 3: - Agreed. Let me add another growisofs problem report which i got from a scdbackup user: With DVD+R DL, growisofs seems to read the size of the ISO image and to announce that size for the write run. If scdbackup adds its checksum list and (superstitious) padding, then the write run aborts less than 32 blocks after the end of the ISO image. mkisofs reports: 3916389 extents written (7649 MB) growisofs -Z /dev/...=/dev/fd0 reports: :-[ [EMAIL PROTECTED] failed with SK=5h/END OF USER AREA ENCOUNTERED ON That is 27 sectors after the end of the image (in the the data tail added by scdbackup). 3916389 % 16 = 5 or 32-27, so if recording was folded in the middle of iso image, then 27 would indeed be maximum possible padding (well, it could have been 16-5=11 if amount of ECC blocks in padded image would be even). Question is if above is actually complete growisofs command line? Point is that growisofs does *not* set layer break, if you don't pass -dvd-compat [or -dvd-video], and without it shouldn't be a problem to pad iso image with additional data... In other words, 'growisofs -Z /dev/...=/dev/fd/0' should have actually worked, while 'growisofs -dvd-compat /dev/...=/dev/fd/0' would work as described above. Elsewise i would now advise him to set a maximum manual layerbreak by -use-the-force-luke=break:size Yes. One can even argue that growisofs should recognize break:+size, which would reserve for size padding, as well as break:max... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > Hi, > > > Cdrskin in addition is based on a library that > > is based on specific security "holes" in Linux. > > Could you describe those holes ? I mentioned already: _all_ other OS forbid to send SCSI commands from a normal user account. The only exception is MS-WIN with ASPI (a ISV product) installed. > > Porting it to other platforms will result in insufficient > > privilleges for sending SCSI commands > > So you can predict properties of future > software with yet undefined target operating > systems ? Of course I can predict what will happen if you port to known other OS. I did this port alrready, so I know what I am talking about > > > I am not sure whether the lib is prepared for this. > > You could learn. It is open source. There is a low probabilty that you can learn from software that itself did avoid to learn from other existing implementaions. Please start explaining why you did not use libscg which grants portability for software that likes to send SCSI commands to arbitrary targets. After you did, it may make sense to give futher answers. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Hi, Andy Polyakov wrote: > The unit in question [Gregoire's] obviously crashes (power cycle is > required to bring it back, i.e. reboot of unit) if write request crosses > layer break position. > It sounds as if their [Rob's and CJ's] > units can't handle arbitrary layer break positions and has to be reminded i wrote: > 2086912 - 2086889 == 23 > The failing write command [of cdrecord with Gregoire's drive] > is 31 blocks long and thus touches both layers. Joerg Schilling wrote: > It may be that this has been forgotten in cdrecord's code (it was planned ;-) > if it works with other drives, then other drives do not follow the worst > possible firmware documented by the MMC standard. So the current consolidated theory would be about like this: - Problem number 1: Rob and CJ have drives which do not like any other layer break address than the one which is their default. Thus growisofs and cdrecord fail if their automatically computed layer breaks get set. The remedy is to enforce the drive's default layer break address and override the programs' computations. (This would mean that cdrskin has no problem with those drives. I would appreciate confirmation.) - Problem number 2: Gregoire's drive does not like if cdrecord's 31-block aligned write command touches both layers together by a single write command. It seems not to have a general layer break setting problem, because growisofs with its automatic layer break and its 16-block aligned write commands only fails much after the layer break. (One could verify this therory by aligning the manual layer break to a multiple of 496.) - Problem number 3: Gregoire's drive has a yet obsure problem with drive-media compatibility which shows up with growisofs and cdrskin but not with Nero. I am still clueless what preparations Nero could do to increase that compatibility. If 496-alignment allows cdrecord to cross the layer break, then it would be interesting to see whether it has write errors, too. - Let me add another growisofs problem report which i got from a scdbackup user: With DVD+R DL, growisofs seems to read the size of the ISO image and to announce that size for the write run. If scdbackup adds its checksum list and (superstitious) padding, then the write run aborts less than 32 blocks after the end of the ISO image. mkisofs reports: 3916389 extents written (7649 MB) growisofs -Z /dev/...=/dev/fd0 reports: :-[ [EMAIL PROTECTED] failed with SK=5h/END OF USER AREA ENCOUNTERED ON That is 27 sectors after the end of the image (in the the data tail added by scdbackup). The same growisofs command works well with DVD+R and sequential DVD-RW. So the rigid size curb seems to be a speciality with the handling of DVD+R DL in growisofs. In a further attempt, cdrskin wrote the whole stream to DVD+R DL with no error messages. (The readability of the media was mediocre, though. I/o errors with several payload files. So the user went back to single layer media. Elsewise i would now advise him to set a maximum manual layerbreak by -use-the-force-luke=break:size ) - Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > The "1F" in CDB means 31 blocks are to be written > by this WRITE10 command. > The "1F D7 E9" means write address is 2086889. > (Confirmed by: 4273948672 / 2048 == 2086889) > > The write size of 31 blocks seems systematic: > 2086889 % 31 == 0 > > The man page of cdrecord says: > "The manual layer break value needs to be a mul- > tiple of the ECC sector size which is 16 logical 2048 > byte sectors in case of DVD" > > 2086912 - 2086889 == 23 > The failing write command is 31 blocks long and > thus touches both layers. It may be that this has been forgotten in cdrecord's code (it was planned ;-) if it works with other drives, then other drives do not follow the worst possible firmware documented by the MMC standard. Looks like cdrecord needs some additional code to verify that a write command does not cross a layer boundary. BTW: this is not easy to implement in a clean way! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
fine d Movie separate able.
hot kx zem Pics smash bite often nurse driving her error. k yn j http://tavalonmpm.tripod.com dining existence easy teach leaf wear healthy ill stamp glass knew several connection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem in 'Closing session' with dvd+rw-tools-7.0
I am having a problem burning DVD-Rs on a Pioneer DVR-109 (running firmware version 1.58). The burning process goes fast but it chokes on "Closing Session" without giving any errors. After about 15 minutes or so, the program will exit without any errors but issuing `dvd+rw-mediainfo /dev/dvd` shows the following: INQUIRY:[PIONEER ][DVD-RW DVR-109 ][1.58] GET [CURRENT] CONFIGURATION: Mounted Media: 11h, DVD-R Sequential READ DVD STRUCTURE[#0h]: Media Book Type: 25h, DVD-R book [revision 5] Last border-out at:2045*2KB=4188160 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: reserved/damaged "Next" Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:2257936*2KB Last Recorded Address: 2234063*2KB READ CAPACITY: 2234064*2048=4575363072 Note Last border-out and READ CAPACITY. Normally these values would be same. Something went terribly wrong and I'd say it smells media defect in lead-in area. Note that you're also expected to "provide versioning information, exact command line, exact output generated by the program." A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
mkisofs $OPTS -V $1 $2|cdrecord driveropts=layerbreak=2086912 $COMCD 2086912 blocks = 4076 MiB Track 01: 4075 of 8124 MB written (fifo 99%) [buf 99%] 8.2x.cdrecord: faio_wait_on_buffer for writer timed out. cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 1F D7 E9 00 00 1F 00 write track data: error after 4273948672 bytes The "1F" in CDB means 31 blocks are to be written by this WRITE10 command. The "1F D7 E9" means write address is 2086889. (Confirmed by: 4273948672 / 2048 == 2086889) The write size of 31 blocks seems systematic: 2086889 % 31 == 0 The man page of cdrecord says: "The manual layer break value needs to be a mul- tiple of the ECC sector size which is 16 logical 2048 byte sectors in case of DVD" 2086912 - 2086889 == 23 The failing write command is 31 blocks long and thus touches both layers. Couldn't agree more. The unit in question obviously crashes (power cycle is required to bring it back, i.e. reboot of unit) if write request crosses layer break position. What I'd like to see is dvd+rw-mediainfo output for growisofs recording that failed at 98%. It should be noted that growisofs reserves for possibility of resuming DVD+R DL recording. If file set (or preformatted image) is not changed in any way, then in most cases it would be possible to re-run the exact command and complete recording. I'd also like to see output from beginning of failed growisofs recording... As always... Rob and CJ: what are your magic layer break values which made cdrecord work on DVD+R DL ? As far as I understood the default value reported by unit, the one that would be used if application didn't set layer break position. It sounds as if their units can't handle arbitrary layer break positions and has to be reminded about what it said itself. I don't think it's related... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
