[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dvd+rw-tools: another CLOSE SESSION failed


> I've tried to write BD-R in the same way, and got this error:
> >:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]:>

This is indeed a known problem. Andy Polykov, the author of growisofs
once stated that it is harmless. See
But the "next 7.2 release" of growisofs did not happen yet.

libburn (under cdrskin and other programs) handles BD-R slightly
differently than growisofs does (no POW, but simply sequential writing).
I am doing daily backups with BD-R, without getting errors until
drive and medium bail out after a few hundred sessions, although
there is still room on the medium. (It seems wise to start a new
BD-R after about 300 sessions.)

> And I am very confused by the content of the READ DISC INFORMATION
> section
> > Disc status:           appendable
> > Number of Sessions:    1
> > State of Last Session: incomplete
> > "Next" Track:          1
> > Number of Tracks:      2

This looks ok for a BD-R which has one session written and is still
Track number 2 is the "invisible track", which can be used for
further writing and from which the next data track will then be
cut off. After the second session, you will have a smaller invisible
track #3.

> using cdrskin

Thanks for flying cdrskin. :))

> > Disc status:           complete
> > Number of Sessions:    1
> > State of Last Session: complete
> > Number of Tracks:      1

This BD-R has one session and is closed (because you did not use
cdrskin option -multi).

> Actually, the BD-Rs stopped being so expensive (due to LTH), so let's
> find is the cause of this error.

I still need to see a burner that reliably does a dozen sessions
on BD-R LTH. They seem to be ok for a few sessions with modern
burners. (Most honest is my old LG GGW. It refuses to touch LTH.)

> I still do not understand how cdrskin works when Defect Management enabled.

There are two aspects: Formatting and writing.

At formatting time you define how many spare blocks are reserved
for replacing bad blocks. If 0 blocks are reserved or if (only with
BD-R) formatting is omitted, then there can be no Defect Management
at write time.
Formatting BD-R is quick, as there can be made no assessment of
bad blocks. Formatting BD-RE can last long, if all blocks get tested.

At write time, SCSI command WRITE12 allows to choose whether Defect
Management shall actually be performed. This is not guaranteed by
the SCSI MMC specs, but obviously the drives obey the Streaming bit
of WRITE12.
By cdrskin option
you can disable Defect Management at write time.

I must state that Defect Management is not helpful in real life.
It throws errors earlier and if blocks get replaced, the read
performance goes down heavily. Even the mechanical noise of reading
such BD-R media is frightening.
I test BD-R daily in both modes. The unformatted ones always beat
the formatted ones in number of sessions and in read speed.
Not to speak of write speed which is 2 to 3 times slower than
nominal, if Defect Management is enabled.

If a BD-R is bad, then it is bad. One should not use it further,
except for testing.

> In growisofs it
> looks like a single pass, but it takes the same time. Which approach is
> more correct?

The visible difference should be mainly because growisofs and
libburn report differently to the user.
But there is an important invisible difference:

growisofs formats BD-R to Pseudo Overwrite capability. This allows
to replace old written blocks by newly written ones.
So growisofs can perform its genuine (and admirable) stunt for DVD+RW
on BD-R too. It writes a copy of the ISO 9660 superblock to the start
of the medium, so that even the dumbest operating system can find
the last session. (Solaris is said to be unable to recognize BD-R
multi-session. I would not bet on FreeBSD either.)

Except the higher technical difficulty for the drive, this approach
has the disadvantage of hiding the first session as soon as more
sessions have been added. Other than with DVD+RW or BD-RE you will
nevertheless see sessions 2 and further ones.

It would be helpful if growisofs could join the xorriso approach
to start the first session at block 32. On BD-R i would propose to
have a track 1 of only 32 blocks for the superblock copy, and to
start the first data session in track 2. This way, its superblock
would survive the copying after further sessions. It would stay
mountable by mount option sbsector=32 (resp. where track 2 starts).

Have a nice day :)


Reply to: