Re: solaris cdrecord BH08LS20 drive BD-R problems
... there is DMA. Even though above is about SPARC Solaris 8 I found no evidence that DMA default settings for ATA would be different on SPARC Solaris 10 and even OpenSolaris for SPARC. The variable atapi-cd-dma-enabled was introduced for Solaris 10. Before _all_ CDs always had no DMA. Given placement of the remark any sane person would assume that it refers SPARC Solaris 10, wouldn't [s]he? Well, the boot variable was introduced in Solaris 10 x86[!] and the variable is Solaris x86 specific! It has no meaning on SPARC Solaris [not to mention that it's impossible to set any custom boot variable with eeprom(sparc)]! In the course of discussion it was also implied that cdrecord's Solaris DMA related READMEs are up-to-date with accuracy of 12 months and apply to *all* Solaris releases. To summarize, the READMEs discuss binary patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. They are as correct as they can be with the feedback from users... Quoting Jörg: Unless this changed during the past 12 month, my information is of course correct and up to date. This remark was also made as reply to my SPARC Solaris [8] *is* capable of DMA. Any sane person would interpret it as Jörg has looked over the information about a year ago and verified that there is nothing to add and patching ata binary driver is still the only way to engage DMA for optical ATAPI unit on Solaris versions =9, both x86 and SPARC. The latter is far from true. 1. Solaris =10 x86 has atapi-cd-dma-enabled (as already mentioned multiple times) 2. It does *not* apply to SPARC Solaris (see below). READMEs are as correct as they are in specific context of Solaris 9 x86! One shouldn't imply [or rather it wrong to imply] anything more than that. patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. I don't recall when Solaris 10 was released, but from my 4 years personal experience with Solaris 10 x86 on Sun W1100z (Opteron-based workstation), it's perfectly possible to Opteron is not sparc... That's why I wrote experience with Solaris 10 *x86*. Then there is enough evidence that the READMEs in question are not applicable to [any recent] SPARC Solaris release. At the very least on SPARC Solaris ATA is implemented by uata driver, which does not even have ata_init_drive_pcidma subroutine. Not to mention above information about DMA *defaults* for SPARC Solaris ATA support. As you could see, my patch is for sparc What my patch is for sparc are you talking about? One found in README.solaris-x86-ATAPI-DMA? If you meant my patch is for x86, then how does it support your argument about DMA default being off on *SPARC* Solaris? and you should know that with Solaris 11 DMA is finally used by default. And so should you, and consequently should not imply that READMEs are perfectly up-to-date. And DMA is *finally* by default on in Solaris 11 x86[!]. On SPARC Solaris it was by default since *earlier*. If you have been able to do something that other people could not do before (using a DVD drive with DMA on a sparc system), it would be nice if you could tell us how you did manage this. I did *nothing*! On the contrary, as mentioned earlier I had to patch uata binary to get rid of DMA! As already stated several times, *DMA is on by default on SPARC Solaris =8* (maybe since earlier, I simply have no data on earlier releases). The setting appears to be negotiated upon uata driver initialization. If DMA ended up off on somebody's system, I would guess that driver failed to negotiate it. Maybe there is jumper on the unit, maybe specific unit is not fully compliant with ATA specification which can be reason for failure. I don't know. But it doesn't mean that one can draw conclusion that DMA is off by default and state Solaris sparc *still* does not support DMA on ATA interfaces. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
If you like to prove that there are Sparc machines with Solaris that behave different from what all other users reported, please send the related information: - exactly describe the machine type, the OS release and the drive type. Information can be found in attachments. Looking through the information does unfortunately not show anything that verifies the presence of DMA for the CD-ROM drive in question. Looking through the *requested* information does not show anything that verifies the presence *or absence* of DMA for the CD-ROM drive in question. SPARC Solaris does not tell a squat about DMA settings in /vad/adm/messages, 'eeprom' or 'prtconf -p' outputs. On the other hand, looking through the information provided *beyond* requested one allows to draw conclusion that DMA is *in fact* enabled for optical drive in question. Once again, target1-dcd-options is 0xa2 and more important read performance reaches 19MBps[!]. Indeed, there is no way venerable Blade-100 can deliver that much over PIO at *portion* of CPU power(*). As for value of 0xa2. Earlier I said that it denotes UDMA-2. As it turns out this was inaccurate. Upper bits, ones constituting 0xa?, do denote UDMA, but lower bits, ones constituting 0x?2, don't denote UDMA *mode*. Lower bits are meaningful when UDMA is disengaged and seem to denote PIO mode. In other words, while not being specific about UDMA mode, the value still tells that UDMA is actually enabled. (*) Well, patching uata driver to avoid DMA in atapi_ routines have shown that same experiment, pread(2) with fixed offset in loop, delivers not more than 2.7MBps at 95% of CPU time! Even though above is about SPARC Solaris 8 I found no evidence that DMA default settings for ATA would be different on SPARC Solaris 10 and even OpenSolaris for SPARC. Unfortunately I have no opportunity to confirm this experimentally. The conclusion is based on once observed target?-dcd-options value on SPARC Solaris 10, comparison of binary code for uata driver in all three releases, and on comparison of source code for Solaris 8 and OpenSolaris. All this naturally doesn't mean that all versions of SPARC Solaris *unconditionally* use DMA with ATAPI, but it's enough to conclude that originating Solaris sparc still does not support DMA on ATA interfaces is not justifiable. In the course of discussion it was also implied that cdrecord's Solaris DMA related READMEs are up-to-date with accuracy of 12 months and apply to *all* Solaris releases. To summarize, the READMEs discuss binary patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. I don't recall when Solaris 10 was released, but from my 4 years personal experience with Solaris 10 x86 on Sun W1100z (Opteron-based workstation), it's perfectly possible to control DMA setting for optical ATAPI unit with atapi-cd-dma-enabled boot parameter and no binary patching is required. This applies even to OpenSolaris for x86 (where it's even properly documented in ata(7d)). Then there is enough evidence that the READMEs in question are not applicable to [any recent] SPARC Solaris release. At the very least on SPARC Solaris ATA is implemented by uata driver, which does not even have ata_init_drive_pcidma subroutine. Not to mention above information about DMA *defaults* for SPARC Solaris ATA support. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: My Pioneer DVR-218L i think is behaving like the LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...
I recently purchased a Pioneer DVR-218L SATA dvd recorder, to replace an old IDE Pioneer recorder. The unit works correctly when burning data, and it works correctly under Windows. But when i tried to burn a Video-DVD under Linux (K3B), it gave me an error in the very end of the recording process. I searched for information, and after a while, I found this: http://www.mail-archive.com/cdwrite@other.debian.org/msg12340.html That thread describes my situation almost exactly, except I own a Pioneer, not LG drive. Here are a couple of debug logs of K3B when failing: http://pastebin.com/f416c99d2 Yes, it appears as similar problem, i.e. recording size is not divisible by 32KB, it's DAO recording and the last write appears timing out. Can you verify if workaround at the end of http://www.mail-archive.com/cdwrite@other.debian.org/msg12357.html helps in your case too? As far as I understand K3b offers DAO as GUI check-box, so you can as well let it be in order to make it work with your unit. Here is the output of dvd+rw-mediainfo /dev/scd1 INQUIRY:[PIONEER ][DVD-RW DVR-218L][1.01] Complete here - http://pastebin.com/f9309400 (with the data of the Verbatim 16X DVD-Rs I used to burn) It's of greater relevance/interest to look at dvd+rw-mediainfo for *resulting* recording, not for blank media. There you should be able to confirm that READ CAPACITY and/or lead-out position are adequate, recording size / 2048 to be specific. Thanks for submission. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Checked it this morning, seems to have finished, and I have no idea how long it took. builtin_dd: 7634768*2KB out @ average 0.2x4390KBps Not faster than 7634768*2/(0.3*4390) seconds. 3 hours 13 minutes at least. Probably rather 4 to 5 hours. Very slow. But at the end a bit too fast for USB 1. So that theory seems invalid, too. USB1 full-speed is 12Mbps or 1.5MBps, right? 0.2x4390KBps is around half the speed... Also keep in mind that if wire speed is not sufficient to sustain media speed, unit will be forced to make idle revolutions and performance can drop to *portion* of wire speed. :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: I/O error Uh oh. It is still ill. It's harmless bug. It was discussed earlier. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
When it comes to accuracy of information meant for general public, it's
difference between implying things and spelling them in manner that
can't be interpreted differently by different people.
1. According to 'man ata' DMA is enabled by default on Solaris 10. To my
experience with Sun W1100z it holds true.
Whis this is true for Solaris 10 x86 and hard disks, it is definitely not
true
for the other.
Original statement was Solaris 10 in general does not by default enable
DMA. Any sane person not intimately familiar with subject would
interpret that Solaris 10 never uses DMA by default.
Well, we are talking about CD/DVD/BluRay writing and it should be obvious for
a
scientist, that remarks are done here with thede constraints in mind.
General public is far from scientific. But even if it was, it would be
even more incentive to stick to most accurate formulations.
I cannot see statements of interest in the rest. If you like to prove that
there
are Sparc machines with Solaris that behave different from what all other
users
reported, please send the related information:
- exactly describe the machine type, the OS release and the drive type.
Information can be found in attachments.
- send information from prtconf -pv
Attached.
- Send the kernel verbose information from /var/adm/messages that
indicate that DMA was in fact enabled for the related drive
Boot log from /var/adm/messages is attached.
- send the eeprom(1) output that indicates that the DMA is not disabled
for CD-ROM type drive even though the low level kernel layers did
set up DMA.
eeprom output can be found in attached 'prtconf -pv' output in Node
0xf002d22c section.
- Send a cdrecord -v -checkdrive output for the drive that verifies
that the drive is capable to do IO in a speed that requires DMA and thus
indicates that DMA is really in effect.
Attached.
-
Now for the rest of subscribers. None of attached information tells DMA
story. As already mentioned on SPARC Solaris (at least up to 10)
negotiated ATA mode can be found in 'prtconf -v' output. Here is
relevant portion from system in question:
ide, instance #0
Driver properties:
name target1-dcd-options length 4
value 0x00a2.
name target0-dcd-options length 4
value 0x00a4.
name dcd_options length 4
value 0x00a4.
Here target0 is system disk and target1 - optical unit. As already
mentioned 0xa2 stands for UDMA-2. This can be confirmed experimentally
by running for example perl -e '$sz=32*1024;
while(1){syscall(173,0,?x$sz,$sz,0)}' /vol/rdsk/noname' against
recorded media and monitoring system with iostat. syscall(173) is
pread(2) and idea is to make unit deliver 1st 32KB from buffer over and
over again. Here is snippet from 'iostat 5' output:
ttydad0 sd0 nfs1 nfs2 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy
wt id
0 16 0 00 19840 62010 000 00 10
11 79 0
0 48 2 12 19847 62010 000 009
11 80 0
0 16 0 00 19885 62110 000 006
11 83 0
0 16 0 00 19834 62010 000 009
12 79 0
sd0 is the optical unit and as per above it delivers almost 20MBps at
~11% system time. Writing naturally can't be performed at 20MBps, but 2x
DVD recording [with growisofs] consumes ~8% system time:
ttydad0 sd0 nfs1 nfs2 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy
wt id
0 78 0 00 2752 9200 000 001
8 26 65
0 78 0 00 2900 9700 000 001
9 27 62
0 78 4 14 2694 9000 000 001
5 28 66
0 47 0 00 2854 9500 000 001
8 28 64
A.
System Configuration: Sun Microsystems sun4u
Memory size: 512 Megabytes
System Peripherals (PROM Nodes):
Node 0xf0029e64
boot-retained-page:
energystar-v3:
idprom:
.......
scsi-initiator-id: 0007
reset-reason: 'POR'
breakpoint-trap: 007f
#size-cells: 0002
model: 'SUNW,375-0096'
name: 'SUNW,Sun-Blade-100'
clock-frequency: 04fca6ea
banner-name: 'Sun Blade 100 (UltraSPARC-IIe)'
device_type: 'upa'
stick-frequency: 0054c563
Node 0xf002cff8
name: 'packages'
Node 0xf0047a58
name: 'SUNW,builtin-drivers'
Node 0xf0051a18
disk-write-fix:
name: 'deblocker'
Node 0xf0051efc
name: 'disk-label'
Node 0xf0052850
iso6429-1983-colors:
Re: solaris cdrecord BH08LS20 drive BD-R problems
USB1 full-speed is 12Mbps or 1.5MBps, right? I am using USB 2.0 ports - 480 Mbps or 60 MBps. I unfortunately have no personal experience with USB storage on SPARC Solaris and can't advice on how to verify if system actually negotiated USB2 Hi-speed for unit in question. My comment was merely about Thomas' calculations. Burning DVDs on the Plextor PX-716UF drive using cdrecord from my Solaris10 (sparc) machine is pretty fast. Yes, but it doesn't exclude possibility that system failed to negotiate anticipated rate for the other unit. Though as just mentioned, I can only speculate on the matter of USB under SPARC Solaris and you should take it as such. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
When it comes to accuracy of information meant for general public, it's difference between implying things and spelling them in manner that can't be interpreted differently by different people. 1. According to 'man ata' DMA is enabled by default on Solaris 10. To my experience with Sun W1100z it holds true. Whis this is true for Solaris 10 x86 and hard disks, it is definitely not true for the other. Original statement was Solaris 10 in general does not by default enable DMA. Any sane person not intimately familiar with subject would interpret that Solaris 10 never uses DMA by default. If it was Solaris 10 x86 does not by default enable DMA for *optical units*, then it wouldn't have been a problem. Extra point if it was complemented with this unfortunately is not properly documented in Solaris 10 manual pages and reference to more descriptive on-line resource (for example Solaris 11 manual page for ata(7d)). 2. 'man eeprom' does not provide any information about DMA settings. Make a bug report against the man page... Original statement was see eeprom(1) in context of Solaris 10 in general does not by default enable DMA. Any sane person not intimately familiar with subject would expect to find additional information in eeprom manual page. She would find nothing there. If statement was eeprom(1) command can be used to examine and modify atapi-cd-dma-enabled variable, then it wouldn't have been a problem (except for questionable relevance, because original question was about SPARC Solaris). Extra point for mentioning that the value might be missing and allowable values of 0 and 1. 3. SPARC Solaris *is* capable of DMA on ATA. To my experience it holds true on Solaris 8 with Pioneer DVR-106: CPU load and performance was adequate in my DVD recording tests and I never had any problems engaging buffer underrun protection. Negotiated settings for every device can be verified with 'prtconf -v'. Solaris 8 definitely does not set up DMA, but Solaris 8 is 10 years old and I do no longer have a machine Original statement was Solaris sparc *still* does not support DMA on ATA interfaces. Any sane person not intimately familiar with subject would interpret still as *whatever* installed on SPARC next to me. Can *you* confirm the statement on *any* SPARC machine with 'prtconf -v'? to check whether I could enable DMA by patching the drivers. The READMEs mentioned above contain instructions on how to patch the ata driver for Solaris 9 (x86), but this unfortunately only works for the original release and will no longer help if you installed an ATA patch. What does it have to do with SPARC Solaris? As mentioned before: Due to the fact that many DVD drives do not allow to set burnproof in case DMA is not enabled, this is a major problem on Solaris/sparc. Is it the only criteria to judge? As mentioned I had no problem [with growisofs] enabling burnproof on Pioneer DVR-106 on SPARC Solaris 8. What do you make of it? If it's not the only criteria, what are others? As a result, I did get a lot of negative feedback from users that have been unable to write DVDs. The only workaround is to use slow DVD-RW media that allows to write slow enough to work without DMA. What units did these users have? What were target?-dcd-options in 'prtconv -v'? If burnproof is the only criteria, is it really appropriate to generalize these experiences to the extent of SPARC Solaris *still* does not support DMA on *ATA* interfaces? As for Solaris DMA related READMEs up-to-date-ness. They contain information exclusively about Solaris 9 x86. I can't verify its accuracy, but I can confirm that atapi-cd-dma-enabled parameter is effective on Solaris =10 x86[!], i.e. no binary code patching is required. They don't contain a word about SPARC Solaris and are not applicable to SPARC Solaris. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
cdrecord: I/O error. read disk info: scsi sendcmd: no error CDB: 51 00 00 00 00 00 00 00 04 00 status: 0x0 (GOOD STATUS) resid: 4 on Fri, 9 Oct 2009 22:12:35 -0400: # dvd+rw-mediainfo /dev/rdsk/c3t0d0s0 ... READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Next Track: 1 Number of Tracks: 1 This time the same SCSI command worked. I also assume it worked in NeroLinux. This is not necessarily the same command.. Cdrecord is implemented in compliance to the SCSI standard. Without knowing whether dvd+rw-mediainfo is implemented compliant to the SCSI standard, It feels ridiculous that I have to say this, but what choice do I have facing FUD? I can assure general public that dvd+rw-media, as well as growisofs, is compliant with SCSI standard (modulo http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html). A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Will dvd+rw-mediainfo work on solaris 10 (sparc) ? It hasn't been tested on SPARC Solaris 10, but ... Andy, thank you for your helpful suggestions. Unfortunately, I could not get dvd+rw-mediainfo to work. It fails on one of the ioctl() calls in Scsi_Command::associate() # dvd+rw-mediainfo /dev/dsk/c4t0d0s0 /dev/dsk/c4t0d0s0: unable to open: Inappropriate ioctl for device As http://fy.chalmers.se/~appro/linux/DVD+RW/ hints, you ought to use character-type device entry. i.e. /dev/rdsk/c4t0d0s0 in this case (note rdsk as opposite to dsk). A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Note that Solaris sparc still does not support DMA on ATA interfaces. It's natural to expect that still means from oldest SPARC Solaris implementing support for IDE through latest, isn't it? Well, I can't speak for oldest and latest ones, but otherwise SPARC Solaris is capable of DMA on ATA interfaces to my knowledge. Negotiated value is reflected in targetN-dcd-options in prtconf -v output. Value of 0x00a2 is common for optical media units and denotes UDMA-2 mode. I am not sure about what you are interested in Accuracy of information provided to the public. As you might know, I send accurate information, so what is your issue? It's not a forum for discussing my issues. If you want to continue discussion, counterargument following: 1. According to 'man ata' DMA is enabled by default on Solaris 10. To my experience with Sun W1100z it holds true. 2. 'man eeprom' does not provide any information about DMA settings. 3. SPARC Solaris *is* capable of DMA on ATA. To my experience it holds true on Solaris 8 with Pioneer DVR-106: CPU load and performance was adequate in my DVD recording tests and I never had any problems engaging buffer underrun protection. Negotiated settings for every device can be verified with 'prtconf -v'. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Thomas, thank you for suggesting dvd+rw-tools-7.1 Will dvd+rw-mediainfo work on solaris 10 (sparc) ? It hasn't been tested on SPARC Solaris 10, but it was tested on SPARC Solaris 8 and x86 Solaris 10 and 11 (latter a.k.a. OpenSolaris). In other words there is no reason to believe that it wouldn't work on SPARC Solaris 10. Naturally provided that your unit generally works with Solaris. I am definitely interested in the capabilities of growisofs. If you're into incremental BD-R recordings, then there is one thing to remember. Media originally recorded by cdrecord won't work for incremental recordings on Solaris. It won't work in the sense that data recorded on later occasions won't be available on Solaris (it should be available on Linux though). In order to make it work on Solaris media has to be formatted for POW (see http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/) and recording has to be treated in special manner (growisofs and xorriso do this, but latter is not available on Solaris). Rule of thumb is if you stick to growisofs, then incremental recordings should work everywhere. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
On a side note for reference. My system is loaded with one of the newer versions of solaris 10 $ uname -a SunOS my_machine 5.10 Generic_139555-08 sun4u sparc sun4u Note that Solaris 10 in general does not by default enable DMA It's natural to expect that Solaris 10 in general covers x86, isn't? Quoting 'man ata' from Solaris 10: Direct Memory Access (DMA) and PCI-IDE Systems Direct Memory Access is enabled by default. To disable DMA ... but you need it for writing. See eeprom(1) eeprom(1) manual page contains no mention of DMA. Note that Solaris sparc still does not support DMA on ATA interfaces. It's natural to expect that still means from oldest SPARC Solaris implementing support for IDE through latest, isn't it? Well, I can't speak for oldest and latest ones, but otherwise SPARC Solaris is capable of DMA on ATA interfaces to my knowledge. Negotiated value is reflected in targetN-dcd-options in prtconf -v output. Value of 0x00a2 is common for optical media units and denotes UDMA-2 mode. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
It won't work in the sense that data recorded on later occasions won't be available on Solaris (it should be available on Linux though). In order to make it work on Solaris media has to be formatted for POW (see http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/) and recording has to be treated in special manner (growisofs and xorriso do this, So Solaris does really not inquire DISC INFO and TRACK INFO to find the superblock ? Correct, Solaris does not inquire this information and consequently non-CD-ROM multi-sessioning is not an option. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrecord floating point exception
The only code that probably could be called free was growisofs, but growisofs at that time was not under GPL (altough the Author claimed so) because commercial publishing was not allowed. Growisofs is now free, but the change to a real free license was made after the complete cdrecord source was published under a free license. dvd+rw-tools were available under same license, GPL, all along, and nothing has changed after the complete cdrecord source was published under a free license. I suppose the above comment refers to http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html. Quoting it: The agreement is not meant to encumber GPL-compliant usage of the sofware in question, for example no explicit permission/license is required, if the same party chooses to download and deploy it internally in their Solaris environment, e.g. for backup purposes, or even re-distribute it under GPL terms. I can assure that this was the intention from the moment of agreement, I believe you that you may have intended to have it be free. The named limitation however caused e.g. Sun to make an agreement with you before Sun started to publish growisofs. So at least Sun also had the impression that the license situation was unclear. If there was an obvious and definitive GPL on growisofs, Sun did just take it. The situation in Germany is definitively that a Judge would take the named limitytion as an expression of will from the author that is wheighted more heavy than the GPL. This is amongst others, because the GPL is a license written by other people. I fail to understand point with these rants. Why do you undertake role of interpreter of an agreement that doesn't concern you? Have you experienced legal problems using dvd+rw-tools? Or do you perhaps represent [or represented at the time] Sun's interests? Have you been asked for an opinion? If yes, how come they asked you and not me? Are you a Judge? Do I need your approval? I bet not. So what is the drift here? Anyway, the above quoted note openly admits that original note was poorly formulated and clarification was provided. I take blame for poor formulation, but [once again] assure that no changes in licensing terms took place at alleged time [or any other time]. Sun indeed contacted Inserve (not me!) and I've got a note about the fact and that Inserve proceeded as agreed. Sun did wonder if notice can be removed from my page, but I left the decision to Inserve. Apparently clarification sufficed. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: dvd+rw-tools 7.1: Compiling problems on new eisfair2
while never having problems to compile on the eisfair1-serverproject I'm unable to compile dvd+rw-tools on the upcoming eisfair2. I got: eisfair2 # make make[1]: Entering directory `/usr/src/dvd+rw-tools-7.1' g++ -O2 -fno-exceptions -D_REENTRANT -c -o growisofs_mmc.o growisofs_mmc.cpp In file included from growisofs_mmc.cpp:17: transport.hxx: In member function ‘int Scsi_Command::is_reload_needed(int)’: transport.hxx:366: error: ‘INT_MAX’ was not declared in this scope make[1]: *** [growisofs_mmc.o] Error 1 make[1]: Leaving directory `/usr/src/dvd+rw-tools-7.1' make: *** [all] Error 2 Eisfair2 depends on Ubuntu 8 having: g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) GNU Make 3.81 glibc 2.7 Is there something missing on my new eisfair2? Note that INT_MAX is not referred in dvd+rw-tools source, CDSL_CURRENT from linux/cdrom.h is. The latter is the problem. Generally header files are expected to be self-contained, in other words it should suffice to include linux/cdrom.h alone to use interfaces described in it. linux/cdrom.h used to be self-contained and one found in glibc-kernheaders package still is, it's pristine kernel header that is not self-contained anymore. It probably should be classified as kernel header bug (as I have no formal way of knowing that a documented macro would require any other particular header). But one way or another, if you ought to compile this very moment, you should be able to 'make WARN=-DINT_MAX=0x7fff'. Cheers. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrecord floating point exception
The only code that probably could be called free was growisofs, but growisofs at that time was not under GPL (altough the Author claimed so) because commercial publishing was not allowed. Growisofs is now free, but the change to a real free license was made after the complete cdrecord source was published under a free license. dvd+rw-tools were available under same license, GPL, all along, and nothing has changed after the complete cdrecord source was published under a free license. I suppose the above comment refers to http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html. Quoting it: The agreement is not meant to encumber GPL-compliant usage of the sofware in question, for example no explicit permission/license is required, if the same party chooses to download and deploy it internally in their Solaris environment, e.g. for backup purposes, or even re-distribute it under GPL terms. I can assure that this was the intention from the moment of agreement, to be specific the moment Solaris support made its appearance in dvd+rw-tools in 2003. The note was indeed updated/clarified in 2006, but once again it has nothing to do with any cdrecord time-frame. Well, it might have been affected *indirectly*, as those who asked for clarification at the time might have been confused by misleading claims just like one in the very beginning of this message. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs won't write double layer DVDs
I recommend you to use cdrecord instead of growisofs.
Cdrecord will tell the drive to do laser power calibration
cdrecord does not do that to DVD+ media.
Wrong: cdrecord of course does a power calibration for DVD+
I thought it bypassed that for DVD+,
It is.
I saw it in the code and can't find
it again. It looked as if a text which fails on DVD+ went around that logic.
Does cdr_opc get set somewhere I'm missing? That could explain why some
media I have don't work well with one burner and cdrecord.
It should be noted that explicit *host-initiated* OPC procedure is *not*
defined for single-layer DVD+ media. Meaning that if you refer to single
layer media, then there hardly is cure (at least not in pure MMC terms).
As it turns out it, host-initiated OPC, is defined for double layer
though and it might make difference...
Christian [and Bill], if you have energy and media to spare, could you
test following:
- download dvd+rw-tools source and unpack;
- copy attached opc.cpp to dvd+rw-tools source catalog;
- change directory to dvd+rw-tools source catalog;
- compile it with 'g++ opc.cpp -o opc';
- load media;
- execute './opc /dev/dvd';
- then *without reloading the media* attempt growisofs recording;
It might be interesting to have a look at verbose dvd+rw-mediainfo
output before and after opc. In other words also execute dvd+rw-medianfo
/dev/dvd -v before and after opc (all *without reloading the media*),
compare them and send them [*if* they are different]. A.
#include transport.hxx
int main(int argc,char *argv[])
{ Scsi_Command cmd;
int err;
if (!cmd.associate(argv[1])) perror(can't open),exit(1);
cmd[0]=0x54;
cmd[1]=0x1;
cmd[9]=0;
if (err=cmd.transport()) sperror(SEND OPC INFORMATION,err);
wait_for_unit (cmd,NULL);
}
Re: growisofs won't write double layer DVDs
Christian, I feel that I have to apologize for Joerg's rude behavior. Cdrecord will tell the drive to do laser power calibration cdrecord does not do that to DVD+ media. Wrong: cdrecord of course does a power calibration for DVD+ LOCAL BOOL ... Interesting that you seem to have time to write this but to not like to support mkisofs. If you really have problems with mkisofs, please make reports in a way that allows to fix them. Joerg, if you want to make personal remark, do it in proper context, or at least have decency to omit originator from explicit Cc: list. It's indeed nothing but rude to flip conversation like this, as if person just ceased to exist. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: mkisofs multi-extent: more bugs
Interesting that you seem to have time to write this This as communicate with growisofs user [and spend 7% of my post to point out misleading statement about cdrecord]? Well, how I dispose my time is my business, but if you have to know it's more important to me to communicate with dvd+rw-tools users. In other words yes, if I have few minutes I'd rather do that. but to not like to support mkisofs. I don't understand... You have time ... to not like support mkisofs? Like have time to dislike doing something [without actually doing it]? No, I don't have time for such things either and don't do that. Or was it *do* not like [*to*] support mkisofs? Is it my job to support it? I spend several hours on bug hunting and this is thanks? Well, thanks for encouraging words! If you really have problems with mkisofs, In a spirit of personal remarks I personally don't really have problems with mkisofs. I personally use home-patched version at my own discretion and don't really have problem with this. please make reports in a way that allows to fix them. As I already said I'm *sorry* I can't do better, primarily because of lack of time. I'm ready to answer specific questions [but not about form of my report], if they don't take very much time [minus time I've spent reflecting over the remark and writing this], but I don't have time to reformulate my report[s]. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs won't write double layer DVDs
I'm trying to write double layer DVDs on my TS-L632C DVD burner. It has always handled single layer DVDs fine and this is the first time I have a problem. What I get is this... Executing 'mkisofs -dvd-video -V DVD /home/abc/dvd | builtin_dd of=/dev/sr0 obs=32k seek=0' Setting input-charset to 'UTF-8' from locale. 0.17% done, estimate finish Thu Jan 1 13:43:04 2009 0.35% done, estimate finish Thu Jan 1 13:43:04 2009 0.52% done, estimate finish Thu Jan 1 13:43:04 2009 /dev/sr0: splitting layers at 1437552 blocks :-[ SEND DVD+R DOUBLE LAYER RECORDING INFORMATION failed with SK=3h/POWER CALIBRATION AREA ERROR]: Input/output error growisofs still does not write completely readable error messages :-( This is an opinion. The fact is that whether or not and when power calibration is performed is left to firmware discretion. Not refers to fact that firmware might choose pre-defined profile. And when on the other hand varies from firmware to firmware, some firmware start the calibration procedure at a WRITE command, others at SEND DVD STRUCTURE with DVD+R DL layer break position. As result power calibration errors get accounted to either of these commands. Christian, as for error interpretation and advice, see Thomas' post. I recommend you to use cdrecord instead of growisofs. Cdrecord will tell the drive to do laser power calibration cdrecord does not do that to DVD+ media. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs won't write double layer DVDs
Cdrecord will tell the drive to do laser power calibration
cdrecord does not do that to DVD+ media.
Wrong: cdrecord of course does a power calibration for DVD+
LOCAL BOOL
do_opc(scgp, dp, flags)
SCSI*scgp;
cdr_t *dp;
UInt32_t flags;
{
if ((flags F_DUMMY) == 0 dp-cdr_opc) {
if (debug || lverbose) {
printf(Performing OPC...\n);
flush();
}
if (dp-cdr_opc(scgp, NULL, 0, TRUE) 0) {
errmsgno(EX_BAD, OPC failed.\n);
if ((flags F_FORCE) == 0)
return (FALSE);
}
}
return (TRUE);
}
So it's up to [non-NULL!] dp-cdr_opc. And what's dp-cdr_opc for DVD+
media?
grep OPC drv_dvdplus.c
(int(*)__PR((SCSI *, caddr_t, int, int)))NULL, /* no OPC */
(int(*)__PR((SCSI *, caddr_t, int, int)))NULL, /* no OPC */
(int(*)__PR((SCSI *, caddr_t, int, int)))NULL, /* no OPC */
A.
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
mkisofs multi-extent: more bugs
As per http://lists.debian.org/cdwrite/2008/07/msg00078.html and
http://lists.debian.org/cdwrite/2008/07/msg00082.html 6 (six) a=40
multi.c bugs were reported:
#1. end-less loop [or premature exit from it] in read_merging_directory;
#2. incorrect merge of extents from previous session [generated by
alternative iso9660 formatter];
#3. files or extents are omitted from multi-session recording due to
incorrect value returned by read_merging_directory;
#4. failure to sort merged directory because of insufficient clean-up in
check_prev_session;
#5. failure to sort merged directory if multi-extent files share same
iso9660 name;
#6. apparent memory leak in check_prev_session;
Of these 6 bugs two were fixed, #1 and #4, and one, #3, kind of fixed.
Kind of means that the problem as it was spelled in the problem report
was resolved, but the thing is that affected procedure uses the return
value itself and modification let it use wrong value. See below for
further details. Rest of the problems were left without attention.
For reference, here is how to reproduce #5:
1. touch 5G; perl -e 'truncate(5G,5*1024*1024*1024)'
2. ./mkisofs -iso-level=3 -R 5G a.iso
3. mv 5G 5g;
4. ./mkisofs -C X,Z -M a.iso -iso-level=3 -R 5g /dev/null;
which results in fatal failure:
Using 5G000.;1 for /5G (5g)
./mkisofs: Error: '/5G' and '5g' have the same ISO9660 name '5G.;1'.
./mkisofs: Error: '/5G' and '/5G' have the same Rock Ridge name '5G'.
./mkisofs: Unable to sort directory
Further bugs.
#7. './mkisofs -iso-level=3 -T 5g' is aborted with *** glibc detected
*** double free or corruption. core file analysis reveals that fatal
condition is raised in free called from sort_n_finish (there is only one
free call in sort_n_finish). This is because dup_directory_entry does
not duplicate -table member, and therefore the latter is bound to be
double-freed.
#8. Once #7 is resolved './mkisofs -iso-level=3 -T 5g' completes, but
TRANS.TBL comes out bloated with duplicating entries: one entry per
recorded extent instead of one per whole multi-extent file.
#9. Once #8 is resolved, multi-extent names and names of last file[s] in
current directory are found to be omitted from TRANS.TBL from
multi-session recording with -T flag. Multi-extent names are omitted
because only super directory entry is processed by
read_merging_directory, and as it's marked with INHIBIT_ISO9660_ENTRY
it's never nominated for TRANS.TBL. Single-extent files can be omitted
from TRANS.TBL because of skewed fix for bug #3 (see above).
Attached patch relative to a53 addresses remaining and new problems.
In tree.c:
- vicinity of lines 573 and 713 - #8;
- vicinity of line 2403 - #7;
In multi.c:
- vicinity of line 805 - #3 and #9;
- vicinity of line 918 - #9;
- vicinity of line 943 - #3;
- vicinity of lines 1090 and 1148 - alternative solution to #2 based on
copying of actual extents from previous session, not partial information
from them, as well as #6;
- vicinity of lines 1357 and 1398 - #5, code was submitted earlier and
its purpose is to maintain expected list order;
- vicinity of line 1869 - #6;
On related note to original report. tree.c also has inconsistencies
between usage of USE_LARGEFILES and multi-extent support. A.
--- ./mkisofs/tree.c.orig 2008-09-11 16:01:02.0 +0200
+++ ./mkisofs/tree.c 2008-12-11 10:56:10.0 +0100
@@ -573,6 +573,12 @@
#endif /* APPLE_HYB */
if (s_entry-de_flags INHIBIT_ISO9660_ENTRY)
continue;
+ /*
+ * In every ISO_MULTIEXTENT chain last entry
+ * is the only one without the flag.
+ */
+ if (s_entry-isorec.flags[0] ISO_MULTIEXTENT)
+continue;
if (s_entry-table) {
/*
* Max namelen, a space before and a space
@@ -713,6 +719,12 @@
if (s_entry-de_flags INHIBIT_ISO9660_ENTRY)
continue;
/*
+ * In every ISO_MULTIEXTENT chain last entry
+ * is the only one without the flag.
+ */
+ if (s_entry-isorec.flags[0] ISO_MULTIEXTENT)
+continue;
+ /*
* Warning: we cannot use the return value of sprintf
* because old BSD based sprintf() implementations
* will return a pointer to the result instead of a
@@ -2403,6 +2415,8 @@
s_entry1-name = e_strdup(s_entry-name);
if (s_entry-whole_name)
s_entry1-whole_name = e_strdup(s_entry-whole_name);
+ if (s_entry-table)
+ s_entry1-table = e_strdup(s_entry-table);
#ifdef APPLE_HYB
/*
* If we also duplicate s_entry-hfs_ent, we would need to change
--- ./mkisofs/multi.c.orig 2008-08-28 23:06:34.0 +0200
+++ ./mkisofs/multi.c 2008-12-11 11:02:06.0 +0100
@@ -76,7 +76,7 @@
LOCAL void free_directory_entry __PR((struct directory_entry * dirp));
LOCAL int iso_dir_ents __PR((struct directory_entry *de));
LOCAL void copy_mult_extent __PR((struct directory_entry *se1,
- struct directory_entry *se2));
+ struct directory_entry *se2[]));
LOCAL void merge_remaining_entries __PR((struct directory *,
struct directory_entry **, int));
@@ -805,6
Re: Growisofs input cache -- Patch
In the mean time I created a patch for growisofs which I hope will be included in the future (see attachment). *If* such option will be added, it would go as -use-the-force-luke option, not straight one. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
cmd.timeout(180); Recompile and retry recording. If it still times out, try to increase to say 300. I tried it - no better. I just have to wait longer for the Error to occur. With 300 growisofs is writing: 587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0% for approximately 5 Minutes, then Kernel logs the link reset and I get the error. As you might have imagined timeout value is expressed in seconds, which is why you have to wait 5 minutes. One interesting thing: The drive blinks for about 1-2 minutes after the first 100%-line. Then it comes short into action (noise like spin up/down) and the LED on the drives goes out. It seems to have finished. I does mean that it finished. But you have to wait for another few minutes until growisofs stops with error. As said above, kernel messages also appear only at the end of the wait time. There is only one conclusion one can draw: your firmware apparently hangs in last non-padded write command. It might be that it would hang in recording modes other than DAO, but growisofs won't exhibit it, because it pads data to nearest ECC block boundary in all recording modes, but DAO. For this reason the problem is described as LG GH20NS10 might hang at the end of DVD-R[W] DAO recording at http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html. For my reference could you submit first line of 'dvd+rw-mediainfo /dev/scd0' output? It contains INQUIRY result. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Growisofs input cache (get away from dd?)
not passing multiple GB of once-used data through the system buffers and blowing everything else out. I see some effects which could make the O_DIRECT approach less superior to normal reading than your scenario would let expect: O_DIRECT is not about superior performance, it's more about *maintaining adequate _overall_ performance* in wider range of practical situations, most notably under low memory conditions. - If the (ISO) image is freshly generated then the formatter program just blew out everything else anyway. Not if it used O_DIRECT too:-) And for the ISO formatter it makes few sense to read O_DIRECT as it has a random access pattern on eventually small files. It's not about size of individual files, but *sum* of their sizes. Also, if you generate image file (as opposite to immediately burning it out), you double the pressure on block cache as kernel would like to cache both files you've read and recently generated portion of the image. - The cache area in RAM is nowadays quite large and i understand that the least recently used cache chunks get thrown out. While a growisofs read chunk is ageing in the cache for several seconds, any busy process can refresh its own chunks' read time. So i expect that the cache of growisofs' input stream can only blow out chunks which are as fewly used as its own chunks. Right. And if you wanted to record same image again you'd have to start pulling data from disk *anyway*. So why put any pressure on block cache? Why even create the situation when not-busy-enough processes would have to fight for their memory when it can be avoided altogether? Note that [not-so-]busy process would have as many meanings are there are users. I have one use case, though, where i burn two identical copies of the same DVD image for redundancy reasons. One-by-one via a single burner drive from an image file on disk onto 16x DVD+R. Even then i experience no undue impact on other processes. I also never noticed a difference when i switched from growisofs to my own programs for that. Meaning that O_DIRECT is not worse (modulo specific and rare situations like one in originating report), so why the fear?-) Is there a realistic scenario where O_DIRECT is reproduciblrye superior to normally buffered reading ? As implied low memory condition on interactively used system. It's commonly hard for developers to reproduce [and sometimes even understand the problem], as they tend to end up with systems sized above average. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One for DVD+RW/hcn.html
dvd+rw-format should have used Format Type 1, Spare Area Expansion, But the drive does only offer 0x00, 0x30, 0x31 with READ FORMAT CAPACITIES. But it does not necessarily mean that you can't compose one yourself. As already mentioned previously, BD-R[E] format descriptors are more like guidelines anyway. In other words it's worth a try... At least provided if Formattable Feature says it's supported... None of my DVD drives offer 0x01 with DVD-RAM. For reference I get: INQUIRY:[MATSHITA][BD-MLT SW-5582 ][BZE6] GET [CURRENT] CONFIGURATION: 0023: 0f 00 00 00 00 00 00 00 Mounted Media: 12h, DVD-RAM READ FORMAT CAPACITIES: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2217248*2048=4540923904 01h(800): 2226976*2048=4560846848 It should be noted that specification says that data in feature 0023h refers to BD-RE and BD-R formatting options. So that formally one shouldn't consider it in DVD-RAM context. But most importantly number of Format Type 1 format descriptors can vary for particular DVD-RAM disc. E.g. if I format with -ssa=none I get *8* of them afterwards, and *none* after -ssa=max. I get two above listed after -ssa=default. Could you test -ssa=none and submit format descriptors for reference? Could you submit dvd+rw-mediainfo /dev/cdrom -verbose output? INQUIRY:[HL-DT-ST][BD-RE GGW-H20L ][YL03] GET [CURRENT] CONFIGURATION: 0023: 09 00 00 00 00 00 00 00 As mentioned above I get 0f, i.e. full set of RENoSA, Expand, QCert and Cert. It definitely makes sense to try composing Format Type 1 descriptor for Panasonic unit. To summarize. It's more than appropriate to look at feature 0023h and at least not pass subtype 2, the one originally causing trouble with this unit, if QCert is not present. So it's hardly case for hcn.html, as dvd+rw-format is not in full compliance with specification, which will have to addressed in next update. Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Growisofs input cache (get away from dd?)
First of all as for dd. Reference to dd in growisofs output is purely historical artifact: 1st growisofs version was nothing but a front-end to mkisofs and dd, and as such was even dependent on specific kernel DVD+RW support. But since version 2 growisofs is no longer dependent on dd nor explicit kernel support. So forget about dd:-) In your situation i would test whether removing O_DIRECT solves your problem and eventually ask Andy for taking your results into respect. For reference. O_DIRECT makes perfect sense in vast majority of cases. Indeed, DVD images are commonly larger than amount of RAM in end-user system, which in turn means that sequential access to the image is bound to be non-cached, or has to be physically performed anyway. Simply because by the time you are reading end of image, block cache allocated for its beginning is lo-o-o-o-ong evicted. As growisofs [=6.0] has internal ring buffer [acting as read-ahead in image burn case], the memory that would be allocated, evicted, reused for block cache for iso image is really better spent elsewhere. Of course if you access *same* iso image by several instances of growisofs at approximately *same* time, then it makes perfect sense to cache the data and minimize physical I/O. In other words O_DIRECT would indeed make more harm than use. But this is very specific and *rare* situation, so it shouldn't come as surprise that specific tuning might be due... I have made a patch which removes the O_DIRECT code completely (it is only used when opening image files anyway). I will try it out tomorrow and provide the patch if the test was successful. There is a way to open image without O_DIRECT and without modifying source code: growisofs -Z /dev/cdrom=/dev/fd/0 image.iso. Ta-dah... There are other things to think about. Most notably. Default ring buffer size in growisofs is 32MB. For optimal performance one has to make sure that sum of these buffers, plus buffer cache large enough to accommodate possible start time differences times recording velocity, plus memory of other programs essential for well-being of the system during recording, all these fits into RAM. You might find yourself in need to reduce growisofs buffer size to make it fit. Or you might have to consider adding more RAM to sustain that many simultaneous high-speed recordings... A. P.S. Always provide versioning information. There were specific bugs that affect performance in similar situations. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Executing 'builtin_dd if=test2.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: FEATURE 21h is not on, engaging DAO... /dev/scd0: reserving 286877 block, warning for short DAO recording Does it fail in same way if recording is larger than 750MB, preferably ~1GB? Maybe a bad example. But I tried it explicitely with 0.5GB, 1GB and 1.5GB. Every time the same. In further testing I focused on the 0.5GB because it's faster ;-). So the short DAO recording is definitely not the problem. Understood. :-[ [EMAIL PROTECTED] failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error :-( write failed: Input/output error -- at the same time, kernel logs: - [ 6030.669547] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 6030.669568] ata2.00: cmd a0/01:00:00:00:80/00:00:00:00:00/a0 tag 0 dma 32768 out [ 6030.669570] cdb 2a 00 00 01 db 40 00 00 0e 00 00 00 00 00 00 00 [ 6030.669573] res 40/00:03:00:00:80/00:00:00:00:00/a0 Emask 0x4 (timeout) It apparently times out, which is basically why I thought of Short DAO recordings. Could you test following. Open growisofs_mmc.cpp in text editor, locate line that reads cmd.timeout(dao_toggle?180:60); Modify it as cmd.timeout(180); Recompile and retry recording. If it still times out, try to increase to say 300. For your question about the kernel-Log in later mail: As far as I remember, the kernel output belongs to this recording, but I'm not 100% sure. If you think it's important, I will test it again. Well, I'd bet the values are from different recordings, because discrepancy is simply insane. It's as important as to maintain sanity:-) As long as I'm the only one with this problem, an official patch or commandline option would be overstated. I was thinking about patching the code for myself (maybe buying a new drive would be less effort ;-) ): Just round tracksize up to the next 32k-Block in adding something like tracksize=(tracksize+DVD_BLOCK-1)/DVD_BLOCK * DVD_BLOCK to the lines: tracksize = dao_size ? (dao_size*CD_BLOCK) : sb.st_size; and tracksize=from_733(descr-volume_space_size)*CD_BLOCK; Do you think, that's too crude, even for a personal patch? Too complicated:-) Open growisofs_mmc.cpp in text editor and locate function named minus_r_reserve_track. In the beginning it reads if (is_dao) dao_blocks = blocks; Replace this line with if (0) dao_blocks = blocks; A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One for DVD+RW/hcn.html
First of all, thanks for the test. I'll look into results later on... Meaning that I probably should stop implying that expanding ssa is a reliable operation... It is quite optimistic to hope for data survival over a FORMAT UNIT command. :)) But as you could see yourself it actually works:-) Either way, there was an oversight from my side: dvd+rw-format should have used Format Type 1, Spare Area Expansion, which actually specified to preserve defect list and therefore recorded data intact. With sub type 2 i get a zillion Z characters on the media. (Probably because of the snooze slow formatting speed.) Yes, it test-writes the whole media. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One for DVD+RW/hcn.html
Thomas, INQUIRY:[HL-DT-ST][BD-RE GGW-H20L ][YL03] Could you submit dvd+rw-mediainfo /dev/cdrom -verbose output? With BD-RE media in? For reference, I want to see feature list appearing in GET [CURRENT] CONFIGURATION paragraph. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One for DVD+RW/hcn.html
Hi, i got one for your hcn.html Thanks. To clarify... INQUIRY:[HL-DT-ST][BD-RE GGW-H20L ][YL03] This drive does not like format type 0x30 with sub type 3 Quick Certification. Only sub type 2 (i.e. full formatting) works ... and needs 4900 seconds. As dvd+rw-format currently insists on subtype value 2 or 3, then the only way around it would be to complement command line with -force=full. Is this correctly understood? This in turn would mean that there is no way to expand ssa without leaving already recorded data intact. Indeed, 2 wipes all the data, while 0 and 1 - wipe the defect list, thus indirectly affecting data suffered from media defects. For reference, the whole idea behind having 3 as default was to permit ssa expanding without affecting recorded data. Well, one can actually argue that specification does not guarantee that data suffered from media defects is not affected even by subtype 3. Indeed, it says that defect clusters will be re-certified and if they get re-certified as good, then it's likely to mean trouble. Meaning that I probably should stop implying that expanding ssa is a reliable operation... Format type 0x00 works and needs about 30 seconds. So that dvd+rw-format -force with already formatted media would still work, i.e. without -ssa, which implies default descriptor a.k.a. format type 0x00. Is this correctly understood? Could you test if format type 0x30 and subtype 0 works for your unit? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
On a second look I couldn't help noticing another strange thing. I have a problem with my SATA-drive LG GH20NS10 (actual firmware EL01, same with old firmware) and growisofs (7.1): If I try to burn a DVD-Image on a DVD-R (or quick-blanked DVD-RW) in DAO-Mode with a size not divisible by 32kB, writing stops after the last complete 32kB-Block and I get an write error: growisofs -dvd-compat -Z /dev/scd0=test2.iso Executing 'builtin_dd if=test2.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: FEATURE 21h is not on, engaging DAO... /dev/scd0: reserving 286877 block, warning for short DAO recording [...] [repeating] 587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0% :-[ [EMAIL PROTECTED] failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error :-( write failed: Input/output error -- Given reservation for 286877 blocks and failing LBA value one would expect failing command block to be 2a 00 00 04 60 90 00 00 0d 00 ... While what we see in kernel log cdb 2a 00 00 01 db 40 00 00 0e 00 00 00 00 00 00 00 I.e. neither address value or number of blocks don't match expected value Is it really for same recording? Or is it just an example from another one? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
It's just that last- and first-session mounts will be equivalent. Apparently we have to rewind the discussion a bit, because there is one thing I said/implied that was *wrong*. Sorry. Rewind backwards to the question about if BD-R is like DVD+R. I said yes, with POW twist and then discussion went on to multi-sessioning and I erroneously implied that all BD-R recordings performed by growisofs are multi-session. Only SRM and SRM-POW recordings are, SRM+POW recordings are *not*. SRM+POW recordings are multi-track, but not multi-session. Meaning that even multi-session aware OS will look for volume descriptor at LBA#16 for SRM+POW recording. What I implied was that multi-session aware OS would look for volume descriptor in the last recorded increment, while none multi-session aware one - at LBA#16, which is wrong. SRM+POW recordings *performed by growisofs* appear single-session to all OSes. There was a number of factors affecting this decision and I reckoned this is the most reliable/sensible way to make whole data accessible in widest range of OSes [modulo possible bugs]. There are other possible working options, but the SRM+POW method implemented by growisofs appeared, once again, *most sensible*. Yes. And thus the real first session will not be mountable because its volume descriptors are overwritten. We simply seem to assign different meanings to mountable in the context. To me mountable is mere validity/sanity of volume descriptor and to you is access to first recording. Let's call it muted instead, in which case answer is yes, 1st recording will become muted. Sanity is restored. First session effectively grows and it has nothing to do with drive recognizing multi-session. So you leave the track open ? No. But I leave session open in SRM+POW (as implied in the beginning). I assumed you fork a new track, write the session, use POW to patch LBA 0 to 31 and then close the track. Right. Except that considering rant in the beginning it might be more appropriate to refer to recording as increment, not session, in SRM+POW context. With overwriteables i write the first session to LBA 32 Cool. You can do this easily with mkisofs too: -C 0,32 (but no -M) Just start writing at LBA 32 and do the LBA 0 patching when the session is done. More is not needed. Cool. Well, maybe a dvd+rw-toc command. xorriso would do that for growisofs too. It has an alias name especially for that: export MKISOFS=xorrisofs growisofs -Z /dev/dvd /some/files growisofs -M /dev/dvd /more/files Emulation of -C goes up to the -C 16,x bug. :)) Even incremental backups are possible: growisofs -Z /dev/dvd -- outdev - -update_r /my/files /files growisofs -M /dev/dvd -- outdev - -update_r /my/files /files (Btw: would it be possible to lift the ban on options like -outdev, -overwrite, -options_from_file, ... ? They all are mistaken for -o.) Cool. I have to consider it... other sessions would have to be identified by looking at track start addresses instead of volume size round ups. I assume there is a regular pattern of gaps between two sessions. For reference, according to READ TRACK INFORMATION end of any given track coincides with start of next one. Though it (end of track) does not necessarily coincides with the end of recording. I don't seem to have data on sessions... I should have, I'll look... And even if not: one can scan for ISO 9660 heads quite effectively. Rounding up to BD cluster size would also be appropriate. A remark about http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/ Your text can make the reader believe that POW consumes Spares. But it messes up the logical address space instead. (If you write to an orphan then you create a new orphan. Cough.) MMC-5 4.5.3.5.4.1: When a SRM disc has the POW capability, the Logical Overwrite of a Cluster is redirected to the NWA of some open Logical Track Only information about the redirections is stored in the Defect List. Busted on spot! To my defense I can only say that it does say in the beginning that it's somewhat less organized notes:-) But to be serious the page was never meant to be a 100% accurate technical description and I deliberately avoided going into very deep details. It admittedly can create such impression, but it does not actually say it, does it? It says that Spare Area is required for SRM+POW and is used to support POW. And it *is* used, because at least the defect list resides in the Spare Area, i.e. consumes it. But either way, yes, your remark is perfectly correct and I do appreciate it. I just hope more people do:-) Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
SRM+POW recordings are *not*. SRM+POW recordings are multi-track, but not multi-session. Meaning that even multi-session aware OS will look for volume descriptor at LBA#16 for SRM+POW recording. [...] I leave session open in SRM+POW [...] appropriate to refer to recording as increment, not session, in SRM+POW So it is very similar to our layouts on overwriteable media. Except that the NWA is prescribed by the new track and not at the discretion of the burn program. (MMC advises to use the track provided NWA in 4.5.3.6.9 The Expanding Orphanage.) Yes. I have to split the meaning of Session for clarity. There are no MMC-sessions on overwriteables and on BD-R+POW (as written by growisofs). But there are ISO-sessions or Volumes which get generated as if they were to be appended to MMC-multi-session media. (This stems from ISO 9660 on CD-R, after all.) Right. I plead for keeping the ISO-sessions distinguishable in order to allow to mount the older states of the (pseudo-)multi-session media. ... I'll definitely consider all the suggestions. --- For reference, according to READ TRACK INFORMATION end of any given track coincides with start of next one. Now this is a riddle. From where did POW take the clusters which replaced the old LBA 0 clusters ? Presumably from past the end of user data. The specs say the Logical Overwrite of a Cluster is redirected to the NWA of some open Logical Track. A SRM disc with POW shall be initialized by the formatting process as a single session disc with a single Logical Track. The latter statement seems to forbid your track structure. Duh ? No. It only says how it should be *initially* formatted, but says nothing about that it shall stay that way for eternity. Anyway. If there is only one open track then the cluster had to be taken from its NWA. After transfer of iso-formatted volume NWA is at its end, right? When LBA 0 is overwritten, space is borrowed from NWA, which increments[!] NWA. *Then* current track is closed. So next track's NWA starts at cluster past borrowed space and no avalanche takes place. But [as mentioned earlier] end of track does not necessarily coincides with end of recording, iso-formatted volume in this case. If you start the next track and inquire its NWA then i'd expect it skips the orphaned cluster address. It does. If it would use the orphan LBA for the start of a sequential write, then an avalanche of orphans would hit the Defect List. POW-aware recording program is expected to check on NWA after every write and handle its changes accordingly. In growisofs case single check in the beginning of recording suffices. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
maybe you missed the _point_ of the riddle Indeed. I was not aware of that. Did you post the READ FORMAT CAPACITIES: of a dvd+rw-mediainfo run on such a media ? I remember to have seen some which report unformatted as state and offer some formatting descriptors. (None with 4 GB, though.) No, but BD-R[E] format capacity descriptors are more like guidelines. Specification permits you to specify any value between minimum and maximum (which you find among descriptors returned by the unit) with granularity of 256 clusters. Indeed, here is output for media formatted with -ssa=4G: INQUIRY:[MATSHITA][BD-MLT SW-5582 ][BZE6] GET [CURRENT] CONFIGURATION: Mounted Media: 41h, BD-R SRM+POW Media ID: PHILIP/R02 BD SPARE AREA INFORMATION: Spare Area:999424/1998848=50.0% free POW RESOURCES INFORMATION: Remaining Replacements:16843040 Remaining Map Entries: 0 Remaining Updates: 0 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: empty Next Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 10220544*2KB Track Size:10220544*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 10220544*2048=20931674112 Compare to descriptors offered for blank media: READ FORMAT CAPACITIES: unformatted: 12219392*2048=25025314816 00h(3000): 11826176*2048=24220008448 32h(0):11826176*2048=24220008448 32h(0):5796864*2048=11871977472 32h(0):12088320*2048=24756879360 Note READ CAPACITY return value being off by ~4GB from unformatted. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
When it is finished you can definitely tell where the burn approached the scratch and kind of skipped over it and moved to the next viable area. Interesting. How did it know in advance where the bad sectors are before trying to write to them ? But how did you manage to engage Defect Management ? Did i miss the solution of the formatting riddle ? The way I understand the problem, you will not get benefits from setting up spare areas for a BD-R that is written in a single shot. This is wrong understanding. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
Releases turned to be feature driven lately and as no new features were required (e.g. HD-DVD was dismissed) I had no immediate plans so far. But as option to specify TDMA allocation is of apparent interest, it might be appropriate to consider release in foreseeable future, i.e. from week to month. Ok, I'll try to keep my eyes open for it. Do you do an announce on this list? Yes. [Don't kill the messenger...] Yes. The real problem is that we don't know how TDMA is used exactly and therefore it's hard to judge if it's excessive or not. It surely varies from application to application and it might be that for your purposes (I assume you pretty much fill the media up at once) it's absolutely excessive. Best is to ask vendor for recommendation. I can't say for anyone else, but in my case, I would say that half is excessive. Which is why I said that option to specify TDMA reservation size is of *apparent* interest ;-) A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
Is my impression right that their sequential personality is much like DVD+R ? Yes, but with optional +POW twist (see my Blu-ray page). My understanding from specs is that it is Defect Management. I.e. the drive will write a portion of its buffer to media. Then it will checkread as long as the data is still in the buffer. If a read error occurs, then it will take relocation measures and write the content again from buffer to Spare Area. The checkread usually cuts write speed by half. Correct. Did it examine the blank media for damages ? No, BD-R can't do that. Prior verification or how they call it full certification can be applied to BD-RE only [naturally]. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
But doesn't the POW gesture make session 1 unmountable as soon as a further session is recorded ? ??? Why should it? It's just that last- and first-session mounts will be equivalent. Even on a drive which would recognize and handle multi-session ? First session effectively grows and it has nothing to do with drive recognizing multi-session. As you hinted yourself, -o sbsector=16 works even when drive handles multi-session. Accessing older sessions is helpful with incremental backups. Then you want to format for SRM-POW (SRM minus POW, i.e. *without* POW), in which case it will behave exactly as multi-session write-once. As mentioned on the page SRM+POW is chosen as default to maintain broadest accessibility by making all the data available even in non-multi-session aware OSes. With overwriteables i write the first session to LBA 32 and do the patching of LBA 0 to 31 already with that first session. An interested reader can mount -o sbsector=32 and thus access session 1 even if LBA 0 to 31 gets overwritten later. Cool. All other sessions can easily be found by our NWA rounding (you 16, me 32). They form a nice chain. I could imagine that this would work with BD-R POW too. Yes it would. Except that other sessions would have to be identified by looking at track start addresses instead of volume size round ups. Hopping over the orphans will make scanning for sessions more cumbersome. This would apply to drives which would need your POW patching. Drives don't need it! Some OSes would. Or I misunderstood the question, in which case please rephrase. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
I am trying to make the spare area of a BD-R be something larger than the default. I was hoping to run something like: ./dvd+rw-format -ssa=4G /dev/dvd But when I execute this command, it says that it is invalid for the detected media. This is not intentional. In other words it's a bug and it will be looked into. Suggested code modification might be appropriate, but I'd rather not say it without double-checking. In a course of few days. The source code change mentioned in originating post is correct and will be included [though in modified form] to next dvd+rw-tools update. After making the above change, it then gets past this portion of the code and gets down to where the actual formatting is going to take place. I get this message: sr0: CDROM (ioctl) error, command: Test Unit Ready 00 00 00 00 00 Deferred sr00:00: sense key Medium Error Additional sense indicates Format command failed This I can't reproduce. In other words I managed to format BD-R disc with -ssa=4G, i.e. unit succeeded to format it with ~4GB spare area. Have you managed to record BD-R in this particular unit at all? Same question about BD-RE? What I'm trying to say is that the unit might simply be broken... Another option is a kernel bug, maybe in SATA support (as you mentioned it's SATA connected). Have you managed to record a DVD? Side note about spare area capacity. There is something they call TDMA, Temporary Disc Management Area, residing in Lead-In. As you allocate spare area, part of it will be reserved for *additional* TDMA regions. Relevant question is what part of it? MMC specification says that default value is up to vendor and in Panasonic case it seem to be 1/2 of spare area capacity. This means that if you ask your unit for spare area utilization data right after format, you'll see that 1/2 of it is already used. Well, it's not actually used, but reserved for TDMAs. Whether it's excessive or not, time will show. Meanwhile I'm considering adding extra option to dvd+rw-format, which would allow you to specify which portion of spare area will be reserved for TDMA. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Now I have to write a little wrapper script for growisofs to add -use-the-force... to the command line generated by the frontend. Did you try whether growisofs does not use DAO automatically if the media is blanked fast ? You cannot reliably ask whether the media was blanked fast. It doesn't mean that you can't try. If given firmware tells difference between minimally and fully blanked media, then it tells you that *every* time, i.e. reliably. In other words it's one-time test for user, then [s]he knows that it works reliably or does blank=fast works only correctly if the medium was written on SAO mode before. I can't second this. To start with there is no such thing as SAO in DVD-R[W] context. SAO is a CD recording mode, which means that unit records session lead-in prior user data. There are only two DVD-RW Sequential recording modes: DAO and Incremental. In latter mode structures describing track structure for given recording are written *after* user data is transferred, so it can't be qualified as SAO. But even if we assume, that it was DAO that was intended to stand above, I can't confirm only. Specification only says that DAO is the only applicable recording mode after fast blanking procedure, and telling from own experience, it's not a problem to perform DAO recording after fast blanking procedure applied to DVD-RW media previously recorded in Incremental or Restricted Overwrite mode. I.e. fast blanking worked in compliance with specification regardless previous recording mode. At least in units I've tested. Or should it have read blank=fast *might* work incorrectly *unless* media was recorded in DAO mode before? Where might refers to few firmwares? In which case can we have an example? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
In other words it's one-time test for user, then [s]he knows that it works reliably or does Should read ... or does *not*. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Now I have to write a little wrapper script for growisofs to add -use-the-force... to the command line generated by the frontend. Did you try whether growisofs does not use DAO automatically if the media is blanked fast ? You cannot reliably ask whether the media was blanked fast. It doesn't mean that you can't try. If given firmware tells difference between minimally and fully blanked media, then it tells you that *every* time, i.e. reliably. In other words it's one-time test for user, then [s]he knows that it works reliably or does If you believe there is a way to identify this, you should tell us how. You check for feature 0x21, Incremental Streaming Writable, being current. If it's not, then DAO is the only applicable mode or in other words media in unit is minimally blanked. As already mentioned, it actually worked with all units I've tried. No, I can't claim that I've tested *awful lot* of them, but either way it's not exactly about belief, but practical experience with quite a few. blank=fast works only correctly if the medium was written on SAO mode before. I can't second this. To start with there is no such thing as SAO in DVD-R[W] context. SAO is a CD recording mode, which means that unit records session lead-in prior user data. There are only two DVD-RW Sequential recording modes: DAO and Incremental. In latter mode this is your private interpretation So as yours, we are all expressing private opinions here. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
The source code change mentioned in originating post is correct and will be included [though in modified form] to next dvd+rw-tools update. Great, any idea when you are planning your next release? Releases turned to be feature driven lately and as no new features were required (e.g. HD-DVD was dismissed) I had no immediate plans so far. But as option to specify TDMA allocation is of apparent interest, it might be appropriate to consider release in foreseeable future, i.e. from week to month. This I can't reproduce. In other words I managed to format BD-R disc with -ssa=4G, i.e. unit succeeded to format it with ~4GB spare area. Have you managed to record BD-R in this particular unit at all? Same question about BD-RE? What I'm trying to say is that the unit might simply be broken... Another option is a kernel bug, maybe in SATA support (as you mentioned it's SATA connected). Have you managed to record a DVD? I have been able to record on this drive before. As long as I don't try to pre-format a BD-R. And I have never had any problems with the BD-RE's. I have also been able to record DVD's with this unit. I am going to move to a SATA unit soon, but right now I'm still tinkering with the same kind of drive that you have. I.e. you suffered from this problem with non-SATA unit? To reiterate. You run dvd+rw-format and kernel starts logging test unit ready: meduim error. As you start dvd+rw-format in text console (i.e. without starting windowing system), the kernel log appears as dvd+rw-format output. Error messages are emitted till you press ctrl-c. Is it correctly understood? Do you see any output from dvd+rw-format? Like process indicator? What does dvd+rw-format print exactly? Basically I'm running low on ideas, primarily because I couldn't reproduce this... Side note about spare area capacity. There is something they call TDMA, Temporary Disc Management Area, residing in Lead-In. As you allocate spare area, part of it will be reserved for *additional* TDMA regions. Relevant question is what part of it? MMC specification says that default value is up to vendor and in Panasonic case it seem to be 1/2 of spare area capacity. This means that if you ask your unit for spare area utilization data right after format, you'll see that 1/2 of it is already used. Well, it's not actually used, but reserved for TDMAs. Whether it's excessive or not, time will show. Meanwhile I'm considering adding extra option to dvd+rw-format, which would allow you to specify which portion of spare area will be reserved for TDMA. A. Wait, are you saying that if you used -ssa=4G you are actually going to get 2G of spare and 2G of TDMA? [Don't kill the messenger...] Yes. The real problem is that we don't know how TDMA is used exactly and therefore it's hard to judge if it's excessive or not. It surely varies from application to application and it might be that for your purposes (I assume you pretty much fill the media up at once) it's absolutely excessive. Best is to ask vendor for recommendation. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
Sorry, please add a -v this should give you the formatted capacity list in addition. As you wish... I am not sure whether you guys like attachments or whether you want things inline, so I just attached it. OK, so this medium holds 200704 spare sectors. This is bullshit. If you write to the media as it was at that moment, it would end-up *without* spare sectors at all and consequently with defect management permanently disabled for that particular disc. Secondly 200704 is maximum number of spare BD *clusters* *allowed* to be configured, not currently configured. I am not sure whether this is the default or whether this is a result of a format call. The media remained unformatted and is as good as virgin. In other words format call had no effect. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Can growisofs do that? Record in DAO mode? Yes. But you have to pass explicit -use-the-force-luke=dao. Try that... Seams to be ok, burning the same opensource_dvd70.iso the DVD-RW is mountable and fully readable. Mediainfo: INQUIRY:[PLEXTOR ][DVDR PX-740A ][1.00] GET [CURRENT] CONFIGURATION: Mounted Media: 14h, DVD-RW Sequential READ DVD STRUCTURE[#10h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2298496*2KB=4707319808 READ DVD STRUCTURE[#0h]: Media Book Type: 33h, DVD-RW book [revision 3] Last border-out at:2045*2KB=4188160 2045 again... It apparently doesn't affect playback. But on the other hand why should it, when kernel looks at track information and capacity, which are perfectly sane: READ TRACK INFORMATION[#1]: Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:1122816*2KB Last Recorded Address: 1122815*2KB READ CAPACITY: 1122816*2048=2299527168 As we see 2045 even in DAO recording, I'd say it's something fishy with firmware. Check if vendor has an update. If not (or if it doesn't resolve the problem) I can't recommend anything else but to stick to DAO mode for all DVD-RW recordings. You can also try to format for Restricted Overwrite, it might work properly... Related question is if DVD-R suffers from same problem... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Pioneer unit worked for me at numerous occasions It's a Plextor PX-740A. So it's a NEC with different firmware. PX-740 is believed to be re-bandged Benq DW1640. Newer PX-8xx units are believed to be re-badged NEC. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Pioneer unit worked for me at numerous occasions It's a Plextor PX-740A. Can it be that it gets screwed up under buffer underruns? I mean as actual average speed was 2.6x, while unit intended to record at 4x, it had to suffer multiple buffer underruns. It should have a burn-proof feature. There is a difference between should and does, isn't there? But I'm not saying that it does not have the feature. As mentioned I really don't have any solid clue about why incremental recording don't work with some units, so I kind of inclined to blame any portion of firmware:-) A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Record in DAO mode? Yes. But you have to pass
explicit -use-the-force-luke=dao. Try that.
One detail question arises to me:
I remember that -dvd-compat on blank DVD-RW caused DAO
from a bug report about scdbackup which tried to pipe
with -dvd-compat.
I have the feeling that we've discussed this, but anyway. If firmware is
in shape, then DAO is engaged automatically. DAO requires prior
knowledge of recording size. Pipe does not give you this knowledge. This
must be conditions where scdbackup suffered the error...
But now that i look into the code of growisofs-7.1
growisofs.c:
intdvd_compat=0, ...
...
else if (!strcmp(opt,-dvd-compat))
{ if (poor_man0) poor_man = 1;
dvd_compat++;
growisofs_mmc.cpp
{ if (dvd_compat = (profile==0x14?2:256))
{ is_dao = 1,
it seems that DAO is not engaged by a single -dvd-compat
Correct.
but would need two of those options.
It was some intermediate suggestion and is kept for backward
compatibility reasons, so please don't get fixated on this. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
Related question is if DVD-R suffers from same problem... Here the mediainfo of a dvd-r written on the same system a few month ago I assume you had no problems reading this recording... showing the same 2045 value: INQUIRY:[PLEXTOR ][DVDR PX-740A ][1.00] GET [CURRENT] CONFIGURATION: Mounted Media: 11h, DVD-R Sequential READ DVD STRUCTURE[#10h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2298496*2KB=4707319808 READ DVD STRUCTURE[#0h]: Media Book Type: 25h, DVD-R book [revision 5] Last border-out at:2045*2KB=4188160 I can imagine this can confuse DVD-ROM players capable of multi-border DVD-R playback (there aren't many, but they can be found in the wild), possibly even recorders of different brands. But if it works for you, then it works for you. But naturally it doesn't change the fact that it's something fishy about this firmware, because this is not compliant with specification. As implied earlier last border-out should point at the end of last recorded track. READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:813696*2KB Last Recorded Address: 813695*2KB READ CAPACITY: 813696*2048=1666449408 This values appear sane and are consistent with each other, so my assumption holds, doesn't it? Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
I made another attempt burning an iso image starting growisofs -Z /dev/sr2=opensource_dvd70.iso I could mount this getting (/var/log/messages): kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 kernel: ISOFS: changing to secondary root In mc (midnight commander) I can look into the directory structure of the mounted dvd but every copy operation gives an error: kernel: attempt to access beyond end of device kernel: 0b:02: rw=0, want=2242880, limit=130528 *ALWAYS* complement problem reports with dvd+rw-mediainfo output for the problem recordings. It's virtually impossible to say something really meaningful without it. Even log output from actual recording is desired might even be required [naturally most of progress indicator can be omitted. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
I got problems mouting DVD-RWs written with growisofs -Z /dev/sr2 . in the same dvd-burner-device it was burned with. Mount says: mount: wrong fs type, bad option, bad superblock on /dev/dvdwriter2, or too many mounted file systems In contrary to cdrecord, growisofs does not implement multi-border support Yes, it does! Virgin and fully blanked DVD-RW media are written in compliant multi-border manner! DVD-R[W] multi-border support was there from day DVD-R[W] support was added to growisofs, along with Restricted Overwrite DVD-RW support. but uses some dirty tricks to pretend multi-session. It should read but uses *in my opinion* some dirty tricks, because that's what it is: *Joerg's* opinion. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
In contrary to cdrecord, growisofs does not implement multi-border support Yes, it does! Virgin and fully blanked DVD-RW media are written in compliant multi-border manner! DVD-R[W] multi-border support was there from day DVD-R[W] support was added to growisofs, along with Restricted Overwrite DVD-RW support. Does this mean you only use the trick for DVD+RW? No. ISO9660 volumes on DVD-RW *Restricted Overwrite* are treated in the same way as on DVD+RW. As well as on DVD-RAM, BD-RE, BD-R formatted for Pseudo-Overwrite. It should be noted that in last case media can be treated as both multi-session[/-border] and expandable single-session. Or rather multi-session capable OSes will mount it as if it was multi-session, while non-multi-session capable OSes will mount first session, yet be able to access files from all the sessions. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
*ALWAYS* complement problem reports with dvd+rw-mediainfo output for the problem recordings. It's virtually impossible to say something really meaningful without it. Even log output from actual recording is desired might even be required [naturally most of progress indicator can be omitted. 1. Blanked previous used media using cdrecord blank=all dev=1,2,0 For reference, you can do same with 'dvd+rw-format -blank=full /dev/sr2'. 2. Wrote iso image growisofs -Z /dev/sr2=opensource_dvd70.iso Output: Executing 'builtin_dd if=opensource_dvd70.iso of=/dev/sr2 obs=32k seek=0' /dev/sr2: Current Write Speed is 4.1x1352KBps. 7340032/2299527168 ( 0.3%) @1.6x, remaining 20:49 RBU 99.4% UBU 4.8% [...] 2289008640/2299527168 (99.5%) @3.0x, remaining 0:02 RBU 29.7% UBU 19.0% builtin_dd: 1122816*2KB out @ average 2.6x1352KBps /dev/sr2: flushing cache /dev/sr2: updating RMA /dev/sr2: closing session For reference. All these updating RMA and closing session commands are pure firmware domain. In particular there are no parameters reflecting track size passed with these commands. Unit firmware is expected to keep track of last written block, 1122816 as we see in builtin_dd summary, and to write it to RMA, TOC and whatever structures required. Question is does it? That's where mediainfo comes into picture: 3. Mediainfo eis # dvd+rw-mediainfo /dev/sr2 INQUIRY:[PLEXTOR ][DVDR PX-740A ][1.00] GET [CURRENT] CONFIGURATION: Mounted Media: 14h, DVD-RW Sequential Media ID: MCC 01RW4X ... READ DVD STRUCTURE[#0h]: Media Book Type: 33h, DVD-RW book [revision 3] Last border-out at:2045*2KB=4188160 2045? This can't be right... Normally it's same as recording size, should be 1122816 in this case. READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Next Writable Address 0? This makes it look like recording was not even performed. Track should be closed... Free Blocks: 2297888*2KB Track Size:2297888*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 65264*2048=133660672 Capacity of 65264 which has no relation to last border-out location? Should be same and 1122816... mount /media/dvdwriter2 Worked; report in /var/log/messages: kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 kernel: ISOFS: changing to secondary root So it wrote something, Next Writable Address must be bogus... 5. Try to copy the content of the mounted device to hd failed: Cannot read source file media/dvdwriter2/Autorun.inf Input/Output error (5) Reporting in /var/log/messages: Nov 20 16:47:30 eis kernel: attempt to access beyond end of device Nov 20 16:47:30 eis kernel: 0b:02: rw=0, want=2242880, limit=130528 This is perfectly consistent with value returned to READ CAPACITY rescaled to 1KB. READ CAPACITY is what defines the end of device. As mentioned writing values like last border-out, next writable address, those defining capacity is pure firmware domain. So it appears as if firmware failed miserably to record consistent and meaningful values. Question is how come? I don't know. Pioneer unit worked for me at numerous occasions and it worked for numerous users with other units... On the other hand there were several reports earlier all mentioning last border-out at 2045... Yet I don't have solid clue about this 2045 phenomena... Can it be that it gets screwed up under buffer underruns? I mean as actual average speed was 2.6x, while unit intended to record at 4x, it had to suffer multiple buffer underruns. But how come 2045 at several occasions? Common firmware deficiency? But it was observed with different vendors... Though it doesn't really exclude possibility of common firmware deficiency, because there is a lot of re-badged units out there... Another question is how come cdrecord succeeded? The catch is that by default it's recording in DAO mode, which requires that application sends track size prior recording, and all last border-out, table of contents, capacity structures residing in lead-in are recorded *prior* data. This is unlike multi-border recordings [which is default mode for growisofs when it comes to write-once and virgin or fully-blanked DVD-RW], when data is recorded first and *then* lead-in. Can growisofs do that? Record in DAO mode? Yes. But you have to pass explicit -use-the-force-luke=dao. Try that... Also try -speed=2. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BD-R formatting help
Hi, Matt! I'm monkeying around with the blu-ray drives again (though now it is a SATA interface) and I've come upon something that I don't quite understand. I am trying to make the spare area of a BD-R be something larger than the default. I was hoping to run something like: ./dvd+rw-format -ssa=4G /dev/dvd But when I execute this command, it says that it is invalid for the detected media. This is not intentional. In other words it's a bug and it will be looked into. Suggested code modification might be appropriate, but I'd rather not say it without double-checking. In a course of few days. Meanwhile please submit dvd+rw-mediainfo output (even garbled one you mentioned you obtain if you don't reload media). cdrecord does not show format descriptors. After making the above change, it then gets past this portion of the code and gets down to where the actual formatting is going to take place. I get this message: sr0: CDROM (ioctl) error, command: Test Unit Ready 00 00 00 00 00 Deferred sr00:00: sense key Medium Error Additional sense indicates Format command failed You indicated it's BDB2 firmware? Is it latest? We both know that there is BZE6 available for SW-5582. Do you know how they number their releases? For example is BZxx later than BDxx? What I'm implying firmware upgrade might be due to make it work with arbitrary ... Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems mounting DVD-RWs written with growisofs
For public [and Marcus's] reference. I can only second Thomas's analysis and suggestions. Thank you, Thomas! A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: growisofs says CLOSE SESSION failed when writing to BD-R
I did a trial run of burning a UDF disk image (created with mkudfiso) to a BD-R disk using growisofs and got the following error message at the end: :-[ CLOSE SESSION failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error The resulting disk does mount on the same system that burned it and the SHA256 hashes for its contents check out ok. My main question is: is this something I should be concerned about? No, it's harmless. Trouble is that when growisofs pre-formats the blank, it fails to instruct finalization procedure about it. The only side effect is this redundant in this case attempt to CLOSE SESSION. It will naturally be fixed in next 7.2 release, but till then it can be safely ignored. You might want to consider explicitly pre-formatting media with dvd+rw-format in order to reserve larger spare area. Recall that BR-R media can be formatted only once and prior actual recording. The command used was `growisofs -Z /dev/dvdwriter=backupudf-bdsize1.iso`. The output (incomplete, as the first bit had scrolled out of the buffer) is attached as growisofs.out. I do recall growisofs saying, at the beginning, that it had found new BD-R media (correct) and was going to format it. If necessary, I can try again and redirect its output to a file. It wouldn't be necessary. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.01.01a=40: multi.c
Fix for multi-extent bug in multi.c has [at least] two bugs:
These two bugs were discovered by merely looking at the code. Actual
initial testings revealed [at least] 3 more bugs, see below.
1. If directory entries constituting multi-extent file end up in
different sectors read_merging_directory ends up in endless loop.
Problematic loop is denoted in attached diff along with possible solution.
Coiuld you please explant your claim?
How are 2KB sectors in directory table filled with directory entries? If
there is no place for next directory entry in current 2KB sector the
latter gets padded with 0s and next directory entry is written to next
2KB sector. Now all you have to imagine is sequence of directory entries
constituting same multi-extent file being laid down in two adjacent
sectors with 0 padding between them. Having this image in mind, how
would following loop handle this padding?
while (i2 len) {
idr2 = (struct iso_directory_record *) dirbuff[i2];
...
i2 += idr2-length[0];
}
It would spin endlessly, wouldn't it? Well, actual loop had an extra
termination criteria:
while (i2 len) {
idr2 = (struct iso_directory_record *) dirbuff[i2];
if ((idr2-flags[0]ISO_MULTIEXTENT)==0) break;
i2 += idr2-length[0];
}
So that there are two possible scenarios:
1. idr2-flags[0] overlaps with 0 padding, therefore condition is met
and loop gets terminated *prematurely*. This results in calculated
s_entry-size being *less* than it should (run mkisofs -M under debugger
and see for yourself).
2. If padding is small enough idr2-flags[0] reads byte of *some* data
from next sector and if this byte happens to have ISO_MULTIEXTENT bit
set, then the loop spins endlessly.
Well, my initial report was admittedly incomplete, I failed to mention
case #1, but #2 is as real. Attached image (produced with mkisofs
2.01.01a43) triggers this case. The image contains single 40GB large
file with long name, so that this file's extents' directory entries span
over two 2KB blocks.
The code you removed is needed and you did not provide a working replacement.
Yes, I did! What is the purpose of the loop in question? To calculate
size field in super directory entry preceding actual extent entries,
isn't it? In next if I added following line:
(*pnt)-mxroot-size += (*pnt)-size;
which takes proper care of this very field without any extra loop.
2. Given that mkisofs reserves for file system layout generated by
another iso9660 formatter, alternative partitioning of file to multiple
extents (for example larger amount of smaller extents) for now would
result in effective data corruption. Point is that it's not enough to
This is a claim that would need a prove...
Given last experience I can't even imagine that it would be possible for
me to provide proof you would accept. You just have to experience it
yourself:
1. mkdir test
touch test/file
perl -e 'truncate(test/file,8*1024*1024)'
this gives you test directory with 8MB file;
2. modify 2.01.01a43 mkisofs/tree.c and redefine LARGE_EXTENT and
MAX_EXTENT to say 0x10, 1MB, recompile;
3. mkisofs -R -iso-level 3 test test.iso
this gives you an image with 8 extents generated by alternative
iso9660 formatter.
4. burn in to CD;
5. modify mkisofs/tree.c and redefine LARGE_EXTENT and MAX_EXTENT to say
0x20, 2MB, recompile;
6. collect multi-session parameters from cdrecord and simply refresh
directory structure:
mkisofs -C xx,yy -M xxx -R -iso-level 3 test test2.iso
7. burn test2.iso as second session, mount it and tell us what you see,
run 'wc /cdrom/test/file' and tell us what is the result.
Now to further bugs.
Bug #3. If previous session has multi-extent file[s]
read_merging_directory effectively omits last directory entry[-ies] in
corresponding subdirectory, which naturally results in file[s]
disappearing from multi-session recordings. This is because of
following. Beside pointer to directory_entry* array procedure in
question returns number of entries in this array in *nentp. Now amount
of allocated and filled entries is nent+nmult, while value returned in
nentp is nent alone. This means that if for example there is
multi-extent file in current directory followed by single-extent one,
latter disappears from multi-session recording, because consumer of
returned array would never process it. One should return nent+nmult, see
reference to line #591 in attached diff.
Bug #4. check_prev_session cleans up only first extent on multi-extent
file. As result remaining extents are attempted to be merged, which in
turn results in failure to sort merged directory. This happens because
loop index in clean-up is never incremented, see reference to line #1099
in attached diff.
Bug #5. Whenever there is an iso-name clash with previous session and
mkisofs assigns
2.01.01a=40: multi.c
Fix for multi-extent bug in multi.c has [at least] two bugs:
1. If directory entries constituting multi-extent file end up in
different sectors read_merging_directory ends up in endless loop.
Problematic loop is denoted in attached diff along with possible solution.
2. Given that mkisofs reserves for file system layout generated by
another iso9660 formatter, alternative partitioning of file to multiple
extents (for example larger amount of smaller extents) for now would
result in effective data corruption. Point is that it's not enough to
copy extents' isorec.extent fields alone, one has to copy at least
isorec.size fields as well. As for at least. *Formally* (i.e. knowing
nothing about alternative iso9660 formatting and assuming worst) one
should copy even isorec.ext_attr_length, [some bits from] flags,
file_unit_size and interleave. Attached diff denotes problematic code by
simply copying all of above mentioned fields in single memcpy (along
with isorec.date field, which is checked to be same as in curr_entry, so
copying should not cause side effects).
Couple of comments not related to above file-system formatting bugs.
There is inconsistency in directory_entry.mxpart declaration and its
usage. Declaration is guarded by #ifdef USE_LARGEFILES, while its
usage is not. Formally multi-extent files don't have to be large, i.e.
small files are allowed to be multi-extent too (actually original
application for multi-extent was *CD* packet writing). Therefore it,
multi-extent support, should not be associated with USE_LARGEFILES and
mxpart declaration should not be depend on corresponding macro.
In check_prev_session one can see free(ptr[i]); and in copy_mult_ext one
can see free(sex);. These are pointers to directory_entry structure,
which in turn can contain pointers to other dynamically allocated
objects, most notably rr_attributes and name. Freeing an object without
freeing other dynamically allocated objects it alone refers to used to
constitute memory leaks.
As for copy_mult_extent. As mentioned above it copies pieces of
information from original extent records. As alternative to this field
copying would it be appropriate to consider simply using original extent
records, i.e. removing them from orig_contents array and linking them
into this_dir? A.
P.S. As usual I make no claims on correctness of provided patch, it
serves primarily educational purposes.
--- ./multi.c.orig 2008-06-13 22:40:10.0 +0200
+++ ./multi.c 2008-07-23 10:42:42.0 +0200
@@ -761,26 +761,11 @@
if ((mx ISO_MULTIEXTENT) == 0
(idr-flags[0] ISO_MULTIEXTENT) != 0) {
struct directory_entry *s_entry;
- struct iso_directory_record *idr2 = idr;
- inti2 = i;
- off_ttsize = 0;
-
- /*
- * Sum up the total file size for the multi extent file
- */
- while (i2 len) {
-idr2 = (struct iso_directory_record *) dirbuff[i2];
-
-tsize += get_733(idr2-size);
-if ((idr2-flags[0] ISO_MULTIEXTENT) == 0)
- break;
-i2 += idr2-length[0];
- }
s_entry = dup_directory_entry(*pnt); /* dup first for mxroot */
s_entry-de_flags |= MULTI_EXTENT;
s_entry-de_flags |= INHIBIT_ISO9660_ENTRY|INHIBIT_JOLIET_ENTRY;
- s_entry-size = tsize;
+ s_entry-size = 0; /* size is calculated below */
s_entry-starting_block = (*pnt)-starting_block;
s_entry-mxroot = s_entry;
s_entry-mxpart = 0;
@@ -796,6 +781,7 @@
(pnt[-1])-next = *pnt;
(*pnt)-mxroot = (pnt[-1])-mxroot;
(*pnt)-mxpart = (pnt[-1])-mxpart + 1;
+ (*pnt)-mxroot-size += (*pnt)-size; /* accumulate mxroot's size */
}
pnt++;
mx = idr-flags[0];
@@ -1184,7 +1170,16 @@
se1-next = sex;
len1++;
}
- memcpy(se1-isorec.extent, se2-isorec.extent, 8);
+ /* 27 bytes memcpy covers following fields:
+ ext_attr_length,
+ extent,
+ size,
+ date,
+ flags,
+ file_unit_size,
+ interleave
+ */
+ memcpy(se1-isorec.ext_attr_length,se2-isorec.ext_attr_length,27);
se1-starting_block = get_733(se2-isorec.extent);
se1-de_flags |= SAFE_TO_REUSE_TABLE_ENTRY;
se1-de_flags |= MULTI_EXTENT;
@@ -1195,7 +1190,7 @@
se1 = se1-next;
se2 = se2-next;
}
- memcpy(se1-isorec.extent, se2-isorec.extent, 8);
+ memcpy(se1-isorec.ext_attr_length,se2-isorec.ext_attr_length,27);
se1-starting_block = get_733(se2-isorec.extent);
se1-de_flags |= SAFE_TO_REUSE_TABLE_ENTRY;
se1-isorec.flags[0] = ~ISO_MULTIEXTENT; /* Last entry */
Re: Burning a Windows / DVD player compatible DVD
Hi, I'm really struggling with this whole compatible DVD thing. For my amateur dramatics group, I have produced a DVD of our show, including menus and all sorts of fun like that. The DVD plays perfectly with xine dvd://video/dvd. I have burned the DVD in many different ways, such as growisofs -dvd-compat -dvd-video -Z /dev/scd1 . and most of the ways I burn it will work perfectly on my panasonic DVD player. However, when I distributed these DVD's to other people, I have received reports that they don't work on Windows machines (they apparently show up as a blank DVD), Mac's (similar I guess - but no detail on that) or some DVD drives (which just refuse to read them). I believe the DVD that was written that works on Linux and my DVD player is using the UDF file system, but several real DVD's I have use iso9660. Well, if a disk gets mounted as iso9600, it doesn't mean that there is no UDF directory structure. What you're likely to see it bridge-formatted disk containing both ISO9600 and UDF directory structures, and ISO9600 gets mounted by default. For reference, mkisofs -dvd-video produces layouts just like that. I tried burning it with iso9660 (actually using gnomebaker) and that fails to play on my DVD player, but it is recognised and can be played by a windows computer. Right, real DVD players can and some actually do refuse to play ISO9660-only media. While Windows can simply not care about file system, it sees just a bunch of media files to be played. What you're more likely to suffer from is incompatibility at media format level (see below), not file system or video content. I'm currently using DVD-R disks, which I understood to be more likely compatible with DVD players (although I may have that wrong because http://fy.chalmers.se/~appro/linux/DVD+RW/ suggests that DVD+R disks are more compatible). It doesn't really say it. It discusses DVD+ format merits, it discusses how to improve compatibility of recordings, but the choice is left to individual reader. In case it is useful, I have pasted the output of dvd+rw-mediainfo for one of the burned DVD's at http://pastebin.com/m7479a9c For future I'd insist on including dvd+rw-mediainfo directly in message (as well as versioning information and even output produced during recording). On provided URL one can find: INQUIRY:[LITE-ON ][DVDRW LDW-451S ][GSB6] GET [CURRENT] CONFIGURATION: Mounted Media: 11h, DVD-R Sequential READ DVD STRUCTURE[#0h]: Last border-out at:2045*2KB=4188160 READ TRACK INFORMATION[#1]: Track Size:2247216*2KB READ CAPACITY: 2247216*2048=4602298368 For -dvd-compat/-video recording last border-out, track size and capacity would normally be the same. Inconsistently low last border-out value is known to confuse some players rendering such media unplayable in this players. Question is why is it low? I used to account it to media defects in lead-in area. At least if advised to try different media or media brand in such situation, other users seem to confirm that failure is not reproducible. However! As I realize now they all reported value of 2045... Common media fault? Hardly... Common firmware deficiency? Can be... Common usage pattern, such as interference with auto-mounting facility? Can be... At least it's least likely recording program's fault, because last border-out position is pure firmware domain, i.e. recording program has nothing to say about it (not to mention that it's generally known to come out right, i.e. equal to last written block + 1). Could anyone suggest how I should be burning these DVD's to ensure they are compatible with both windows and more DVD players? If you want to try DVD+R, then do make sure that you instruct your unit to burn it with so called DVD-ROM book-type with 'dvd+rw-booktype -dvd-rom -unit+r /dev/dvd'. Lite-on should allow you to do that. As for DVD-R. There was a case of malformed border-out position mentioned in http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html, look for BTC. If your firmware can't correctly handle incremental recording, then -use-the-force-luke=dao might be solution even for you. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
The reason is in the beginning of merge_isofs() in multi.c. In
particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed
to be and customarily used for other purposes (such as hybrid disks),
there is no guarantee that data there does not resemble iso9660 volume
descriptor. I don't want mkisofs to look at sectors prior 16th at all,
but start directly with volume descriptor. One can argue that mkisofs
should have seek-ed to 16th sector all by itself, but the code has been
around for so long, that it should be considered feature, not bug.
In theory, I could change mkisofs to start looking at sector #16
Once again, the code has been around for so long, that it should be
considered to be a feature, and therefore no modifications should me
made. In other words, don't.
But if you put something that looks like a PVD between sector #0 and
sector #15, then your software is wrong anyway. Are you really doing this?
I'm not putting anything between sectors #0 and #15, but it does not
mean that some other program does not. And by doing so such program does
*not* violate any standards, moreover, it's common practice. mkisofs
itself puts data there if instructed to generate hybrid disk. Data put
by mkisofs does not normally resemble PVD, but *formally* there is no
guarantee that it won't. Therefore it's not inappropriate (or in other
words it's not definitely wrong) to guide mkisofs directly to 16th sector.
Your claim that the file is non-contiguous is just wrong.
Having 9GB 5G.0 file in XP (previously discussed), if I read byte prior
4GB-2KB offset in the file, I get last byte from LBA X+0x20-2, and
when I read next byte, i.e. at 4GB-2KB offset in file I get data from
LBA Y, and there is 1GB gap between X+0x20 and Y.
I cannot speak for the sofware you used to look at the image.
In other words you're implying that under no circumstances results
obtained with software of my choice could be possibly right.
I looked at my test results using isoinfo and isoinfo did not show
non-contiguous files.
Already mentioned 'isoinfo -l -i /dev/dvd' output:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 9663674368 May 20 2008 [ 24 80] 5G.1;1
-- 000 1073743872 May 20 2008 [2097175 00] 5G000.0;1
In other words, like Windows XP kernel, isoinfo also reckoned that there
are one ~9GB and one ~1GB file. Now suggested 'isoinfo -debug -l -i
/dev/dvd' output:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 4294965248 May 20 2008 [ 24 80] 5G.0;1
-- 000 4294965248 May 20 2008 [2621640 80] 5G.1;1
-- 000 1073743872 May 20 2008 [4718791 00] 5G.1;1
-- 000 9663674368 May 20 2008 [ 24 00] 5G.1;1
-- 000 1073743872 May 20 2008 [2097175 00] 5G000.0;1
It depicts that 9GB file consists of 3 extents, 1st starting at LBA 24,
2nd at 2621640, and finally 3rd one at 4718791. But where does first
extent end? At 24 + 4294965248 / 2048 = 2097175, which is more than 1GB
apart from start of 2nd extent.
P.S.: The solution to correctly import directory entries from old sessions is
not trivial but a first hacky solution seems to work
Just for reference, attached patch would handle even shrinking
multi-extent files. Once again I want to point out that I make no claims
that the patches are complete solution to the problem. Their purpose is
to support claims in original bug report. A.
--- ./mkisofs/multi.c.orig 2007-08-20 18:17:17.0 +0200
+++ ./mkisofs/multi.c 2008-05-23 14:05:38.0 +0200
@@ -538,6 +538,7 @@
unsigned char *tt_buf;
UInt32_t tt_extent;
UInt32_t tt_size;
+ int mxpart;
static int warning_given = 0;
@@ -589,6 +590,7 @@
tt_extent = 0;
seen_rockridge = 0;
tt_size = 0;
+ mxpart = 0;
while (i len) {
idr = (struct iso_directory_record *) dirbuff[i];
if ((i + (idr-length[0] 0xFF)) len) {
@@ -635,6 +637,20 @@
(*pnt)-rr_attr_size = 0;
(*pnt)-total_rr_attr_size = 0;
(*pnt)-de_flags = SAFE_TO_REUSE_TABLE_ENTRY;
+
+ /*
+ * Track multi-extent files.
+ */
+ if (idr-flags[0]ISO_MULTIEXTENT) {
+ (*pnt)-de_flags |= MULTI_EXTENT;
+ (*pnt)-mxpart = ++mxpart;
+ }
+ else if (mxpart) {
+ (*pnt)-de_flags |= MULTI_EXTENT;
+ (*pnt)-mxpart = ++mxpart;
+ mxpart = 0;
+ }
+
#ifdef APPLE_HYB
(*pnt)-assoc = NULL;
(*pnt)-hfs_ent = NULL;
@@ -947,6 +963,7 @@
{
int i;
int rr;
+ int same;
int retcode = 0; /* Default not found */
for (i = 0; i len; i++) {
@@ -996,6 +1013,7
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
You used mkisofs incorrectly Command line sequence was *tailored* to allow to produce usable input for *hex editor* in less than minute. Why did you use -C16,xxx? This is definitely wrong. The reason is in the beginning of merge_isofs() in multi.c. In particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed to be and customarily used for other purposes (such as hybrid disks), there is no guarantee that data there does not resemble iso9660 volume descriptor. I don't want mkisofs to look at sectors prior 16th at all, but start directly with volume descriptor. One can argue that mkisofs should have seek-ed to 16th sector all by itself, but the code has been around for so long, that it should be considered feature, not bug. Your claim that the file is non-contiguous is just wrong. Having 9GB 5G.0 file in XP (previously discussed), if I read byte prior 4GB-2KB offset in the file, I get last byte from LBA X+0x20-2, and when I read next byte, i.e. at 4GB-2KB offset in file I get data from LBA Y, and there is 1GB gap between X+0x20 and Y. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Consider creating say 5GiB file and mastering an image: $ touch 5G.0 $ perl -e 'truncate(5G.0,5*1024*1024*1024)' $ ./mkisofs -iso-level 3 5G.0 1st.iso One does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 1st.iso contains following entries: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes contiguous 5GiB large file named 5G.0 consisting of two extents. X is extent beyond directory table in 1st.iso. So far so good. Now throw in another 5GiB file into second session: $ touch 5G.1 $ perl -e 'truncate(5G.1,5*1024*1024*1024)' $ ./mkisofs -C 16,2621614 -M 1st.iso -iso-level 3 5G.1 2nd.iso Again, one does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 2nd.iso comes out corrupted: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 5G000.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes fragmented 9GB-2KB file named either 5G.0 or 5G.1[?] and 1GB+2KB file named 5G000.0. Y is extent beyond directory table in 2nd.iso. Correct table for 2nd.iso would be: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 You used mkisofs incorrectly Command line sequence was *tailored* to allow to produce usable input for *hex editor* in less than minute. and you seem to missinterpret the results from the tool you used to list ISO-9660 directories. What is it you doubt? a) My lay-out of directory records? b) Interpretation of what they represent? c) Would be correct lay-out? If a), then you either didn't bother to examine them close enough or misinterpreted them. If b), then consider following output from Windows XP dir command for actual two-session recording: Volume in drive D is CDROM Volume Serial Number is 7896-8AA6 Directory of D:\ 05/19/2008 04:09 PM 9,663,674,368 5G.0 05/19/2008 04:09 PM 1,073,743,872 5G000.0 2 File(s) 10,737,418,240 bytes 0 Dir(s) 0 bytes free Admittedly one can argue what does above mentioned sequence of directory records represent, but reported interpretation is *not* something I made up out of nowhere, it actually occurred. If c), then please suggest your sequence. You did however find a bug. It seems that mkisofs for some reason assigned new block addresses for old files. No. What apparently happens is following. As mkisofs -M reads 1st.iso it runs across two directory records describing two extents of 5G.0. As it pays no attention to ISO_MULTIEXTENT flag, it treats these two extents as two files with same name. Then it discovers name conflict and resolves it by renaming second extent to 5G000.0. It does *not* assign new block addresses for old files, as 'location of extent' values remain constant for original 5G.0 extents, corresponding directory records simply moved apart by directory record sorting algorithm. Latter means that it's perfectly possible to choose file names in such manner that recording will come out right [at least on XP]. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
Why I even bothered to report this? To be told that I can't use
multi-sessioning options to dump second session data to separate file in
order to examine its directory table in hex editor?
and you seem to missinterpret the results
from the tool you used to list ISO-9660 directories.
What is it you doubt? a) My lay-out of directory records? b)
Interpretation of what they represent? c) Would be correct lay-out?
If a), then you either didn't bother to examine them close enough or
misinterpreted them.
If b), then consider following output from Windows XP dir command for
actual two-session recording:
I am sure that you did not missinterpret the results in case you used isoinfo.
I used hex editor, yet I can assure that despite this I did not
misinterpret the results.
I explained you that the problem is the incorrect allocation os _new_ space
for
the old file.
Well, why don't you back up your explanation with some evidence? I've
provided directory records' layout, even XP dir output for actual
multi-session recording, while you only said what you *would* use to
examine single-session recording...
BUT NEVER MIND!!! I'm going to throw in some more information supporting
my claim and then I'm going to *stop* following this thread, because I
simply don't have time or energy arguing.
Exhibit #1. 'isodump -i 1st.iso' output:
34 [ 1]17 2048 02/*.
34 [ 1]17 2048 02/*..
40 [ 1]18-2048 80/ 5G.0;1
40 [ 1] 200017 1073743872 00/ 5G.0;1
Exhibit #2. 'isoinfo -l -i 1st.iso' output:
Directory listing of /
d- 000 2048 May 20 2008 [ 23 02] .
d- 000 2048 May 20 2008 [ 23 02] ..
-- 000 5368709120 May 20 2008 [ 24 80] 5G.0;1
Exhibit #3. 'isodump -i /dev/dvd' output for two-session recording with
5G.0 in first session and 5G.1 in second:
34 [ 1] 2800c7 2048 02/*.
34 [ 1] 2800c7 2048 02/*..
40 [ 1]18-2048 80/ 5G.0;1
40 [ 1] 2800c8-2048 80/ 5G.1;1
40 [ 1] 4800c7 1073743872 00/ 5G.1;1
42 [ 1] 200017 1073743872 00/ 5G000.0;1
Note starting extent addresses for 5G.0 and 5G000.0. They are the *same*
as for 5G.0 extents in 1st.iso. These are original extents and no new
block addresses were assigned to old files. Also note that it's exactly
same directory records layout depicted in my original report. Oh!
isodump was modified to seek to second session, I simply hard-coded
offset for this particular recording.
Exhibit #4. 'isoinfo -l -T -i /dev/dvd' output for same recording:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 9663674368 May 20 2008 [ 24 80] 5G.1;1
-- 000 1073743872 May 20 2008 [2097175 00] 5G000.0;1
Exhibit #5. Attached mkisofs/multi.c patch. Note that I make no claims
that it's complete solution for the problem. On the contrary, I can
confirm that the patched mkisofs for example fails to handle situation
when 5G.0 shrinks to less than 4GB in second session. The sole purpose
of the patch is to provide support for original claim [summarized in
subject]. All the patch does is reconstruct mxpart member of
directory_entry structure for extents in previous session.
Exhibit #6. 'isodump -i /dev/dvd' output for two-session recording
performed with patched mkisofs.
34 [ 1] 2800c7 2048 02/*.
34 [ 1] 2800c7 2048 02/*..
40 [ 1]18-2048 80/ 5G.0;1
40 [ 1] 200017 1073743872 00/ 5G.0;1
40 [ 1] 2800c8-2048 80/ 5G.1;1
40 [ 1] 4800c7 1073743872 00/ 5G.1;1
Exhibit #7. 'isoinfo -l -T -i /dev/dvd' output for same recording:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 5368709120 May 20 2008 [ 24 80] 5G.0;1
-- 000 5368709120 May 20 2008 [2621640 80] 5G.1;1
I can even confirm that it works as it should in XP. A.
--- ./mkisofs/multi.c.orig 2007-08-20 18:17:17.0 +0200
+++ ./mkisofs/multi.c 2008-05-20 19:20:53.0 +0200
@@ -538,6 +538,7 @@
unsigned char *tt_buf;
UInt32_ttt_extent;
UInt32_ttt_size;
+ int mxpart;
static int warning_given = 0;
@@ -589,6 +590,7 @@
tt_extent = 0;
seen_rockridge = 0;
tt_size = 0;
+ mxpart = 0;
while (i len) {
idr = (struct iso_directory_record *) dirbuff[i];
if ((i + (idr-length[0] 0xFF)) len) {
@@ -635,6 +637,20 @@
(*pnt)-rr_attr_size = 0;
(*pnt)-total_rr_attr_size = 0;
(*pnt)-de_flags =
mkisofs -M makes no attempt to reconstruct multi-extent files
$ ./mkisofs -v mkisofs 2.01.01a39 ... Consider creating say 5GiB file and mastering an image: $ touch 5G.0 $ perl -e 'truncate(5G.0,5*1024*1024*1024)' $ ./mkisofs -iso-level 3 5G.0 1st.iso One does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 1st.iso contains following entries: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes contiguous 5GiB large file named 5G.0 consisting of two extents. X is extent beyond directory table in 1st.iso. So far so good. Now throw in another 5GiB file into second session: $ touch 5G.1 $ perl -e 'truncate(5G.1,5*1024*1024*1024)' $ ./mkisofs -C 16,2621614 -M 1st.iso -iso-level 3 5G.1 2nd.iso Again, one does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 2nd.iso comes out corrupted: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 5G000.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes fragmented 9GB-2KB file named either 5G.0 or 5G.1[?] and 1GB+2KB file named 5G000.0. Y is extent beyond directory table in 2nd.iso. Correct table for 2nd.iso would be: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 as an interested bystander i wonder how it is about general mountability of this image. Is this supported in contemporary Linux ? Define supported. Multi-extent files are recognized by isofs module and simple tests like above do pass... This does not exclude possibility for breakage in some situation[s]... Multi-extent support is actually rather old in Linux... 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]
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)
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)
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: 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)
- 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: 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: More Dual-Layer burning oddities
Just recently, I started having issues again, where the burning process (both with growisofs and cdrecord) would *seem* to burn fine, but there'd be an error during the layer flip which caused the disc to be unreadable at that point (ie: halfway through the disc). After a whole lot of investigation and coasters, I found out that I could make use of cdrecord's 'layerbreak' driveropt to result in a disc that was actually readable. So it sounds like your unit failed to record data at out-most edge? If it's really does not depend on media, then I'd say that your unit is deteriorating and you should consider replacing it... I've got two questions about this: 1) The cdrecord manpage mentions that using 'layerbreak' will cause the drive to burn using the 'layer jump' method, as opposed to 'sequential recording.' Is there a way to tell growisofs to do the same thing? 'Layer jump' is DVD-R/DL recording mode and it's not supported by growisofs for reasons discussed at http://fy.chalmers.se/~appro/linux/DVD+RW/-RW/. This however does *not* mean that growisofs can't control layer break position on DVD+R/DL. For example, if you specify -dvd-compat at growisofs command line, then it will automatically fold recording in the middle and record equal amount of data in both layers. You can also specify layer break position manually with -use-the-force-luke=break:NN, where N is amount of 2K blocks to layer break. Normally you'd use it when pinpointing layer break in DVD-Video recording in order to improve experience (commonly you'd want layer break on chapter point or dark and silent scene). But once again, I'd recommend to consider replacing unit. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
(i.e. no spare area) by dvd+rw-format option -ssa=none It might also be worth to check the impact of certification on write error detection. I.e.: -format=full I would propose to try both. It would be most economic to do -ssa=none first, because i would expect it to be the most likely to omit error detection on traditional WRITE10 (SCSI command 2Ah). With -format=full i would possibly expect that WRITE12 (command AAh) is needed. What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? But why not let drive do it during recording then? The time would be the same. The drive is in position to do better job and it makes perfect sense to let it. Indeed, if result of your checksum test fail, what options do you have? Try recording once again spending double your precious time? In BD-R case even discard media, which is pretty expensive, isn't it? So if your time is so precious to you, defect management is actually *saving* it for you. Not to mention money and *data* itself. The only reason to bypass defect management would be real-time recordings, but then it's likely to be a video recording when it's more important to keep recording, then to miss a second. For any kind of *storage* application, i.e. kind of applications we discuss here, bypassing defect management makes *no sense* *whatsoever*. There seems to be a WRITE12 experiment ready in dvd+rw-tools-7.1/growisofs_mmc.cpp Maybe Andy Polykov already knows more about that topic. Yes, commented out WRITE12 code in growisofs_mmc.cpp was used in a defect management bypass experiment in DVD-RAM. Its purpose was to satisfy curiosity, such as what would it take for *another* kind of application. Kind of application that would also have to handle so called enhanced defect management codes. It's not in production and I have no intention to put into production for reasons discussed above. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
DVD+R 16x info: INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106] GET [CURRENT] PERFORMANCE: Write Performance: 7.2x1385=9913KB/[EMAIL PROTECTED] - 15.9x1385=22059KB/[EMAIL PROTECTED] Wow! It says that it will gradually increase velocity, perhaps operate at constant angular velocity? For reference. Zoning is determined mostly by unit mechanics and has lesser to do with media. Indeed, in order to provide some linear velocity disk has to be rotated faster closer to center [where recording starts]. And there is limit for how fast given motor can go. Zone boundaries reflects maximum motor spin at given radius. I basically wanted to see zone boundaries (assuming that it would be same for all media types in this unit), but it doesn't show... Oh, well... time test: [EMAIL PROTECTED]:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 1000+0 przeczytanych recordów 1000+0 zapisanych recordów skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s As Thomas mentioned it's essentially 8x you see. Pktcddvd not used, doesn't matter whether growiso is started as root or user. When started as root growisofs boosts its priority and instructs system to pinpoint its memory (so that it's not swapped out). I burned some data using cdrecord+xcdroast again, the average speed was about 7.7 although it complained that dma is off. I checked it with hdparm (of course it was on), then just in case hdparm -X udma2 and again time test, unfortunatelly no improvement. It appears that your system balances somewhere at 8x. Or in other words slightly less than 8x is what it can deliver to the unit. Whether or not you actually get near 8x depends on combination of small factors and growisofs (as well as cdrskin) apparently ends up just below the level when unit if forced to take a lot of idle rotations and performance drops a lot. As mentioned, it seems to be specific to DVD+RW, but it's probably unit that requires a tad larger marginal for its DVD+RW recording strategy. How come just growisofs? Probably the fact that growisofs constrains itself to 32KB data transfers is one of the small factors. I mean larger transfer chunks would allow performance not to slip. But one way or another you don't want to balance on the edge (small factors come and go, you stay) and should concentrate on optimizing your system. Most likely it's kernel deficiency, so kernel upgrade [or downgrade] might help, but make sure recording unit is on dedicated IDE channel, double-check cabling... Meanwhile stick to -speed=6 [for all recordings to ensure you're below the edge with marginal]. A.
Re: Low burning speed
181403648/4220336128 ( 4.3%) @6.0x, remaining 11:30 RBU 99.1% UBU 84.6%
209125376/4220336128 ( 5.0%) @6.0x, remaining 10:52 RBU 100.0% UBU 80.8%
232062976/4220336128 ( 5.5%) @5.0x, remaining 10:53 RBU 100.0% UBU 73.1%
241631232/4220336128 ( 5.7%) @2.1x, remaining 11:15 RBU 98.9% UBU 30.8%
256933888/4220336128 ( 6.1%) @3.3x, remaining 11:18 RBU 100.0% UBU 19.2%
So not a single SYNC CACHE? ... Moving on to next probable suspect, unit
lying about available buffer capacity. Open growisofs_mmc.cpp in text
editor, locate lines that read
if (msecs=0)
{ poll (NULL,0,msecs);
continue;
}
(line #637 in 7.1) and modify it as following:
if (msecs=0)
{ fprintf(stderr,--- %d %d %d\n,msecs,bsize,bfree);
poll (NULL,0,msecs);
continue;
}
The drive seems to be willing to run at the speed which
is announced for the first part of the media: 6.0x.
The fact that the drive buffer (UBU) after a short time
of burning has less than 20 % fill indicates that there
is a problem with data transfer from computer to drive.
Well, not necessarily. In growisofs case when unit returns long write
in progress, it takes a nap for estimated time to drain buffer to 1/2
of its capacity. Then it should be noted that UBU value is *minimum*
observed value for progress indicator update period. So that *if* unit
returns long write in progress a lot, it would be normal to observe
UBU lying around 50%. If not below, because system timer doesn't provide
enough accuracy to nail 50% mark exactly. Note that I'm only saying that
UBU values below 50% do not *necessarily* indicate a problem! I'm *not*
saying that it's not a problem indication in *this* case:-)
Effective throughput seems to be about 4.3 MB/second.
This incident here looks quite strange:
1882193920/4220336128 (44.6%) @3.7x, remaining 8:10 RBU 100.0% UBU 26.9%
1883176960/4220336128 (44.6%) @0.2x, remaining 8:13 RBU 100.0% UBU 100.0%
1883176960/4220336128 (44.6%) @0.0x, remaining 8:17 RBU 100.0% UBU 100.0%
1886191616/4220336128 (44.7%) @0.7x, remaining 8:21 RBU 100.0% UBU 15.4%
Drive buffer is reported as full, but there is no
substantial data transfer for a short time.
This usually happens when recording crosses the velocity zone boundary.
Though it's too early if one trusts write performance descriptor [in one
previous posts it was at 112640*2K=230686720]...
This cannot be blamed on a bad throughput.
Maybe the drive buffer ran empty and the drive
decided to wait until it is at 100 % again.
Then it needed some time to speed up disc rotation
again.
Experiment proposal:
Would it work with better speed if you do not
burn the ISO image on the fly but first generate
it in a disk file and afterwards burn that file
to media ?
Also, in case it's not executed as root, try to execute growisofs as root.
For simplicity you could omit the mkisofs run
and just create a dummy file of 4 GB:
dd if=/dev/zero of=/tmp/4gb_of_zeros bs=1M count=4096
(1 GB = count=1024 should suffice too.)
This file could be burned to media by various programs:
growisofs -use-the-force-luke -Z /dev/sr0=/tmp/4gb_of_zeros
Or simply 'growisofs -Z /dev/dvd=/dev/zero'. This will guarantee that
there is no interference from file system. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Growiso doesn't work properly with LG GSA4163B burner and DVD+RW 8x discs. Burning speed is about 4x (even when burner speeds up switching from 4x zone to 8x - it's a ZCLV burner), it's well visible with K3b. There's no problem with all other types of media, including DVD-R 8X. Version 7.0.1 and 7.1, data: big, small, in combination, doesn't matter, media: Verbatim made by Mitsubishi and TDK made by Ricoh. Here's output: [EMAIL PROTECTED]:~$ growisofs -Z /dev/hdc /mnt/hda6/WinFast\ WorkArea/Poszukiwacze\ Czindici2.avi /mnt/hda6/WinFast\ WorkArea/odessa.avi /mnt/hda7/WinFast\ WorkArea/JFK.mpg /mnt/hda7/WinFast\ WorkArea/Nieukończony\ cud\ 2.mpg WARNING: /dev/hdc already carries isofs! About to execute 'mkisofs /mnt/hda6/WinFast WorkArea/Poszukiwacze Czindici2.avi /mnt/hda6/WinFast WorkArea/odessa.avi /mnt/hda7/WinFast WorkArea/JFK.mpg /mnt/hda7/WinFast WorkArea/Nieukończony cud 2.mpg | builtin_dd of=/dev/hdc obs=32k seek=0' I: -input-charset not specified, using utf-8 (detected in locale settings) /dev/hdc: Current Write Speed is 8.2x1352KBps. 0.24% done, estimate finish Tue Mar 25 22:09:03 2008 0.49% done, estimate finish Tue Mar 25 21:58:44 2008 0.73% done, estimate finish Tue Mar 25 21:55:19 2008 0.97% done, estimate finish Tue Mar 25 21:53:35 2008 1.21% done, estimate finish Tue Mar 25 21:52:34 2008 1.46% done, estimate finish Tue Mar 25 21:53:01 2008 1.70% done, estimate finish Tue Mar 25 21:52:22 2008 1.94% done, estimate finish Tue Mar 25 21:51:53 2008 ... ... 99.48% done, estimate finish Tue Mar 25 21:55:48 2008 99.72% done, estimate finish Tue Mar 25 21:55:49 2008 99.97% done, estimate finish Tue Mar 25 21:55:49 2008 Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 2060711 extents written (4024 MB) builtin_dd: 2060720*2KB out @ average 3.6x1352KBps /dev/hdc: flushing cache /dev/hdc: stopping de-icing /dev/hdc: writing lead-out 3.6x with below parameters sounds like recording was progressing at 1/2 of advertised velocity, i.e. started at 3x and then switches to 4x at about half recording. Question is does it run uniformly at 1/2 or does speed jump up and down? Read on... And here's output of media info: [EMAIL PROTECTED]:~$ dvd+rw-mediainfo /dev/hdc INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106] GET [CURRENT] CONFIGURATION: Mounted Media: 1Ah, DVD+RW Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s GET [CURRENT] PERFORMANCE: Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] - 112639] 8.0x1385=11080KB/[EMAIL PROTECTED] - 2295103] Speed Descriptor#0:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Looks all right... I can think of following reasons (in ascending order of likelihood). 1. Even though so called Page 05 settings should not affect DVD+ recordings (per MMC specification), unit looks at the page and misinterprets the settings. This happened before, though not in DVD+RW context. 2. Under high-speed recordings unit lies about available buffer capacity tricking growisofs to sleep for longer intervals, long enough to drain the buffer and affect performance. This happened before with some Pioneer units, and it should be handled, but your unit might lie in yet more confusing manner. 3. growisofs is periodically tricked to issue SYNCHRONIZE CACHE command, which drains the buffer, which in turn results in idle revolutions, hence lower performance. Could you do following. Download source, unpack some place, open growisofs_mmc.cpp with text editor, locate line that reads sync_cache: (it's line 665 in 7.1), add following line after it: fprintf(stderr,-- SYNC CACHE %x\n,errcode); Then 'make' and run './growisofs -use-the-force-luke=moi -Z /dev/hdc /mnt/hda6/...' directly from current working directory and collect output. Questions are: how does speed varies in progress indicator? Steady or jerky? Do you see SYNC CACHE and if yes, how often and what's the code? [There is a chance that there will be a lot of SYNC CACHE lines, don't hesitate to abort recording with Ctrl-C]. How does UBU value in progress indicator vary? A.
Re: Low burning speed
Growiso doesn't work properly with LG GSA4163B burner and DVD+RW 8x discs. Burning speed is about 4x (even when burner speeds up switching from 4x zone to 8x - it's a ZCLV burner), it's well visible with K3b. There's no problem with all other types of media, including DVD-R 8X. If you want meaningful answer, provide versioning information, exact command line, exact output generated by the program and complement it with dvd+rw-mediainfo output for resulting recording. Quote is from dvd+rw-tools web-page. To spare bandwidth you don't have to provide *complete* output, but only relevant, at very least handful of line from beginning and end. Also, when you say no problem with all other types of media, is it the same data set? What can you say about the data set? Is it a lot of small files or few large ones? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Burning video DVD+R
You used growisofs, i assume. Afaik it does not close DVD+R even if option -dvd-compat or -dvd-video is given. ??? -dvd-compat or -dvd-video do close the disk! Well, if used already at 1st recording. There is code that prevents you from closing the disk *if* 1st recording was not performed with -dvd-compat [or -dvd-video]. This is done for reasons discussed in Compatibility: caveat lector on dvd+rw-tools page. Point is that if you perform 1st recording without -dvd-compat and leave the disk open, then lead-out pointer points at the outer edge. This means that DVD-ROM units that try to calibrate at lead-out vicinity will be forced to virgin surface and fail. Just closing such disk will leave you with *nothing* you would be able to do to improve its compatibility in such DVD-ROM units. This is why growisofs refuses to just close open disk and -M /dev/cdrom=/dev/zero is advised to be used instead. Point is that -M /dev/cdrom=/dev/zero ensures that whole surface is recorded and above mentioned calibration is not performed on virgin surface. Reasoning basically is even if more time consuming, it's better than nothing left to do. Once again, this applies if 1st session was recorded without -dvd-compat or -dvd-video. If 1st session is recorded with -dvd-compat, then disk is closed at once [and unit burns lead-out pointer to point at the end of 1st session and not out-most edge]. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for cooperation with all burn backends
Is it really a problem between recording programs?
It is especially a problem between growisofs and libburn
on my 2.4 system.
- growisofs burns of DVD+RW experience data damage in about
25 % of the cases after libburn did a bus scan on the burning drive.
- growisofs burns of DVD-RW stall libburn bus scan as soon as the
active drive is enumerated. Affected growisofs burns have about
50 % probability to be damaged.
...
I can offer a patch of 100 to 150 lines in growisofs.c
to achieve locking of /dev/srN or /dev/scdN via the
corresponding /dev/sgM.
Since i implemented that on my system i am free of trouble
between growisofs and libburn.
I published the test version (loudly declaring itself as
inofficial hack) on the [EMAIL PROTECTED] mailing list
in the hope of some test results ... then i wanted to approach
you.
No echo. Everybody is on 2.6 already.
See diff -puN at
http://scdbackup.sourceforge.net/dvd+rw-tools-7.0.tsA60930.diff.txt
If sg scanning is so intrusive, why are you using at all? Isn't there
a way to list sg binding, say though ... /proc? And look, there is! It's
even possible to see what kind each device is and limit search to type
5, a.k.a. CD-ROM, devices... In either case below is function which will
appear in next release. Test it. A.
int grab_sg (int blkfd)
{ struct { unsigned int dev_id,host_unique_id; } idlunblk,idlunsg;
FILE *fp;
int host_no,channel,lun,id,type,i,sgfd=-1;
char str[128];
struct stat sb;
if (ioctl (blkfd,SCSI_IOCTL_GET_IDLUN,idlunblk) 0) return -1;
if ((fp=fopen (/proc/scsi/sg/devices,r)) == NULL) return -1;
for (i=0;i=0;i++)
{ if (fgets (str,sizeof(str),fp) == NULL) break;
if (sscanf (str,%d\t%d\t%d\t%d\t%d,
host_no,channel,id,lun,type) != 5)
continue;
if (idlunblk.dev_id == ((id 0xff) +
((lun 0xff) 8) +
((channel 0xff) 16) +
((host_no 0xff) 24)))
{ sprintf (str,/dev/sg%d,i);
if (stat (str,sb) 0) break;
errno = ENOENT;
if (minor(sb.st_rdev) != i) break;
sgfd = open (str,O_RDWR|O_NONBLOCK|O_EXCL);
if (sgfd=0)
{ if (ioctl (sgfd,SCSI_IOCTL_GET_IDLUN,idlunsg) 0 ||
idlunblk.dev_id != idlunsg.dev_id ||
idlunblk.host_unique_id != idlunsg.host_unique_id)
close (sgfd), sgfd = -1, errno = ENOENT;
}
break;
}
}
fclose (fp);
return sgfd;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for cooperation with all burn backends
... But the trouble is that the other systems, other than Linux that is, might and already do have own ways to serialize the access. It might be impossible and/or simply inappropriate not to use these mechanisms. Doesn't this kind of doom all very portable attempts as simply unachievable? Very portable almost alwas == equally crippled on all platforms. I'm so tired of 'very portable' software. That's kind of what I wanted to say. I mean it's either very portable or with explicit support for every system. But as it seems we're talking about one particular OS, Linux in this case, after all, we should abstain for using very portable term in context of this discussion. At least I will:-) I like the idea of having a convention-- but I would argue against it locking down devices against all access. [Once again] given that we're talking about Linux, 2.6 O_EXCL serializes only O_EXCL opens. So the program that only wishes to query unit can do so, while program that wants to pull the data or modify page settings should rather adhere to O_EXCL to serialize the access. A CDROM device is perfectly capable of answering, eg, ' are you a cdrom?' whil e burning. As far as I interpret Thomas' experience he has problems with growisofs performing recording on /dev/cdrom being disrupted by scan attempt on /dev/sg. This apparently turns to be far from simple are you a cdrom? question... I realize that deciding what access is 'safe' is underspecified right now. ... because from personal experience I can tell that I've never had problems running dvd+rw-medianfo during ongoing growisofs recording. dvd+rw-medianfo does issue are you a cdrom? and a bunch of other queries. In other words unit *is* indeed capable to answer the limited amount of questions and the fact that Thomas reports problem indicates rather a kernel issue. To summarize. My vote goes for block device addressing, back-porting of O_EXCL to 2.4 and convincing auto-mounting/-playing developers to stick to it. I will not be obeying O_EXCL in cdparanoia, at least in its current form. However, I also want to make cdparanoia safe in the context of cdrom devices [ripping] burning. I don't quite understand why not adhere to O_EXCL when it actually comes to action. I mean you can perform initial open without O_EXCL so that you can pull TOC, offer options to user, etc, but just before you're about to modify page parameters and start pulling CDDA, you can as well claim O_EXCL... But once again, I don't see applications such as cdrskin or cdparanoia as biggest problem, because user still *controls* them, but [s]he does not control auto-mounting/-playing facilities. Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for cooperation with all burn backends
Have you seen resmgrd? Keep in mind that I brought it as example of something that didn't quite catch up. And I did this to sort of emphasize the point that I don't believe in pure user-land solutions:-) I mean I kind of wanted to say look, it kind of does the things you propose, yet, it did *not* really make it. And consequently time is better spent adhering to block device even under 2.4, back-porting O_EXCL for block device[!], etc... For us programmers it would be nice to know the resmgr protocol and thus to get rid of forking an external program. (A study of resmgr client code should help.) resmgr comes with libresmgr.so.1 with documented interface providing all the functionality exposed through command line directly to application. I far as I understand... I believe this scheme is extensible enough for other operating systems. As mentioned, the reality is rather that it's either very portable or with explicit [and disjount] support for every system, because most of other system do provide means for serializing access and not using them is not an option. Cheers:-) A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools 7.0: iso burning problem
I faced a problem with dvd+rw-tools (6.0, 6.1 und 7.0) when I tried to burn a DVD-Iso-Image to a dvd using the command line growisofs -Z /dev/scd2=/media/CDWserver/export/Server/DVD-Images/KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso But it gives an invalid argument error: Output Executing 'builtin_dd if=/media/CDWserver/export/Server/DVD-Images/KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso of=/dev/scd2 obs=32k seek=0' :-( write failed: Invalid argument The following command line works well: cat KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso | growisofs -Z /dev/scd2=/dev/fd/0 Why is there is difference between these two commands. Why does the second work and the first not? I'd bet on the fact that growisofs opens file with O_DIRECT, while cat doesn't. For public reference. It turned to be the problem with ext3 implementation under 2.4 missing direct I/O method, which appears to be trivial [and erroneous] omission in kernel source [at lest ext2 implements this method]. One would normally expect O_DIRECT flag rejected already at open(2), but it doesn't seem to be the case. It remains mystery why it was not noticed earlier by 2.4 users. Next version shall compensate for this by banning O_DIRECT under 2.4 [naturally at run-time]. Meanwhile those who suffer from this can modify #ifdef O_DIRECT line in growisofs.c as #ifdef __notdef__ to work around the problem. A. P.S. for Marcus. The final conclusion slightly differs from one I gave you in private conversation, but it the workaround is the same. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for cooperation with all burn backends
Thomas, this is a request towards all developers of burn backends. Is it possible we define a common locking mechanism for drives which does not depend on hardly documented Linux O_EXCL ? Something simple and very portable would be needed. I don't quite understand couple of things. As for locking, or rather serializing access to [relevant] devices. Very portable customarily means support for different operating systems. But the trouble is that the other systems, other than Linux that is, might and already do have own ways to serialize the access. It might be impossible and/or simply inappropriate not to use these mechanisms. Doesn't this kind of doom all very portable attempts as simply unachievable? Secondly. Why do you address back-end developers? Is it really a problem between recording programs? Isn't auto-mounting/-playing facilities interfering with ongoing recording *bigger* problem? So if you want to make the noble attempt and spend some time convincing developers time is better spent talking to that developers. IMHO that is:-) Advisory locking would be sufficient, i think. So shall we assume that we're actually talking about Linux and Linux only? At least the rest of *this* message implies Linux alone. Please keep it in mind... Have you seen resmgrd? Well, it didn't seem to catch up, but anyway... Why didn't it catch up? If you want my opinion, I think that all attempts to achieve the goal *purely* in user-land are doomed. 2.6 O_EXCL on block device appears to be sufficient for intended purpose and I personally would rather prefer it back-ported to 2.4 than some user-land facility. My motivation currently is about growisofs and /dev/srN : I had the ito open(2) O_EXCL those /dev/srN and /dev/scdM which have the same SCSI address as the /dev/sgK used by libburn. Note that it doesn't have to be /dev/sg. Even though different, both 2.4 and 2.6 provide interfaces for passing SCSI commands from user-land through /dev/cdrom. Well, I have to admit I've never tested CDROM_SEND_PACKET interface for non-data recordings... Did libburn developers do? I definitely would (if I were to develop non-data cd recording program:-). Addressing by block device is really more natural, because you share same view as auto-mounting/-playing and hot-plugging facilities and even initial OS installation procedure, and consequently even user view. Not to mention that that's how it works in most OSes anyway. To summarize. My vote goes for block device addressing, back-porting of O_EXCL to 2.4 and convincing auto-mounting/-playing developers to stick to it. My vote naturally doesn't make it just happen, but unfortunately I don't have time [or energy] to suggest alternative. Note that there are left-overs from experiment with resmsg in dvd+rw-tools code [look for dev_open], so in case of alternative outcome, I'd prefer to see something similar to that, i.e. link to an .so and if available modify behavior at run time. Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools 7.0: iso burning problem
It remains mystery why it was not noticed earlier by 2.4 users. I had written two reports on this mailinglist in june 2006 but got no comment on it. Sorry about that. Life does not always turn the way we like:-) Yet, you have to admit it's somewhat mysterious, because June is ~1/2 year[!] after first release utilizing O_DIRECT... Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools 7.0: iso burning problem
I faced a problem with dvd+rw-tools (6.0, 6.1 und 7.0) when I tried to burn a DVD-Iso-Image to a dvd using the command line growisofs -Z /dev/scd2=/media/CDWserver/export/Server/DVD-Images/KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso But it gives an invalid argument error: Output Executing 'builtin_dd if=/media/CDWserver/export/Server/DVD-Images/KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso of=/dev/scd2 obs=32k seek=0' :-( write failed: Invalid argument This was a problem with 6.x on Linux for files residing on NFS, but it's fixed in 7.0. Double-check that you're running 7.0 and run the command under strace [on Linux or whatever system call tracing utility for your OS] and [to save the public bandwidth] send the system call trace to me. The following command line works well: cat KNOPPIX_V5.0.1DVD-2006-06-01-DE.iso | growisofs -Z /dev/scd2=/dev/fd/0 Why is there is difference between these two commands. Why does the second work and the first not? I'd bet on the fact that growisofs opens file with O_DIRECT, while cat doesn't. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Snoop DVD (MMC/ATAPI/SCSI) requests
Hi. I'm running Windows as a Guest OS in VMware on Linux. In Windows, a closed source application communicates with my DVD writer using VMwares virtual DVD, connected to /dev/hdc, which is my DVD writer. Now, I'd like to monitor all communication with my DVD. I found out about blktrace and it looked very promising. However, I've now discovered that blktrace cannot display all data, for example Inquiry Data. This is also pointed out by http://lkml.org/lkml/2005/8/23/70: the cdb is dumped, not the data So, are there any other tools that I can use to snoop the DVD communication? I've tried strace without luck. In VMware case you can tailor http://fy.chalmers.se/~appro/LD_*-gallery/index.html?sgio#sgio for very particular purpose:-) A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding files in small increments
I'm currently in a project where we try to burn log-files from disk to dvd-r. The goal is to rotate a log-file every 20 minutes and have it copied to read-only media in order to make it hard for an evil person to tamper with the file. We currently use the following commands in order to burn the files: initially, with a new media: growisofs -input-charset=iso-8859-15 --speed=1 -Z list of files -R -J and for appending more files: growisofs -input-charset=iso-8859-15 --speed=1 -M list of files -R -J The problem is that after a while, about 1,5 days, we can no longer append files. As the files are quite small, much below 100MB totally, my guess is that we are running out of sessions. Well, there also is some space *wasted* between sessions. It would help if you send (or look yourself;-) dvd+rw-mediainfo for affected media. And while we're on it, you should also send error message from failing recording, otherwise all one can do is speculate... However, someone suggested that we might be able to use multiple tracks in each session. This would gain us 99 tracks * the number of sessions, effectively increasing the period by a factor 100 before needing to switch media. 99 tracks is CD limiations. DVD-R allows for over 2000 recordings, but you might experience problems mounting it, as most OSes (and you should also tell what's yours!) ask for CD-ish table of contents and unit have to fabricate something which is not exactly like reality. Track recordings... H-m-m-m... You'll definitely have to be creating to mount them, which is why data commonly recorded in single track per session... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dvd+rw-tools update [7.0, Blu-ray, Mac OS X]
dvd+rw-tools 7.0 are available for download at usual location, http://fy.chalmers.se/~appro/linux/DVD+RW/. As subject suggests this release adds Blu-ray Disc support and Mac OS X 10=2 support. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sudo and growisofs
sudo growisofs ... /etc/shadow env MKISOFS=/tmp/evil.script sudo growisofs ... is enough reason for vast majority of users. A. How about I create a non superuser burn that is allowed to burn through permissions on the block device and then use: Well, who makes sure that input data readable for non-superuser burn? Is it acceptable that account in question can be used for virtually any purpose through env MKISOFS=/tmp/evil.script ...? I bet not, and then we just come back to the workaround suggested in man-page. And once again, if you disagree just compile with 'make WARN=-DI_KNOW_ALL_ABOUT_SUDO' and make your own rules. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems when writing DVDs with growisofs
Folks! Do math first! Dataset size was reportedly about 4.4GB, while I/O error logged at 4GB *exactly*. It can't be some prefetch/pad bug! It looks as if kernel can't manage volumes larger than 4GB *at all*. Or at least refuses to... The problem has been solved (moved): For the device of my DVD-burners there was pktsetup (for writing to DVDRAM) called via a initscript from which I dont know that it was aktivated. This is misconception. pktsetup is not for DVD-RAM, but for CD-RW packet writing, but can as well be used with DVD-RW Restricted Overwrite and DVD+RW [at least as far as I understand]. Ok, I can now read my DVD successfully and completly. So that packet writing module limits volume size to 4GB? Talk to the maintainer... readcd worked because it bypasses block device and issues raw read commands to its liking. But it remains the question, why I should not read my my DVDRAM now completly... You should not have any problems reading or writing DVD-RAM with pkt module disengaged. Nor should you have problems *reading* any kind of DVD media and writing with growisofs with pkt module disengaged. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Different max speed on same DVD ????
Does anyone know why my Pionneer DVR-109 and my HP DVD writer report different speed for the same 8x DVD ?? Pionner reports 4x and 2x speeds whereas HP reports 8x and 4x. Support for particular media brands vary from firmware to firmware. One vendor can dare to offer higher velocity for particular media brand, while another can choose to take more fail-safe path. Or offer higher velocity in next firmware. That's the way it is and it does not indicate hardware failure of any kind. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: burning iso-image to DVD-R failed
I can write iso-images to DVD-RW, DVD+RW even Double-Layer DVD+R with k3b with out any problems. But trying to burn an image, which I can burn to DVD-/+RW medias, to a DVD-R fails with the message below after about 40 seconds or 2 minutes. Two factors. a) Earlier kernel versions don't allow for a [write] command to execute for longer than 30 seconds [for interface used by growisofs]. b) growisofs allows limit of 3 minutes for command to execute [when kernel respects it]. Meaning that if command takes longer to execute, most notably unit is to perform power calibration in the beginning of recording, the command will time out and show as some error. Well, neither 40 or 2 mins falls to mentioned limits, which suggests that either unit is defective or I have tested two types of DVD-R medias with the same result. What does this message mean? Does the burning-device be defect? Well, neither 40 or 2 mins falls to mentioned limits, which suggests that either unit is defective or you were unlucky to hit two media brands poorly supported by your firmware. Try some quality brands, such as Verbatim, check vendor site for firmware updates... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD Double Layer Playing problem
I recently obtained a two DVD+-RW DL burners and decided to test them by trying to burn a copy of Monster's Inc (which is a DVD we own that is a DL disk) They are the Plextor DVDR PX-750A and the DVD-RW drive that comes with the SONY VIAO VGN-SZ160P. I used dd if=/dev/dvd of=DVD.iso bs=2048 to make the ISO, and growisofs -dvd-compat -Z /dev/dvd=DVD.iso to burn it. There were no reported errors at all during the burning process. I can mount the burned disks on the either of the Dl DVD+-RW drives that did burning, but my oldest DVD drive (which is only a DVD-RW single layer burner) thinks there is no media there (it can play commerical DL DVDs just fine). It's probably deficiency of this recorder. Recorders [unlike pure ROM players] are expected to have closer look at media, closer than looking at Media Book Type that is. It probably smells recordable media, but it's too old to believe that it's double layer... I can play the ISO image with xine no problem and I have used diff to verify that 1) The ISO and the burned DVDs movie are the same But I cannot play the burned DVDs as video anywhere, including the drives that burned it one (with either windows or linux) On windows or a commercial stand-alone DVD player I get a frozen scene from one of the previews with a stuttering text that loops after a few minutes. With either xine or totem it reports that this DVD is encrypted and recommends that I install libdvdcss. I have libdvdccs installed and it is what I use to watch most commercial DVDs that I watch. Content protection is two-fold. First you have to authenticate yourself to unit so that it gives up protected sectors, and then you have to descramble the content. When you ran dd you probably were authenticated [you probably ran xine prior dd], but dd doesn't do any descrambling and therefore you've copied scrambled content. When you burn it to recordable media it turns unplayable [you're likely to hear audio though], because you didn't copy the descrambling keys, nor marked protected sectors as scrambled. But before you ask how do you do the latter two, keep in mind that you *can't*. Consumer recordables provide *no* way to copy or setup own descrambling keys and therefore the only way is to descramble content prior recording. How is another question [which I don't feel capable to answer]. It seems clear that in terms of data and filesystems, I'd challenge the terms of data part. The fact that you can mount it is not mystery, because not everything is scrambled. Most notably sectors describing/defining file system layout are not, which is why it's never a problem to mount protected media and list files on it. Not even whole video content is scrambled, most notably menus are commonly not, so you can always navigate... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: can't read DVD+RW in Sony DW-G120A immediately after growisofs
I'm now quite confused. I'm attempting to use a Sony DW-G120A DVD+-RW which I have mounted in an external USB chassis. I have successfully burned CD-RWs with cdrecord, but am having no luck burning a DVD+RW. I have formatted two different DVD+RW blank and tried to record with what appears to be no success. I can not read the recorded DVD+RWs in a DVD-ROM drive in my laptop. This with laptop DVD-ROM can be just infamous incompatibility problem. Earlier very few, really very few laptop units could read DVD+RW. I can burn a DVD-R in the Sony, I can read that DVD-R in both the Sony and in my laptop DVD-ROM (and play it with ogle). I am not experienced enough to figure out what is going wrong with the DVD+RW. dvd+rw-tools-5.21.4.10.8 alexandria 2.6.12-gentoo-r10 # growisofs -speed 8 -Z /dev/scd0=/home/thoth/music.iso Executing 'builtin_dd if=/home/thoth/music.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: Current Write Speed is 2.5x1385KBps. 2392064/628006912 ( 0.4%) @0.3x, remaining 26:09 5111808/628006912 ( 0.8%) @0.6x, remaining 20:18 ... 623280128/628006912 (99.2%) @0.6x, remaining 0:06 625868800/628006912 (99.7%) @0.5x, remaining 0:02 builtin_dd: 306656*2KB out @ average 0.5x1385KBps /dev/scd0: flushing cache /dev/scd0: stopping de-icing /dev/scd0: writing lead-out /dev/scd0: reloading tray alexandria 2.6.12-gentoo-r10 # cat /dev/scd0 | file - cat: /dev/scd0: Input/output error /dev/stdin: empty The unit can be broken or simply doesn't like the particular media brand. Poor media support manifests itself in rather bizarre way. If quality brand media, such as Verbatim, doesn't work talk to your retailer and try to exchange unit. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD Double Layer Playing problem
Thank you very much for taking the time to reply. Most of what you say makes the trouble I am having make sense. But three things do not seem to fit: I never said I know everything, or in other words I can as well be incorrect:-) No warranties implied. 1) I can play the .iso that I made with dd just fine in Xine. This should be just as scrambled as the DVD I burn from it. As far as I understand there're two ways to get scrambling key: a) convince player to give it up; b) brute-force it [which takes like milliseconds]. Xine is using libdvdcss and it's known fact that the latter is perfectly capable of b). If scrambled sectors are marked as such [I believe they are], then they can be identified and key can be brute-forced upon moment first scrambled sector is encountered. It's plausible that that's how .iso playback works. But once again, no warranties implied, as I don't actually consider myself an expert in CSS protection... 2) This procedure has worked to create a copy of a commercial single layer DVD just fine. It's possible that that video content on that particular DVD was not actually scrambled. It's not required by standard... You can even have region-protected media, yet unscrambled content... 3) running diff on the .iso and the (unplayable) mounted burnt DL DVD reported no differences. Keep in mind that scrambling keys reside in DVD control area. You can't copy them with dd, nor can you burn them on copy, so that original and copy *are* different. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems when writing DVDs with growisofs
What data transferrate would you exspect while writing to a DVDRAM? What does media case say? 3x? 2x? But no, not that much... I know, that is slower than DVD+/-RW, since it does verify the data, Keep in mind that data written to DVD-RAM is verified immediately upon write only when explicitly asked for with WRITE AND VERIFY command[*]. Otherwise data verification is performed upon later playback and if block smells deteriorated, then the data is transparently moved to spare area. It should also be noted that advertised velocity of 2-3x can only be observed when you switch off defect control system [or bypass it be means of streaming recording[**]]. So that as defect control is [presumably] on by default, you're likely to observe lower speeds, 1x if not less, so that an order of one hour magnitude for 4GB should be reasonable... [*] growisofs can do this with -use-the-force-luke=wrvfy, also note that Linux kernel does *not* do anything of that sort; [**] for technically minded streaming recording refers to WRITE(12) with streaming bit set; but with my setup it takes hours to write 4GB... Hardware: LG 4163B (A106 firmware, newest stable) Software: Linux 2.6.17.4 (newest stable) formatted with udf (udftools) Mounted directly (no pktcdvd...) I wouldn't put so much faith to Linux UDF write performance. Use ext2 or stick to growisofs:-) One way or another it hardly have anything to do with pktcdvd. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems when writing DVDs with growisofs
...Am I right here ?:When writing to a DVDRAM with growisofs I will get a filesystem identical to that of a DVD: udf or iso9660. Or you can make an empty placeholder on hard disk, losetup it, format to your liking and burn it. I mean growisofs is actually a recording program and formally is filesystem neutral. But it does treat mkisofs output in special way, so you might get an impression that iso9660 is what you get... I heard, that using ext2 or such will kill DVDRAM soon, since there are sectors (blocks? or whatever it is named ... sorry, I am not a native English speaker...) constantly written to, so they will die to soon since there max. write count has been reached. And so would read-write mounted UDF. It's definitely good idea to mount *either* with noatime, but otherwise I don't think that ext2 would wear out the media faster than UDF. Even safer approach would be to keep media mounted read-only for most of the time and re-mount read-write when you actually intend to manipulate data. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: growisofs and PX-716: impossible changing burning speed after the first burn.
- reboot the system;
- put 16x media in unit and collect 'dvd+rw-mediainfo /dev/cdrom
verbose' output;
- perform 8x recording;
- put another 16x media in unit and collect another
'dvd+rw-mediainfo
/dev/cdrom verbose' output;
Send both to me.
Here attached there are the two outputs.
Hope they can be useful.
It sound like firmware bug...
INQUIRY:[PLEXTOR ][DVDR PX-716A ][1.09]
Current Write Speed: 16.0x1385=22160KB/s
Write Speed #0:16.0x1385=22160KB/s
Write Speed #1:12.0x1385=16620KB/s
Write Speed #2:8.0x1385=11080KB/s
Write Speed #3:6.0x1385=8310KB/s
Write Speed #4:4.0x1385=5540KB/s
GET CURRENT PERFORMANCE:
Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] -
16.0x1385=22160KB/[EMAIL PROTECTED]
GET PERFORMANCE:
Speed Descriptor#0:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#1:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#2:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#3:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#4:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
INQUIRY:[PLEXTOR ][DVDR PX-716A ][1.09]
Current Write Speed: 8.0x1385=11080KB/s
Write Speed #0:16.0x1385=22160KB/s
Write Speed #1:12.0x1385=16620KB/s
Write Speed #2:8.0x1385=11080KB/s
Write Speed #3:6.0x1385=8310KB/s
Write Speed #4:4.0x1385=5540KB/s
GET CURRENT PERFORMANCE:
Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] -
16.0x1385=22160KB/[EMAIL PROTECTED]
GET PERFORMANCE:
Speed Descriptor#0:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#1:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#2:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#3:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Speed Descriptor#4:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
Note that GET CURRENT PERFORMANCE returns 16x in both cases, while
Current Write Speed is 8x in second case. The value obtained by GET
CURRENT PERFORMANCE, Write Performance is commonly controlled by SET
STREAMING command, while Current Write Speed [exposed through page
2A] - by SET CD SPEED command. Now, specification says that DVD
recording speed shall be controlled by SET STREAMING, while SET CD
SPEED [as well as page 2A] is retained for legacy CD recording [and
other] software. In other words new software is *expected* to use SET
STREAMING unit is *expected* to respect it. Some units even don't
expose DVD recording velocities through page 2A, and any attempt to
change its values has *no* effect on DVD recordings. Nor should it have
according to specification! And your firmware seems to violate this
clause by favoring Current Write Speed... File bug report to Plextor...
Try if attached snippet can reset Current Write Speed to 16x. Save it
to dvd+rw-tools source directory and compile with 'g++ resetspeed.cpp'.
What it does is send restore all defaults to unit, though through SET
STREAMING command. A.
#include transport.hxx
main(int argc,char *argv[])
{ Scsi_Command cmd;
unsigned char pd[28];
int err;
if (argc2)
fprintf (stderr,usage: %s /dev/dvd\n,argv[0]),
exit(1);
if (!cmd.associate (argv[1]))
fprintf (stderr,%s: unable to open: ,argv[1]), perror (NULL),
exit(1);
memset(pd,0,sizeof(pd));
pd[0]=4; // RDD
cmd[0]=0xB6; // SET STREAMING
cmd[10]=sizeof(pd);
cmd[11]=0;
if ((err=cmd.transport (WRITE,pd,sizeof(pd
sperror (SET STREAMING,err),
exit(1);
}
