>> *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]