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 : 14@0
> Track#AA : 17@65264
> Multi-session Info: #1@0
> 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.
Reply to: