Bug #1458230 “libburn imposing 0.2x BD-R burn (5-6 hours)” : Bugs : libburn package : Ubuntu

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2015-05-24:

#1

Hi,

libburn obviously tries to tell the drive the desired speed.
But the drive decides to work much slower, despite promising
speeds up to 12x BD with the given BD-R.

A possible reason could be Defect Management which is caused
by the cdrskin option blank=format_if_needed. It checkreads
the write result after writing about half a drive buffer to
the medium.

But the xorriso run was not told to format its BD-R.
Does dvd+rw-mediainfo report it as formatted after the burn?
(I.e not
  READ FORMAT CAPACITIES:
   unformatted: 12219392*2048=25025314816
but rather
  BD SPARE AREA INFORMATION:
   Spare Area: 196608/196608=100.0% free
)

Do you get better speed from growisofs ?
growisofs -Z /dev/sr0=disc.iso

You could add option
stream_recording=on
to the runs of cdrskin and xorrecord to surely disable Defect
Management.

Have a nice day :)

Thomas

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2015-05-24:

#2

Hi,

i forgot to ask: How is the read speed with this drive ?
Does it deliver dozens of MB per second ?

Do you get better write speeds with DVD media ?
(A DVD+RW at 4x DVD speed should be 5 times as fast as the
write speed you observe with BD-R.)

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-25:

#3

Download full text (4.4 KiB)

Thank you very much for looking into this, and I'll apologise for having, at best, asymptotically approached the scientific method whilst attempting to burn a set of back-up discs.

My first burn used the k3b GUI. I had to install the brandonsnider cdrtools PPA, before it would even start writing to the disc (ref. https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning). This burn proceeded at a reasonable speed but, contrary to (my understanding of) my choice of settings, the disc was finalised (complete, not appendable). (OK, my ISO was not much less than the disc capacity and I won't open myself to ridicule by suggesting I mourned this loss. However, the final disc of the set was to be only half full, and I also wanted to take the opportunity to learn the correct technique.) The only interesting result, from dvd+rw-mediainfo on that disc, is that Speed Descriptor#n is 00/12219391 c.f. 00/11826175 on the cdrskin and xorriso burns I reported earlier. (I've no idea what that means and, hence, the compass of “interesting” might be minimal.)

From this, I turned to the command line (OK, I first tried to obtain silicon-empire, but it appears to have been pulled) and tried a couple of discs with growisofs, both of which were left in the desired, appendable, state, but at the cost of five to six hours' burning:
growisofs -Z /dev/sr0=disc02.iso
growisofs -speed=20 -Z /dev/sr0=disc03.iso

I'll admit, here, that some/all of my speed requests were ambitious. I'd let myself be guided by the dvd+rw-mediainfo output, and forgotten to check the paper, on the top of the spindle, which said “6x”.

So, I then turned to libburn (installing cdrskin & xorriso) :
cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso
xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

And that was where I'd reached when I filed the bug report. (With thanks to ~/.bash_history!)

In answer to your other questions:
I think the xorriso run did format the disc. The dvd+rw-mediainfo output is very similar to that for the cdrskin disc. (Sorry I did not paste that on the original report.)
Reading back the discs seemed fairly fast. I'd checked the md5sums after each burn. I'll capture a more formal metric, if necessary, but I'm confident in saying reading is fine.
I haven't tried disabling defect management. That doesn't sound attractive, but I accept it could be a valuable investigative test.
I've just tried a DVD-RW 2x, in the drive. Performance seemed consistent with my experience with my DVD writers, and I calculated it as proceeding about twice as quickly as the problem BD-Rs.

Subsequent to my posting of the problem report, it did occur to me to check the version details the programs declare (rather than just relying on the package headline):
cdrskin --version
cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn
Cdrecord 2.01a27 Emulation. Copyright (C) 2006-2014, see libburnia-project.org
System adapter : internal GNU/Linux SG_...

Thank you very much for looking into this, and I'll apologise for having, at best, asymptotically approached the scientific method whilst attempting to burn a set of back-up discs.

My first burn used the k3b GUI.  I had to install the brandonsnider cdrtools PPA, before it would even start writing to the disc (ref. https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning).  This burn proceeded at a reasonable speed but, contrary to (my understanding of) my choice of settings, the disc was finalised (complete, not appendable).  (OK, my ISO was not much less than the disc capacity and I won't open myself to ridicule by suggesting I mourned this loss.  However, the final disc of the set was to be only half full, and I also wanted to take the opportunity to learn the correct technique.)  The only interesting result, from dvd+rw-mediainfo on that disc, is that Speed Descriptor#n is 00/12219391 c.f. 00/11826175 on the cdrskin and xorriso burns I reported earlier.  (I've no idea what that means and, hence, the compass of “interesting” might be minimal.)

From this, I turned to the command line (OK, I first tried to obtain silicon-empire, but it appears to have been pulled) and tried a couple of discs with growisofs, both of which were left in the desired, appendable, state, but at the cost of five to six hours' burning:
growisofs  -Z /dev/sr0=disc02.iso
growisofs -speed=20 -Z /dev/sr0=disc03.iso

I'll admit, here, that some/all of my speed requests were ambitious.  I'd let myself be guided by the  dvd+rw-mediainfo output, and forgotten to check the paper, on the top of the spindle, which said “6x”.

So, I then turned to libburn (installing cdrskin & xorriso) :
cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso
xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

And that was where I'd reached when I filed the bug report.  (With thanks to ~/.bash_history!)

In answer to your other questions:
I think the xorriso run did format the disc.  The dvd+rw-mediainfo output is very similar to that for the cdrskin disc.  (Sorry I did not paste that on the original report.)
Reading back the discs seemed fairly fast.  I'd checked the md5sums after each burn.  I'll capture a more formal metric, if necessary, but I'm confident in saying reading is fine.
I haven't tried disabling defect management.  That doesn't sound attractive, but I accept it could be a valuable investigative test.
I've just tried a DVD-RW 2x, in the drive.  Performance seemed consistent with my experience with my DVD writers, and I calculated it as proceeding about twice as quickly as the problem BD-Rs.

Subsequent to my posting of the problem report, it did occur to me to check the version details the programs declare (rather than just relying on the package headline):
cdrskin --version
cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn
Cdrecord 2.01a27 Emulation. Copyright (C) 2006-2014, see libburnia-project.org
System adapter    :  internal GNU/Linux SG_IO adapter sg-linux
libburn interface :  1.3.8
libburn in use    :  1.3.8
cdrskin version   :  1.3.8
Version timestamp :  2014.06.28.060001
Build timestamp   :  -none-given-

xorrecord --version
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.
Cdrecord 2.01-Emulation Copyright (C) 2013 see libburnia-project.org xorriso
xorriso 1.3.2
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2013, Thomas Schmitt <…@gmx.net>, libburnia project.
xorriso version   :  1.3.2
Version timestamp :  2013.08.07.110001
Build timestamp   :  -none-given-
libisofs   in use :  1.3.8  (min. 1.3.6)
libjte     in use :  1.0.0  (min. 1.0.0)
libburn    in use :  1.3.8  (min. 1.3.4)
libburn OS adapter:  internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use :  1.3.2  (min. 1.3.2)
Provided under GNU GPL version 2 or later.
There is NO WARRANTY, to the extent permitted by law.

libisoburn is rather stale, but the change log does not show anything pertinent to my problem as having subsequently been addressed.  (Also, cdrskin --version did not mention that library, which could truly take it out of the equation.)

I will insert the balance of the output I captured, as separate “comments”, in the belief this will aid navigation.

Thank you very much, once again.

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-25:

#4

disc01 burnt with k3b (brandonsnider cdrtools PPA):

INQUIRY: [PIONEER ][BD-RW BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
Mounted Media: 41h, BD-R SRM
Media ID: CMCMAG/BA5
Current Write Speed: 12.0x4495=53940KB/s
Write Speed #0: 12.0x4495=53940KB/s
Write Speed #1: 10.0x4495=44950KB/s
Write Speed #2: 8.0x4495=35960KB/s
Write Speed #3: 6.0x4495=26970KB/s
Write Speed #4: 4.0x4495=17980KB/s
Write Speed #5: 2.0x4495=8990KB/s
Speed Descriptor#0: 00/12219391 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
Speed Descriptor#1: 00/12219391 R@10.0x4495=44950KB/s W@10.0x4495=44950KB/s
Speed Descriptor#2: 00/12219391 R@8.0x4495=35960KB/s W@8.0x4495=35960KB/s
Speed Descriptor#3: 00/12219391 R@6.0x4495=26970KB/s W@6.0x4495=26970KB/s
Speed Descriptor#4: 00/12219391 R@4.0x4495=17980KB/s W@4.0x4495=17980KB/s
Speed Descriptor#5: 00/12219391 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s
READ DISC INFORMATION:
Disc status: complete
Number of Sessions: 1
State of Last Session: complete
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: partial incremental
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 11797440*2KB
Last Recorded Address: 11797439*2KB
FABRICATED TOC:
Track#1 : 14@0
Track#AA : 14@11797440
Multi-session Info: #1@0
READ CAPACITY: 11797440*2048=24161157120

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-25:

#5

disc06 burnt with xorrecord (xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso):

INQUIRY: [PIONEER ][BD-RW BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
Mounted Media: 41h, BD-R SRM
Media ID: CMCMAG/BA5
Current Write Speed: 6.0x4495=26970KB/s
Write Speed #0: 12.0x4495=53940KB/s
Write Speed #1: 10.0x4495=44950KB/s
Write Speed #2: 8.0x4495=35960KB/s
Write Speed #3: 6.0x4495=26970KB/s
Write Speed #4: 4.0x4495=17980KB/s
Write Speed #5: 2.0x4495=8990KB/s
Speed Descriptor#0: 00/11826175 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
Speed Descriptor#1: 00/11826175 R@10.0x4495=44950KB/s W@10.0x4495=44950KB/s
Speed Descriptor#2: 00/11826175 R@8.0x4495=35960KB/s W@8.0x4495=35960KB/s
Speed Descriptor#3: 00/11826175 R@6.0x4495=26970KB/s W@6.0x4495=26970KB/s
Speed Descriptor#4: 00/11826175 R@4.0x4495=17980KB/s W@4.0x4495=17980KB/s
Speed Descriptor#5: 00/11826175 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s
READ DISC INFORMATION:
Disc status: appendable
Number of Sessions: 2
State of Last Session: empty
"Next" Track: 2
Number of Tracks: 2
READ TRACK INFORMATION[#1]:
Track State: partial incremental
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 5216800*2KB
Last Recorded Address: 5216799*2KB
READ TRACK INFORMATION[#2]:
Track State: invisible incremental
Track Start Address: 5216800*2KB
Next Writable Address: 5216800*2KB
Free Blocks: 6609376*2KB
Track Size: 6609376*2KB
FABRICATED TOC:
Track#1 : 14@0
Track#AA : 14@5216800
Multi-session Info: #1@0
READ CAPACITY: 5216800*2048=10684006400

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-25:

#6

Download full text (6.0 KiB)

DVD-RW 2x burning with cdrskin:

INQUIRY: [PIONEER ][BD-RW BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
Mounted Media: 14h, DVD-RW Sequential
Media ID: JVC_VictorW7
Current Write Speed: 2.0x1385=2770KB/s
Write Speed #0: 2.0x1385=2770KB/s
Speed Descriptor#0: 00/2296863 R@2.0x1385=2770KB/s W@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2296864*2KB=4703977472
READ DVD STRUCTURE[#0h]:
Media Book Type: 32h, DVD-RW book [revision 2]
Last border-out at: 2045*2KB=4188160
READ DISC INFORMATION:
Disc status: complete
Number of Sessions: 1
State of Last Session: complete
Number of Tracks: 1
READ FORMAT CAPACITIES:
formatted: 562086*2048=1151152128
00h(800): 2296256*2048=4702732288
10h(10): 2296256*2048=4702732288
15h(10): 2296256*2048=4702732288
READ TRACK INFORMATION[#1]:
Track State: complete
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 562086*2KB
Last Recorded Address: 562085*2KB
FABRICATED TOC:
Track#1 : 14@0
Track#AA : 14@562086
Multi-session Info: #1@0
READ CAPACITY: 562086*2048=1151152128

cdrskin -v dev=/dev/sr0 blank=deformat_sequential
cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn
cdrskin: verbosity level : 1
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
cdrskin: ... scanning for devices done
cdrskin: status 4 burn_disc_full "There is a disc with data on it in the drive"
Current: DVD-RW sequential recording
cdrskin: beginning to blank disc
Starting to write CD/DVD at speed MAX in real BLANK mode for single session.
Last chance to quit, starting real write in 0 seconds. Operation starts.
cdrskin: blanking ( done 1.0% , 189 seconds elapsed )
...
cdrskin: blanking done
Blanking time: 1740.422s

dvd+rw-mediainfo /dev/sr0
INQUIRY: [PIONEER ][BD-RW BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
Mounted Media: 14h, DVD-RW Sequential
Media ID: JVC_VictorW7
Current Write Speed: 2.0x1385=2770KB/s
Write Speed #0: 2.0x1385=2770KB/s
Speed Descriptor#0: 00/2296863 R@2.0x1385=2770KB/s W@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2296864*2KB=4703977472
READ DVD STRUCTURE[#0h]:
Media Book Type: 32h, DVD-RW book [revision 2]
Last border-out at: 2045*2KB=4188160
READ DISC INFORMATION:
Disc status: blank
Number of Sessions: 1
State of Last Session: empty
"Next" Track: 1
Number of Tracks: 1
READ FORMAT CAPACITIES:
unformatted: 2296256*2048=4702732288
00h(800): 2296256*2048=4702732288
10h(10): 2296256*2048=4702732288
15h(10): 2296256*2048=4702732288
READ TRACK INFORMATION[#1]:
Track State: blank
Track Start Address: 0*2KB
Next Writable Address: 0*2KB
Free Blocks: 2296864*2KB
Track Size: 2296864*2KB
READ CAPACITY: 0*2048=0

cdrskin dev=/dev/sr0 -v...

DVD-RW 2x burning with cdrskin:

INQUIRY:                [PIONEER ][BD-RW   BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         14h, DVD-RW Sequential
 Media ID:              JVC_VictorW7
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:        2.0x1385=2770KB/s
 Speed Descriptor#0:    00/2296863 R@2.0x1385=2770KB/s W@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
 Media Book Type:       00h, DVD-ROM book [revision 0]
 Legacy lead-out at:    2296864*2KB=4703977472
READ DVD STRUCTURE[#0h]:
 Media Book Type:       32h, DVD-RW book [revision 2]
 Last border-out at:    2045*2KB=4188160
READ DISC INFORMATION:
 Disc status:           complete
 Number of Sessions:    1
 State of Last Session: complete
 Number of Tracks:      1
READ FORMAT CAPACITIES:
 formatted:		562086*2048=1151152128
 00h(800):		2296256*2048=4702732288
 10h(10):		2296256*2048=4702732288
 15h(10):		2296256*2048=4702732288
READ TRACK INFORMATION[#1]:
 Track State:           complete
 Track Start Address:   0*2KB
 Free Blocks:           0*2KB
 Track Size:            562086*2KB
 Last Recorded Address: 562085*2KB
FABRICATED TOC:
 Track#1  :             14@0
 Track#AA :             14@562086
 Multi-session Info:    #1@0
READ CAPACITY:          562086*2048=1151152128

cdrskin -v dev=/dev/sr0 blank=deformat_sequential
cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn
cdrskin: verbosity level : 1
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
cdrskin: ... scanning for devices done
cdrskin: status 4 burn_disc_full "There is a disc with data on it in the drive"
Current: DVD-RW sequential recording
cdrskin: beginning to blank disc
Starting to write CD/DVD at speed MAX in real BLANK mode for single session.
Last chance to quit, starting real write in   0 seconds. Operation starts.
cdrskin: blanking ( done 1.0% , 189 seconds elapsed )          
...
cdrskin: blanking done                                          
Blanking time:   1740.422s

dvd+rw-mediainfo /dev/sr0
INQUIRY:                [PIONEER ][BD-RW   BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         14h, DVD-RW Sequential
 Media ID:              JVC_VictorW7
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:        2.0x1385=2770KB/s
 Speed Descriptor#0:    00/2296863 R@2.0x1385=2770KB/s W@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
 Media Book Type:       00h, DVD-ROM book [revision 0]
 Legacy lead-out at:    2296864*2KB=4703977472
READ DVD STRUCTURE[#0h]:
 Media Book Type:       32h, DVD-RW book [revision 2]
 Last border-out at:    2045*2KB=4188160
READ DISC INFORMATION:
 Disc status:           blank
 Number of Sessions:    1
 State of Last Session: empty
 "Next" Track:          1
 Number of Tracks:      1
READ FORMAT CAPACITIES:
 unformatted:		2296256*2048=4702732288
 00h(800):		2296256*2048=4702732288
 10h(10):		2296256*2048=4702732288
 15h(10):		2296256*2048=4702732288
READ TRACK INFORMATION[#1]:
 Track State:           blank
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:           2296864*2KB
 Track Size:            2296864*2KB
READ CAPACITY:          0*2048=0

cdrskin dev=/dev/sr0 -v padsize=300k -multi WindowsBlue-ClientwithApps-64bit-EnglishUnitedKingdom-2358828.iso 
cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn
cdrskin: verbosity level : 1
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
cdrskin: ... scanning for devices done
cdrskin: beginning to burn disc
cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
Current: DVD-RW sequential recording
Track 01: data  3584 MB         padsize:  300 KB
Total size:     3584 MB (407:53.97) = 1835398 sectors
Lout start:     3584 MB (407:55/97) = 1835548 sectors
Starting to write CD/DVD at speed MAX in real TAO mode for multi session.
Last chance to quit, starting real write in   0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
Starting new track at sector: 0
Track 01:   50 of 3584 MB written (fifo 100%) [buf  97%]   2.0x.
...
Track 01: 3584 of 3584 MB written (fifo 100%) [buf  97%]   2.0x.              
cdrskin: thank you for being patient for 1374 seconds                     
Fixating...
cdrskin: working post-track (burning since 1419 seconds)        
Track 01: Total bytes read/written: 3758587904/3758915584 (1835408 sectors).
Writing  time:  1419.430s
Cdrskin: fifo had 1835248 puts and 1835248 gets.
Cdrskin: fifo was 0 times empty and 310542 times full, min fill was 99%.
Min drive buffer fill was 97%
cdrskin: burning done

dvd+rw-mediainfo /dev/sr0INQUIRY:                [PIONEER ][BD-RW   BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         14h, DVD-RW Sequential
 Media ID:              JVC_VictorW7
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:        2.0x1385=2770KB/s
 Speed Descriptor#0:    00/2296863 R@2.0x1385=2770KB/s W@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
 Media Book Type:       00h, DVD-ROM book [revision 0]
 Legacy lead-out at:    2296864*2KB=4703977472
READ DVD STRUCTURE[#0h]:
 Media Book Type:       32h, DVD-RW book [revision 2]
 Last border-out at:    2045*2KB=4188160
READ DISC INFORMATION:
 Disc status:           appendable
 Number of Sessions:    2
 State of Last Session: empty
 "Next" Track:          2
 Number of Tracks:      2
READ FORMAT CAPACITIES:
 formatted:		1835408*2048=3758915584
 00h(800):		2296256*2048=4702732288
 10h(10):		2296256*2048=4702732288
 15h(10):		2296256*2048=4702732288
READ TRACK INFORMATION[#1]:
 Track State:           complete incremental
 Track Start Address:   0*2KB
 Free Blocks:           0*2KB
 Track Size:            1835408*2KB
 Last Recorded Address: 1835407*2KB
READ TRACK INFORMATION[#2]:
 Track State:           invisible incremental
 Track Start Address:   1882528*2KB
 Next Writable Address: 1882528*2KB
 Free Blocks:           413728*2KB
 Track Size:            413728*2KB
FABRICATED TOC:
 Track#1  :             14@0
 Track#AA :             14@1835408
 Multi-session Info:    #1@0
READ CAPACITY:          1835408*2048=3758915584

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-25:

#7

Sorry, looking back on this, I recognise I burnt only three of the BD-Rs with libburn, not the four I'd claimed. The exaggeration was entirely unintentional.

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2015-05-25:

#8

Download full text (3.3 KiB)

Hi,

everything points towards Defect Management which seems to
be extremely slow with the given drive and BD-R media.
It normally slows down writing by a factor of 2 or 3 but not
by 10 or 20.

So the option stream_recording=on of cdrskin and xorrecord
is worth a try with the next BD-R you burn.

There remains the question why the BD-R written by your
xorrecord run is formatted despite you did not use option
blank=format_if_needed.

-----------------------------------------------------------
Reasoning:

> cdrtools [...] proceeded at a reasonable speed

cdrecord does not format the BD-R and thus no Defect Management
is employed while writing.

> growisofs [...] at the cost of five to six hours' burning

growisofs always formats, uses no stream recording, and thus
always employs Defect Management.

> I think the xorriso run did format the disc.

It should not have done it with the arguments you showed.
Whatever, there is still the option stream_recording=on
which should compensate for the speed effect of formatting.
(... and make formatting more or less senseless.)

> I've just tried a DVD-RW 2x, in the drive. Performance seemed consistent
> with my experience with my DVD writers, and I calculated it as proceeding
> about twice as quickly as the problem BD-Rs.

2x DVD = 2.7 MB/s. That's plausible in comparison to the
1 MB/s you measure with BD-R.

So most probably the hardware connection is not to blame.

> libisoburn [1.3.2] is rather stale,

It's ok for the purpose.
Anyway, libburn is the one which operates the drive.
The BD stuff did not change much since many years.

> disc06 burnt with xorrecord (xorrecord -v dev=/dev/sr0 speed=26970k
> fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k
> disc06.iso):

It does not report BD spare area which i would expect if
it is formatted. But the announced size is smaller than the
unformatted size.

Can you show the output of the growisofs written BD-R or the
one which you wrote with cdrskin option blank=format_if_needed ?

Please also run with the xorriso-written BD-R

xorriso -outdev /dev/sr0 -list_formats

and show the output.

> The only interesting result, from dvd+rw-mediainfo on that disc, is that
> Speed Descriptor#n is 00/12219391 c.f. 00/11826175 on the cdrskin and
> xorriso burns I reported earlier. (I've no idea what that means and,
> hence, the compass of "interesting" might be minimal.

Speed descriptors are the way how the drive tells the burn
program the speeds offered with the loaded medium.
Theoretically a speed descriptor could be valid only for
a part of the medium (with other speed on the rest). Therefore
the speed descriptors tell the end address of their valid
block range. In practice all ranges end at the medium end.
Further the drive decides on its own how fast it really burns.

The xorriso-written BD-R reports a range up to 11826175 blocks
which is the end address of default size formatted BD-R.
The cdrecord-written BD-R reports 12219391 which is the end
of an unformatted BD-R.
See also output of dvd+rw-mediainfo on a blank BD-R:
> READ FORMAT CAPACITIES:
> unformatted: 12219392*2048=25025314816
> 00h(3000): 11826176*2048=2422000...

Hi,

everything points towards Defect Management which seems to
be extremely slow with the given drive and BD-R media.
It normally slows down writing by a factor of 2 or 3 but not
by 10 or 20.

So the option  stream_recording=on  of cdrskin and xorrecord
is worth a try with the next BD-R you burn.

There remains the question why the BD-R written by your
xorrecord run is formatted despite you did not use option
blank=format_if_needed.

-----------------------------------------------------------
Reasoning:

> cdrtools [...] proceeded at a reasonable speed

cdrecord does not format the BD-R and thus no Defect Management
is employed while writing.

> growisofs [...] at the cost of five to six hours' burning

growisofs always formats, uses no stream recording, and thus
always employs Defect Management.

> I think the xorriso run did format the disc.

It should not have done it with the arguments you showed.
Whatever, there is still the option stream_recording=on
which should compensate for the speed effect of formatting.
(... and make formatting more or less senseless.)

> I've just tried a DVD-RW 2x, in the drive.  Performance seemed consistent
> with my experience with my DVD writers, and I calculated it as proceeding
> about twice as quickly as the problem BD-Rs.

2x DVD = 2.7 MB/s. That's plausible in comparison to the
1 MB/s you measure with BD-R.

So most probably the hardware connection is not to blame.

> libisoburn [1.3.2] is rather stale,

It's ok for the purpose.
Anyway, libburn is the one which operates the drive.
The BD stuff did not change much since many years.

> disc06 burnt with xorrecord (xorrecord -v dev=/dev/sr0 speed=26970k
> fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k
> disc06.iso):

It does not report BD spare area which i would expect if
it is formatted. But the announced size is smaller than the
unformatted size.

Can you show the output of the growisofs written BD-R or the
one which you wrote with cdrskin option blank=format_if_needed ?

Please also run with the xorriso-written BD-R

xorriso -outdev /dev/sr0 -list_formats

and show the output.

> The only interesting result, from dvd+rw-mediainfo on that disc, is that
> Speed Descriptor#n is 00/12219391 c.f. 00/11826175 on the cdrskin and
> xorriso burns I reported earlier.  (I've no idea what that means and,
> hence, the compass of "interesting" might be minimal.

Speed descriptors are the way how the drive tells the burn
program the speeds offered with the loaded medium.
Theoretically a speed descriptor could be valid only for
a part of the medium (with other speed on the rest). Therefore
the speed descriptors tell the end address of their valid
block range. In practice all ranges end at the medium end.
Further the drive decides on its own how fast it really burns.

The xorriso-written BD-R reports a range up to 11826175 blocks
which is the end address of default size formatted BD-R.
The cdrecord-written BD-R reports 12219391 which is the end
of an unformatted BD-R.
See also output of dvd+rw-mediainfo on a blank BD-R:
> READ FORMAT CAPACITIES:
>  unformatted:           12219392*2048=25025314816
>  00h(3000):             11826176*2048=24220008448

(Just how did the xorriso-written BD-R get formatted ... ?)

----------------------------------------------------------------

Have a nice day :)

Thomas

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2015-05-25:

#9

Hi,

some corrections to my previous mail:

i wrote:
> growisofs always formats

growisofs formats BD-R by default but also can keep them
unformatted if its undocumented option
-use-the-force-luke=spare=none
is used and the medium is not yet formatted. In this case it
is supposed to burn with full nominal speed.
(cdrskin and xorriso are supposed not to format by default,
but only if options like cdrskin's blank=format_if_needed are used.)

I wrote:
> The xorriso-written BD-R reports a range up to 11826175 blocks

Should have been:
The xorriso-written BD-R reports a range up to block 11826175.
(That's 11826176 blocks from 0 to 11826175.)

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-31:

#10

Archive of results from dvd+rw-mediainfo and xorriso -list_formats Edit (1.4 KiB, application/octet-stream)

Hi,

Thank your for the answers, and sorry I've been a while in responding.

I am preparing more data for back-up, and my plan is to reinstate my Windows XP partition and investigate Blue-ray BD-R burning behaviour with (probably) CDBurnerXP.

I agree that the evidence suggest that Defect Management is a necessary condition for the problem, but, as you said, it should not be having an order of magnitude effect on the writing speed. If my experience is similar, in XP, I will buy a different brand of BD-R, and, if that makes little difference, try to reject the drive.

Summarising all “experiments” so far:

1) K3b
2) growisofs -Z /dev/sr0=disc02.iso
3) growisofs -speed=20 -Z /dev/sr0=disc03.iso
4) cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
5) cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso
6) xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

1) K3b
Mounted Media: 41h, BD-R SRM
Speed Descriptor#0: 00/12219391 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
Disc status: complete

Media current: BD-R sequential recording
Media status : is written , is closed
Media summary: 1 session, 11797440 data blocks, 22.5g data, 0 free
Format status: written, with 23866.0 MiB
BD Spare Area: 0 blocks consumed, 0 blocks available

2) growisofs -Z /dev/sr0=disc02.iso
3) growisofs -speed=20 -Z /dev/sr0=disc03.iso

Mounted Media: 41h, BD-R SRM+POW
Speed Descriptor#0: 00/12088319 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
POW RESOURCES INFORMATION:
Remaining Replacements:16843296
Remaining Map Entries: 0
Remaining Updates: 0

Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 12088320 data blocks, 23.1g data, 568m free
Format status: written, with 23610.0 MiB
BD Spare Area: 0 blocks consumed, 65536 blocks available

4) cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
5) cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso

Mounted Media: 41h, BD-R SRM
Speed Descriptor#0: 00/11826175 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s

Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 11797440 data blocks, 22.5g data, 56.1m free
Format status: written, with 23098.0 MiB
BD Spare Area: 0 blocks consumed, 196608 blocks available

6) xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

Exactly as 4) & 5), except for reflecting that a smaller ISO was written to 6).

I am attaching an archive of the direct “dvd+rw-mediainfo /dev/sr0” and “xorriso -outdev /dev/sr0 -list_formats” output for each disc.

Hi,

Thank your for the answers, and sorry I've been a while in responding.

I am preparing more data for back-up, and my plan is to reinstate my Windows XP partition and investigate Blue-ray BD-R burning behaviour with (probably) CDBurnerXP.

I agree that the evidence suggest that Defect Management is a necessary condition for the problem, but, as you said, it should not be having an order of magnitude effect on the writing speed.  If my experience is similar, in XP, I will buy a different brand of BD-R, and, if that makes little difference, try to reject the drive.

Summarising all “experiments” so far:

1) K3b
2) growisofs  -Z /dev/sr0=disc02.iso
3) growisofs -speed=20 -Z /dev/sr0=disc03.iso
4) cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
5) cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso
6) xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

1) K3b
Mounted Media:         41h, BD-R SRM
Speed Descriptor#0:    00/12219391 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
Disc status:           complete

Media current: BD-R sequential recording
Media status : is written , is closed
Media summary: 1 session, 11797440 data blocks, 22.5g data,     0 free
Format status: written, with 23866.0 MiB
BD Spare Area: 0 blocks consumed, 0 blocks available

2) growisofs  -Z /dev/sr0=disc02.iso
3) growisofs -speed=20 -Z /dev/sr0=disc03.iso

Mounted Media:         41h, BD-R SRM+POW
Speed Descriptor#0:    00/12088319 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s
POW RESOURCES INFORMATION:
 Remaining Replacements:16843296
 Remaining Map Entries: 0
 Remaining Updates:     0

Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 12088320 data blocks, 23.1g data,  568m free
Format status: written, with 23610.0 MiB
BD Spare Area: 0 blocks consumed, 65536 blocks available

4) cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso
5) cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso

Mounted Media:         41h, BD-R SRM
Speed Descriptor#0:    00/11826175 R@12.0x4495=53940KB/s W@12.0x4495=53940KB/s

Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 11797440 data blocks, 22.5g data, 56.1m free
Format status: written, with 23098.0 MiB
BD Spare Area: 0 blocks consumed, 196608 blocks available

6) xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso

Exactly as 4) & 5), except for reflecting that a smaller ISO was written to 6).

I am attaching an archive of the direct “dvd+rw-mediainfo /dev/sr0” and “xorriso -outdev /dev/sr0 -list_formats” output for each disc.

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2015-05-31:

#11

Hi,

> If my experience is
> similar, in XP, I will buy a different brand of BD-R, and, if that makes
> little difference, try to reject the drive.

I am curious about the outcome.

Just for the records resp. future use:

Formatting BD-R and using it with Defect Management:

growisofs -Z /dev/sr0=...iso

  cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          blank=format_if_needed \
          ...iso

  xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          blank=format_overwrite \
          ...iso

Not formatting BD-R and thus not using Defect Management:

growisofs -use-the-force-luke=spare=none -Z /dev/sr0=...iso

cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m ...iso

xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m ...iso

Formatting without immediate writing:

dvd+rw-format /dev/sr0

cdrskin dev=/dev/sr0 -v blank=format_overwrite

xorriso -outdev /dev/sr0 -format fast

Writing to formatted BD-R without Defect Management:

  cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          stream_recording=on \
          ...iso

  xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          stream_recording=on \
          ...iso

Reasoning for change proposals with cdrskin and xorriso:

The extended verbosity of cdrskin -v -v seems not needed.
A single -v allows important messages and progress messages.

padsize=300k is needed only for CD TAO in order to work
around a traditional bug in the Linux kernel at read time.
BD-R cannot trigger that bug. So i propose padsize=0.

speed=10 and --adjust_speed_to_drive are options for special
occasions. Best is to let the drive decide about speed.

xorrecord --grow_overwriteable_iso is only useful with
overwritable media, e.g. with BD-RE and even there one
should consider to use native xorriso instead. It is not
applicable to BD-R and thus ignored.

blank=as_needed is not very appropriate for BD-R either.
It will assert that the medium is blank, nevertheless.

A larger fifo will help with achieving full nominal speed.
After all, 64 MB are only about 1.5 seconds at 10x BD speed.

Have a nice day :)

Thomas

Hi,

> If my experience is
> similar, in XP, I will buy a different brand of BD-R, and, if that makes
> little difference, try to reject the drive.

I am curious about the outcome.

Just for the records resp. future use:

Formatting BD-R and using it with Defect Management:
  
  growisofs -Z /dev/sr0=...iso
  
  cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          blank=format_if_needed \
          ...iso
  
  xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          blank=format_overwrite \
          ...iso

Not formatting BD-R and thus not using Defect Management:

growisofs -use-the-force-luke=spare=none -Z /dev/sr0=...iso

cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m ...iso

xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m ...iso

Formatting without immediate writing:

dvd+rw-format /dev/sr0

cdrskin dev=/dev/sr0 -v blank=format_overwrite

xorriso -outdev /dev/sr0 -format fast

Writing to formatted BD-R without Defect Management:

cdrskin dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          stream_recording=on \
          ...iso

xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m \
          stream_recording=on \
          ...iso

Reasoning for change proposals with cdrskin and xorriso:

The extended verbosity of cdrskin -v -v seems not needed.
A single -v allows important messages and progress messages.

padsize=300k is needed only for CD TAO in order to work
around a traditional bug in the Linux kernel at read time.
BD-R cannot trigger that bug. So i propose padsize=0.

speed=10 and --adjust_speed_to_drive are options for special
occasions. Best is to let the drive decide about speed.

xorrecord --grow_overwriteable_iso is only useful with
overwritable media, e.g. with BD-RE and even there one
should consider to use native xorriso instead. It is not
applicable to BD-R and thus ignored.

blank=as_needed is not very appropriate for BD-R either.
It will assert that the medium is blank, nevertheless.

A larger fifo will help with achieving full nominal speed.
After all, 64 MB are only about 1.5 seconds at 10x BD speed.

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-05-31:

#12

Hi Thomas,

Thank you very much for all the recommended commands, and your careful explanations. I'm about to copy these to my own stash of notes.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-11-15:

#13

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libburn (Ubuntu):
status:	New → Confirmed

Revision history for this message

Njorl (usingcoconuts) wrote on 2015-11-16:

#14

My work on verifying that this is genuinely a problem in libburn has stalled. I apologise for this, but more so for having neglected to provide a potentially critical interim update (which now follows upon the prompting of someone having clicked a “me too” button).

Whilst I was in the process of preparing back-ups, for eventual storage on BD-R (hence, in effect, gathering the materials for further testing of the behaviour I'd reported), I became aware that all USB ports on the “test” computer were version 1.1. (I have no explanation of how this had eluded me for so very long.)

The laws of physics seem to establish that, for my initial burn, using the k3b GUI, I must have got the ISO image onto an internal HD. My memory is does not assist me with that point, though.

Certainly, all the libburn Blu-ray burns (but not the libburn DVD-RW test burn) were of ISOs held on an external HD, connected via a USB port (now recognised as USB 1.1). (I suspect I'd fooled myself by creating the ISOs using a laptop, rather than the desktop in which the burner is mounted!)

Pulling out some xoriso stats, from my earlier post:
xorriso : UPDATE : 10189 of 10189 MB written (fifo 0%) [buf 60%] 0.2x.
xorriso : UPDATE : Closing track/session. Working since 10285 seconds

My burn speed was 0.99 MB/s or 7.9 Mbit/s. USB 1.1 is rated at a maximum of 12 Mbit/s. I could not find a definite answer as to whether that is for the payload or for payload + error correction + control, but it does not seem unreasonable to think the 7.9 Mbit/s was the limit of my USB connection.

I subsequently put a USB 2.0 card into the PC, but it will be a few weeks before I can pick up the testing again. For the moment, I think the most likely conclusion for this bug report is closure on grounds of raiser's idiocy. However, I suggest that anyone, who feels he may be experiencing this “bug”, posts his detailed observations (ideally without missing the obvious).

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2016-04-17:

#15

Hi,

can we close this bug as either:
- not reproducible under proper hardware conditions,
- or as caused by insufficient data source bandwidth ?

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2016-04-17:

#16

Thomas,

I slightly favour the second option as, although I think it is not yet strictly proven, whereas the first is one of those assertions that stands until disproven, it does have a reasonable chance of pointing anyone who suffers a similar issue in the right direction fairly quickly.

I may actually be ready to retest, in the next couple of months, but the Linux distribution has gone out of support and I'll probably replace it beforehand. So, testing will be so far from scientific conditions as to carry no significance unless it, against all expectation, reproduces the problem. (My Blu-ray writer has not exactly earnt its keep in its first year.)

Any possibility for making libburn more idiot-proof? If the log had been able to decompose how the burn speed was determined, I might have managed to check up on the bottleneck - and have avoided this drain on your time.

Assuming this thread does not become locked, I will report my eventual success with libburn.

Happy New Year!

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2016-04-17:

#17

Hi,

Njorl wrote:
> Any possibility for making libburn more idiot-proof? If the log had
> been able to decompose how the burn speed was determined, I might have
> managed to check up on the bottleneck - and have avoided this drain on
> your time.

First i would have to make myself idiot-proof.

In hindsight the pacifier messages give a clear indication:

>> xorrecord ... fs=8m ...
>> xorriso : UPDATE : 10186 of 10189 MB written (fifo 1%) [buf 78%] 0.2x.

If the software fifo is at 1% of 8 MB = 80 kB while there are still 3 MB
to burn, then the input side of xorriso is not fast enough.

The drive buffer stays filled at about 60 to 80 % because the drive sees
no urgent need for writing. It rather waits until the buffer is nearly
full before it puts the data on medium.

----------------------------------------------------------------------

So i now officially declare that the problem was caused by insufficient
data source bandwidth.

USB 1 has at most 12 MBit/s. The shown xorriso run burned 10189 MB in
10286 seconds. That's 990 kByte/s = 7.925 MBit/s net payload.
This matches well enough to consider USB 1 the original cause of the
poor input speed.
In any case, USB 1 is not fast enough for normal DVD or BD burning.
1x DVD = 1385 kB/s , 1x BD = 4495 kB/s.

----------------------------------------------------------------------

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2016-06-15:

#18

Download full text (3.8 KiB)

Success, at last!

I burnt a couple of BD-R discs, on Monday, using a USB 2 card, fitted into the problem PC, as the source external HD connection, and the rate was roughly 22 GiB in half an hour.

Here's the tail end of the output:

xorriso : UPDATE : 22408 of 22530 MB written (fifo 98%) [buf 96%] 3.3x.
xorriso : UPDATE : 22421 of 22530 MB written (fifo 99%) [buf 96%] 3.1x.
xorriso : UPDATE : 22435 of 22530 MB written (fifo 99%) [buf 96%] 3.2x.
xorriso : UPDATE : 22449 of 22530 MB written (fifo 99%) [buf 96%] 3.3x.
xorriso : UPDATE : 22463 of 22530 MB written (fifo 98%) [buf 96%] 3.3x.
xorriso : UPDATE : 22477 of 22530 MB written (fifo 83%) [buf 96%] 3.1x.
xorriso : UPDATE : 22490 of 22530 MB written (fifo 62%) [buf 90%] 3.1x.
xorriso : UPDATE : 22505 of 22530 MB written (fifo 39%) [buf 96%] 3.3x.
xorriso : UPDATE : 22519 of 22530 MB written (fifo 17%) [buf 96%] 3.3x.
xorriso : UPDATE : 22530 of 22530 MB written (fifo 0%) [buf 100%] 2.6x.
xorriso : UPDATE : Closing track/session. Working since 1732 seconds
xorriso : UPDATE : Closing track/session. Working since 1733 seconds
Writing to '/dev/sr0' completed successfully.

xorriso : NOTE : Re-assessing -outdev '/dev/sr0'
Drive current: -outdev '/dev/sr0'
Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 11535712 data blocks, 22.0g data, 567m free

The big difference, of course, is the fifo being loaded to 90-something percent through most of the writing.

So, I have no evidence that this was a libburn bug. Everything points to my problem's cause being inappropriate hardware (namely, a USB 1.x interface in the path to the ISO file).

Additional detail:

Cdrecord 2.01-Emulation Copyright (C) 2013 see libburnia-project.org xorriso
xorriso 1.3.2
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2013, Thomas Schmitt <email address hidden>, libburnia project.
xorriso version : 1.3.2
Version timestamp : 2013.08.07.110001
Build timestamp : -none-given-
libisofs in use : 1.3.8 (min. 1.3.6)
libjte in use : 1.0.0 (min. 1.0.0)
libburn in use : 1.3.8 (min. 1.3.4)
libburn OS adapter: internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use : 1.3.2 (min. 1.3.2)
Provided under GNU GPL version 2 or later.
There is NO WARRANTY, to the extent permitted by law.

$ dvd+rw-mediainfo /dev/sr0

INQUIRY: [PIONEER ][BD-RW BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
Mounted Media: 41h, BD-R SRM
Media ID: CMCMAG/BA5
Current Write Speed: 8.0x4495=35960KB/s
Write Speed #0: 8.0x4495=35960KB/s
Write Speed #1: 6.0x4495=26970KB/s
Write Speed #2: 4.0x4495=17980KB/s
Write Speed #3: 2.0x4495=8990KB/s
Speed Descriptor#0: 00/11826175 R@8.0x4495=35960KB/s W@8.0x4495=35960KB/s
Speed Descriptor#1: 00/11826175 R@6.0x4495=26970KB/s W@6.0x4495=26970KB/s
Speed Descriptor#2: 00/11826175 R@4.0x4495=17980KB/s W@4.0x4495=17980KB/s
Speed Descriptor#3: 00/11826175 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s
READ DISC INFORMATION:
Disc status: appendable
Number of Sessions: 2
State of Last Sessi...

Success, at last!

I burnt a couple of BD-R discs, on Monday, using a USB 2 card, fitted into the problem PC, as the source external HD connection, and the rate was roughly 22 GiB in half an hour.

Here's the tail end of the output:

xorriso : UPDATE : 22408 of 22530 MB written (fifo 98%) [buf  96%]   3.3x.
xorriso : UPDATE : 22421 of 22530 MB written (fifo 99%) [buf  96%]   3.1x.
xorriso : UPDATE : 22435 of 22530 MB written (fifo 99%) [buf  96%]   3.2x.
xorriso : UPDATE : 22449 of 22530 MB written (fifo 99%) [buf  96%]   3.3x.
xorriso : UPDATE : 22463 of 22530 MB written (fifo 98%) [buf  96%]   3.3x.
xorriso : UPDATE : 22477 of 22530 MB written (fifo 83%) [buf  96%]   3.1x.
xorriso : UPDATE : 22490 of 22530 MB written (fifo 62%) [buf  90%]   3.1x.
xorriso : UPDATE : 22505 of 22530 MB written (fifo 39%) [buf  96%]   3.3x.
xorriso : UPDATE : 22519 of 22530 MB written (fifo 17%) [buf  96%]   3.3x.
xorriso : UPDATE : 22530 of 22530 MB written (fifo  0%) [buf 100%]   2.6x.
xorriso : UPDATE : Closing track/session. Working since 1732 seconds
xorriso : UPDATE : Closing track/session. Working since 1733 seconds
Writing to '/dev/sr0' completed successfully.

xorriso : NOTE : Re-assessing -outdev '/dev/sr0'
Drive current: -outdev '/dev/sr0'
Media current: BD-R sequential recording
Media status : is written , is appendable
Media summary: 1 session, 11535712 data blocks, 22.0g data,  567m free

The big difference, of course, is the fifo being loaded to 90-something percent through most of the writing.

So, I have no evidence that this was a libburn bug.  Everything points to my problem's cause being inappropriate hardware (namely, a USB 1.x interface in the path to the ISO file).

Additional detail:

Cdrecord 2.01-Emulation Copyright (C) 2013 see libburnia-project.org xorriso
xorriso 1.3.2
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2013, Thomas Schmitt <scdbackup@gmx.net>, libburnia project.
xorriso version   :  1.3.2
Version timestamp :  2013.08.07.110001
Build timestamp   :  -none-given-
libisofs   in use :  1.3.8  (min. 1.3.6)
libjte     in use :  1.0.0  (min. 1.0.0)
libburn    in use :  1.3.8  (min. 1.3.4)
libburn OS adapter:  internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use :  1.3.2  (min. 1.3.2)
Provided under GNU GPL version 2 or later.
There is NO WARRANTY, to the extent permitted by law.

$ dvd+rw-mediainfo /dev/sr0

INQUIRY:                [PIONEER ][BD-RW   BDR-209M][1.20]
GET [CURRENT] CONFIGURATION:
 Mounted Media:         41h, BD-R SRM
 Media ID:              CMCMAG/BA5
 Current Write Speed:   8.0x4495=35960KB/s
 Write Speed #0:        8.0x4495=35960KB/s
 Write Speed #1:        6.0x4495=26970KB/s
 Write Speed #2:        4.0x4495=17980KB/s
 Write Speed #3:        2.0x4495=8990KB/s
 Speed Descriptor#0:    00/11826175 R@8.0x4495=35960KB/s W@8.0x4495=35960KB/s
 Speed Descriptor#1:    00/11826175 R@6.0x4495=26970KB/s W@6.0x4495=26970KB/s
 Speed Descriptor#2:    00/11826175 R@4.0x4495=17980KB/s W@4.0x4495=17980KB/s
 Speed Descriptor#3:    00/11826175 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s
READ DISC INFORMATION:
 Disc status:           appendable
 Number of Sessions:    2
 State of Last Session: empty
 "Next" Track:          2
 Number of Tracks:      2
READ TRACK INFORMATION[#1]:
 Track State:           partial incremental
 Track Start Address:   0*2KB
 Free Blocks:           0*2KB
 Track Size:            11535712*2KB
 Last Recorded Address: 11535711*2KB
READ TRACK INFORMATION[#2]:
 Track State:           invisible incremental
 Track Start Address:   11535712*2KB
 Next Writable Address: 11535712*2KB
 Free Blocks:           290464*2KB
 Track Size:            290464*2KB
FABRICATED TOC:
 Track#1  :             14@0
 Track#AA :             14@11535712
 Multi-session Info:    #1@0
READ CAPACITY:          11535712*2048=23625138176

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2016-06-15:

#19

Hi,

all looks well for a run with 8x nominal speed and Defect Management enabled.

You may try to get higher speed by omitting cdrskin option
blank=format_if_needed
or by using option
stream_recording=on
with BD-R media which are already formatted or with BD-RE media (which will
get formatted automatically and inavoidably).

---------------------------------------------------------------

If anybody is watching who can close this bug, then please do.
The problem won't fix because we cannot squeeze enough bandwidth
out of a USB 1 connection.

Have a nice day :)

Thomas

Revision history for this message

Njorl (usingcoconuts) wrote on 2016-06-15:

#20

Thank you, once again, Thomas.

I've noticed I omitted to post the command line:
xorrecord dev=/dev/sr0 -v padsize=0 -multi fs=64m blank=format_overwrite Disc01.iso

I hope I'd followed your recommendation correctly.

I am far from unhappy with the writing speed. Considering it has taken me a year to accumulate enough data for a couple of BD-Rs, this is far from the most important aspect of my life to begin optimising! (I got the BD writer to save time versus writing multiple DVDs, but, thanks to my stupid oversight with the USB port, it may now be several centuries before I have a credit balance.)

As long as writing speed is reasonable, what is important for me is the quality of the recording; any time spent backing-up is waisted if you can't recover the data from the media when you need them, of course.

I am considering having a go with cdck (I hope hearing about that doesn't send its developers into hiding), but I wonder how much this is verging on paranoia. I burnt a second copy of each ISO, which should give me a high probability of full recovery using gddrescue, if the time comes.

By the way, I THINK I noticed that, during the formatting stage, each successive status line reported progress as 1%. Not really an issue, as the formatting completes before I have time to worry.

Best wishes for an idiot-free future.

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2016-06-16:

#21

Hi,

> I hope I'd followed your recommendation correctly.

The xorriso command looks ok. If you do not plan to produce and
burn add-on ISO sessions you may omit option -multi.

> I burnt a second copy of each ISO, which should
> give me a high probability of full recovery using gddrescue, if the time
> comes.

You should record own checksums additionally to those of the media
which decide over read succes versus i/o error. After some rescue tool
pieced together an alleged repaired version of the ISO you need means
to verify this.

xorrisofs offers option --md5, xoriso offers command -md5 "on".
Both will put MD5 sums into the ISO which can at any time later
checked by xorriso commands -check_media and -check_md5_r.

> during the formatting stage, each successive status line reported
> progress as 1%.

It depends much on the willingness of the drive to indicate progress.
libburn sends a SCSI command to which the drive is supposed to reply
a number between 0 and 65535. This number represents a range of 0 to
100 percent. For reasons of plausibility i rather map it to 1 to 99
percent.
So probably your drive returned 0 all the time.

Have a nice day :)

Thomas

Revision history for this message

Jeremy Bícha (jbicha) wrote on 2016-07-15:

#22

This bug report is being closed due to your comment that this was not a bug with libburn.

For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in libburn (Ubuntu):
status:	Confirmed → Invalid

Revision history for this message

Thomas Schmitt (scdbackup) wrote on 2016-07-15:

#23

Hi,

thanks for taking action.

I was not aware of being authorized to manage Ubuntu bugs.
Will practice on a few other outdated ones which one can reach from
the Debian package tracker. (Fresh upstream versions are available of
libburn, libisofs, libisoburn.)

Have a nice day :)

Thomas

Revision history for this message

Jeremy Bícha (jbicha) wrote on 2016-07-15:

#24

As the (Debian) maintainer of these packages, you definitely have permission to manage these bugs! But even for bugs in unrelated packages, please don't hesitate to help triage bugs and change their status accordingly.

Since Ubuntu "yakkety" has not yet reached Debian Import Freeze and those packages aren't currently modified in Ubuntu compared to Debian, they will be auto-sync'ed in a few hours.

https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule

Ubuntu
libburn package

libburn imposing 0.2x BD-R burn (5-6 hours)

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntulibburn package

libburn imposing 0.2x BD-R burn (5-6 hours)

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
libburn package