--- Comment #26 from Thomas Schmitt <> ---

> The error ImgBurn gives me is something like "invalid address for write".
> Other users receiving that error were told it's because of the medium
> quality,

It's probably a miscoordination between burn program and drive.
There is SCSI error code

Each SCSI WRITE command contains the block address where the write
operation shall start and the number of blocks which shall be written
with the payload bytes of the SCSI command.
If the drive replies "invalid address", then either one of the affected
blocks was out of the range of writable blocks on a BD-RE or a BD-R which
was formatted to "Pseudo Overwrite" (POW), or the start block address
was not the Next Writable address of a BD-R which was not formatted to POW.

> 50GB Panasonics

So probably double-layer BD-R. Unlike with DVD+R DL, we burn programmers
have no influence on the hopping between the layers. That's rather good,
as with DVD+R DL we had some problem reports with any of the possible
modes of operation.

My best guess would be that the passing-through of SCSI commands to the
burner is prone to disturbances or hick-ups.


No protests from the drive to see. It took nearly 50 GiB.

The only suspicious message is
> cdrfifo 0: on read: errno=22 , "Invalid argument"
This was when reading the input file into the ring buffer.
And it happened before writing began. But it did not prevent writing
... which i cannot reproduce yet.
All my tries with simulated errors abort early.

My apologies for the medium waste, anyway.

errno 22 is not a usual read error. man 2 read mentions O_DIRECT.
Maybe the distro configured libburn with non-default
and your disk has physical blocks larger than 2048.
But Debian and therefore probably Mint has in the buildd log of libburn:
  disabled use of O_DIRECT with track input

If it's O_DIRECT, then a run with growisofs might encounter the same
problem. If i understand its source right, then it uses O_DIRECT
by default if Linux is younger than 2.5.


What was the exact cdrskin command you used and what do you get from
  ls -ld $path
with $path leading to the image file ?


What happens if you do (without risking a BD-R medium)

  cdrskin --allow_emulated_drives -sao -v dev=stdio:/dev/null fs=32m -eject

Does it report again
  cdrfifo 0: on read: errno=22 , "Invalid argument"

If so, then we need to build cdrskin from source with surely O_DIRECT


What does a hex editor say about your burned BD-R ?
Does it show any non-zero bytes after maybe some first MBs of zeros ?


Have a nice day :)


You are receiving this mail because:
You are watching all bug changes.

Reply via email to