Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.

[Paul Menzel]

Dear Thomas,


Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt:

> > Could you please CC me
> 
> I will try to remember. :)
> But maybe you better subscribe by a mail to
>   688229-subscribe at bugs.debian.org

I would like to avoid that, because it also requires confirmation and I
think »Reply to all« is easier. But I will do so next time, it happens.

> > Is there some way to simulate a burner to find out what happened?
> 
> libburn would accept burner addresses like
>   stdio:/tmp/my_emulated_drive
> which would behave like DVD-RAM or DVD+RW. I.e. quite different
> from DVD-R or DVD+R. Nevertheless such an emulated drive would
> allow to exercise the communications between libisofs and libburn,
> as done by Brasero.
> 
> I do not know how to make Brasero use such a drive address.
> Probably one would have to hack its source.

I will take a look.

> Another way to exercise DVD-R is to use DVD-RW. They need to get
> blanked before re-use. E.g. by
>   xorriso -outdev /dev/sr1 -blank deformat -eject all
> This lasts as long as writing the full capacity of 4.7 GB.
> (Fast blanking is possible but the DVD-RW would afterwards refuse
>  to perform the write type Incremental which is used by Brasero.)
> 
> 
> Some numbers from your reports are against my theory of a missing
> start piece:
> 
> libisofs reported:
>     brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %)
> 
> dvd+rw-mediainfo and xorriso -toc report a track size of
>     1059568*2KB
> 
> The overall sizeis of image and track would match.
>     2 * 1059568 - 2119108 = 28
> The track size is aligned to a DVD ECC block of 32 KiB.
> 
> The track was written by write type Incremental. I.e. it
> is supposed to bear only the bytes which were actually written,
> rounded up to the next multiple of 16 blocks (= 32 KiB).
> 
> If a start piece of the image would be missing, then the track
> would have to be shorter.
> 
> Grrrrr.

That really is strange.

> I assume you too live in Germany. If so:
> Would the images on the DVD be non-private enough and would
> you want to invest 1.45 Euro into a mail stamp in order to send
> me that DVD-R for closer inspection ?
> Or do you have 2 GB of internet storage from where i could
> download a copy of the medium made by
>   dd if=/dev/sr1 bs=2048 of=/tmp/copy_of_dev_sr1
> ?

I will try to and will contact you again next week.

> > Everything worked fine with `xorriso`.
> >
> >         $ xorriso -md5 on -outdev /dev/sr1 -map ~/test /
> 
> Well ... Yay and Grrrr at the same time.
> Yay for xorriso and the drive, Grrr for my inability to explain what
> went wrong with the Brsaero DVD-R.

Grrr³ from my side to not understanding anything. ;-)

> > The only thing I noticed, that another DVD drive, the Toshiba DVD-ROM
> > SD-M1712, needed more than 25 seconds to recognize the disc.
> 
> This might be due to the fact that the medium is still appendable,
> unlike the one from Brasero. I.e. you could add more files by xorriso
> or growisofs.
> 
> How is recognition time with the burner ?
> 
> In order to get a closed DVD-R, you would have to use command
>   -close on
> E.g. with the now appendable DVD-R medium
>   $ mkdir ~/test2
>   $ cp ...a...few...files... ~/test2
>   $ xorriso -md5 on -dev /dev/sr1 -map ~/test2 /test2 -close on
> 
> (Note that this run uses command -dev rather than -outdev in order
>  to load the existing directory tree of the image and to merge it
>  with the newly added file tree.)
> 
> Maybe it will then be recognized faster by the DVD-ROM.

Thank you for the detailed explanation. I already gave the DVD away.
Maybe I have a chance to look into it again.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120923/732c2509/attachment.pgp>