Why can't I burn a BluRay?

Message

grooveman · Post by **grooveman** » Tue Feb 09, 2016 8:54 pm

Hi.

This has been driving me nuts for over a year now... but why the heck can't I burn a BluRay? I have tried this on 3 different drives, on two different systems... It always konks out before the burn is complete. It is usually considerate enough to wait until it is about 80-90% done before it finally dies, but it always seems to.

We Take the drive out, put it into a windows box, and the thing burns them fine. It is related to my (gentoo) system... though I cannot possibly think how. It burns DVD's and CDRs just fine -- it is only bluray, and I've tried 3 different types of media now.

I try using K3b, and I have tried burning from the command line with growisofs like so:

Code: Select all

rowisofs -Z /dev/sr0 -J -R -udf -allow-limited-size -V "LaserScan_2016" laser

This last session went 70% before dying.

I'm using an LG BH16NS40.

We are trying to archive off a ton of data, so it is critical that I be able to do this.

Thank you!

G

1clue · Post by **1clue** » Tue Feb 09, 2016 9:15 pm

Are you trying to burn your personal data, or are you trying to burn something like a movie? Pretty much all purchased Blu-Ray content is DRM (digital rights management), which means you need an encryption key.

I have a blu-ray writer, but right about the time I got it set up my backups became too big to fit on a disc, so I've actually never burned one. I've burned smaller media with typical DVDs and CDRs without problems. Any more though I put backups on a removable hard disk.

At any rate, the only reason I can think of for a consistent failure burning on a blu-ray is if it's DRM content. Or maybe if you have older/slower hardware maybe you're getting buffer under-runs?

grooveman · Post by **grooveman** » Tue Feb 09, 2016 9:22 pm

This is just data. Not trying to rip anything.

I just updated my version of cdrtools... trying again...

Post by **NeddySeagoon** » Tue Feb 09, 2016 9:27 pm

grooveman,

I use Xfburn on BDs but have not gone much past 20G. I only have single layer media too.

You really don't want an ISO fs on dual layer BDs. Even if it burns, the entire directory structure must be contained in the first 4G.

The Doctor · Post by **The Doctor** » Tue Feb 09, 2016 9:32 pm

I haven't had any experience with blueray, but have you tried setting the burn speed as slow as possible? When ever I have problems burning a disk this has always fixed it.

It seems you are not the only one who had this issue and slowing things down fixed the problem on Ubuntu http://ubuntuforums.org/showthread.php?t=2047399

szatox · Post by **szatox** » Tue Feb 09, 2016 9:42 pm

We are trying to archive off a ton of data, so it is critical that I be able to do this.

Ehm.... I know it's not the answer you hoped for, but it must be pointed out:
optical drives you can get in store are poor quality and age very quickly. I had some disks that were only writable when I bought them and failed when I needed another one of those a month or two later. And once written to, they would only last for a few months before generating read errors. A very bad thing, considering "archiving" implies long retention time.
Sure, some people claim they have better disks for this... But once you find out they failed, it's too late already.

Also, not exactly your use case though kinda related, since I work as a backup engineer (storing several versions of the same data). Hard drives appear to be the cheapest way to store huge amount of data those days. Disk pools provide you large space and random access, which in turn enables you to go for high compression ratios at cost of data locality. I'm using a few of those, enterprise class, and surprisingly* they work. Poor compression ratio is around 5(data bases tend to do that). Good one is 20. I see 30 at one of those boxes. Not counting "incremental forever", because those use the size of full backup as the base (bumps ratio to values over 100, but let's name it for what it is: cheating)

* Most of the software I see there is "enterprise class" like in "you need an enterprise to pay for it" rather than "good enough to let your enterprise relay on in". Fortunately, hardware components of the complete solution turned out to be much more resilient

1clue · Post by **1clue** » Tue Feb 09, 2016 10:25 pm

+1 for what szatox said.

What I went to is this: I got a box (more than one now) which had a sata bay in it. It's just a 3.5" drive bay with an eject button. It's not part of a hot-swap setup. I use this because internal SATA drives are simpler and faster than USB drives, with less fuss.

I have several plain-old jumbo SATA drives, I buy the biggest ones that are relatively cheap. They're numbered. This would equate to the number of rolling tapes you would use, were you using tape backup. I use 3. They don't have to be enterprise class because they don't sit in the machine, you write to them like a tape drive and eject them.

Each backup session, I copy data to the drive, into a folder like /mnt/backup/2016-02-09/hostname/path/to/source/file. In some cases like a database, I'll zip it. In the cases like files in /etc I just do a raw directory copy. Adjust to your scenario.

I use a script for each system which automatically puts the info into the appropriate place for that system. In some cases it's networked and in others it's direct to a local drive.

When the drive approaches capacity, you will need to delete the oldest backup. I also have a system for choosing a less frequent backup to get at some older preserved data, they go onto the same drive but I name them so I don't accidentally delete them later.

Points:

Don't archive your entire system into a single compressed/encrypted file. An error in the zip file will likely trash your entire backup. Zip individual files for critical data.
Leaving critical information unzipped gets you extremely fast access to files you may need. /etc/ for example has lots of small files, I leave them as-is so I just mount it and grab it.
Develop a good off-site storage plan. One in your office, one at home, one in your laptop bag for rotations, for example.
This isn't the cheapest way to make backups, but it's as fast as SATA, it does not rely on any backup software that might get obsolete, and it is reliable.

scdbackup · Post by **scdbackup** » Wed Feb 10, 2016 7:39 am

Hi,

there are a few known problems with growisofs and BD, but they
do not hit at 70 percent of the burn run.

What messages do you get from growisofs when it fails ?

I myself am burning single layer BD-RE and BD-R with xorriso.
Except some individual bad media they work fine (if the drive
is young enough for the contemporary BD-R media).
This means that i am pretty much at the same success state as
NeddySeagon with xfburn. xorriso and xfburn both use libburn as
burn backend.

NeddySeagon wrote
> You really don't want an ISO fs on dual layer BDs.

I'd rather say that one really does not want genisoimage to pack up
the ISO and add and UDF directory tree.

I deem xorriso with option -for_backup the better ISO producer.
MD5 for data files, ACL, xattr, and no crashes because of deep
directories or unresolved name collisions.

> Even if it burns, the entire directory structure must be contained
> in the first 4G.

Only if you plan to read the ISO by OS with extremely outdated
ISO 9660 drivers. Like Solaris, FreeBSD, NetBSD. They cannot cope
with files of size 4 GiB or more, either.
On those systems you need a userland extractor (like xorriso) to
retrieve all files.

But you will hardly ever get directory tree data above 4 GiB if you
write everything as single session.

Proposal:

Code: Select all

xorriso -for_backup -outdev /dev/sr0 -blank as_needed -joliet on -volid "LaserScan_2016" -map laser /

will do about what your run of growisofs and genisoimage does,
except the production of an UDF directory tree.

Have a nice day

Thomas
[/code]

grooveman · Post by **grooveman** » Wed Feb 10, 2016 7:08 pm

Hmm... Yes, this thread did digress somewhat.

I am only interested in burning bluray's. I have looked at other methods. They do not fit my needs here. Blurays are portable, they are are sturdy, and non-mechanical.

I'm really wondering here if there is compatibility issue here with my bluray burner and linux. At home, I have an older bluray burner (I think it is a pioneer), and I have no trouble at all. I have fully automated bacukps of all my systems using some bash scripting, cron an growisofs. At the office, I have gone through three LG bluray burners, all of which worked fine under windows, and all of which gave me no end of trouble under Linux.

The weird thing is that I only see 3 manufacturers of Blurays nowdays, LG, ASUS and Pioneer -- and LG seems to have the market share. LG has let me down x3, Asus I do not trust, because they do not stand behind products. Pioneer has been more expensive, though now they seem more reasonable.

I had hoped that there would be a solution for this, or a liveable work-around... but I don't know if there will be. LG does not see it as a problem if it works under Windows... and I do not hear many complaint from other people. Bluray is just not that popular.

Thanks though.

G

scdbackup · Post by **scdbackup** » Wed Feb 10, 2016 8:29 pm

Hi,

grooveman wrote:
> I am only interested in burning bluray's

Then please tell the last few lines of growisofs messages when
it has failed to burn a BD.

> Blurays are portable, they are are sturdy, and non-mechanical.

Yes. Great media. My personal sports until we get holodiscs.
I am doing daily incremental backups on BD-R and BD-RE.

> I'm really wondering here if there is compatibility issue
> here with my bluray burner and linux

Only if it or the bus hardware is individually bad, or the kernel
does not operate the bus hardware properly.

Blu-ray burners get controlled by SCSI commands which are specified
in documents MMC-5 or later, and SPC-3 or later.
These commands and their payload data get handed over to the Linux
kernel by ioctl(SG_IO). The kernel cares for transfering them to the
drive. If the drive indicates success, payload data are transferred
to the kernel. Else, the kernel requests Sense Data from the drive.
Either sucess and payload, or failure and sense data are returned
to the caller of ioctl(SG_IO).
In the latter case, growisofs will report lines like

Code: Select all

:-[ WRITE@LBA=126290h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error

3h means "MEDIUM ERROR", (0Ch , 00h) means "WRITE ERROR".

If no such SK/ASC/ACQ is to see, then the abort is due to kernel,
computer's bus controller, or drive's bus controller.

> I had hoped that there would be a solution for this, or a
> liveable work-around...

Did you already try the proposed xorriso run ?

> I do not hear many complaint from other people.

I do neither. As programmer of burn software i would soon learn if
there were some which do not work. I have a LG GGC-H20L (still great
with BD-RE), a LG BH16NS40, and an Optiarc BD-5300S (company out of
business meanwhile, i fear).

> Bluray is just not that popular.

For many people it just seems to work. cdrecord burns BD, growisofs
burns BD (with maybe a hickup when it's done), libburn burns BD.
I got success reports with libburn and 100 GB BD-Rs.

Have a nice day

Thomas

grooveman · Post by **grooveman** » Wed Feb 10, 2016 10:30 pm

Code: Select all

 99.91% done, estimate finish Wed Feb 10 17:27:57 2016
 99.96% done, estimate finish Wed Feb 10 17:27:56 2016
Total translation table size: 0
Total rockridge attributes bytes: 4041
Total directory bytes: 14336
Path table size(bytes): 210
Max brk space used 15000
10664632 extents written (20829 MB)
builtin_dd: 10664640*2KB out @ average 3.0x4390KBps
/dev/sr0: flushing cache
/dev/sr0: closing track
/dev/sr0: closing session
:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error
/dev/sr0: reloading tray

command issued:

Code: Select all

growisofs -Z /dev/sr0 -J -R -udf -V "Stuff" -iso-level 3 "stuff"

This was a disk of about 12 files, in a file structure 2 layers deep, consisting of 4 folders.

Thanks!

scdbackup · Post by **scdbackup** » Wed Feb 10, 2016 11:01 pm

Hi,

> :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error

That's most probably
https://bugs.debian.org/cgi-bin/bugrepo ... bug=713016
fixed by
https://sources.debian.net/src/dvd%2Brw ... 016.patch/
or earlier by
http://pkgs.fedoraproject.org/cgit/rpms ... 23545363a4

growisofs formats the BD-R but then forgets about that. So it sends
an SCSI command which is appropriate only for unformatted BD-R.

Besides programming, two workarounds are known:

- Format the blank BD-R with program dvd+rw-format, so that growisofs
gets to see an already formatted medium.

Code: Select all

dvd+rw-format /dev/sr0

- Use growisofs option

Code: Select all

-use-the-force-luke=spare:none

to prevent automatic formatting of BD-R.
This will give you full nominal write speed. (I assume that your media
are 6x, if growisofs reports 3x with Defect Management.)

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

Are you sure the media are not properly readable afterwards ?

The inappropriate SCSI command is sent after everything important
is already done. (That's why i refer to it as hickup.)

To my knowledge it is mainly an annoyance to K3B or Brasero which
see a non-zero exit value .

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

xorriso does not have this bug.
Further it will not format BD-R by default, but only if you tell
it to do so by its command -format "as_needed":

Code: Select all

xorriso -for_backup -outdev /dev/sr0 -format as_needed -blank as_needed -joliet on -volid "LaserScan_2016" -map laser /

Have a nice day

Thomas

grooveman · Post by **grooveman** » Thu Feb 11, 2016 12:25 am

Wow! You really know your Bluray!

I will give that a whirl tomorrow. You have given me hope, at least

Tony0945 · Post by **Tony0945** » Thu Feb 11, 2016 12:41 am

grooveman wrote:The weird thing is that I only see 3 manufacturers of Blurays nowdays, LG, ASUS and Pioneer -- and LG seems to have the market share. LG has let me down x3, Asus I do not trust, because they do not stand behind products. Pioneer has been more expensive, though now they seem more reasonable.

I have a Pioneer 209DBK on order. It is replacing a flaky LG conventional burner. I'm sick of LG in general and will not buy that brand again. Even the conventional burners start to die after about 8 months. I have Lite-On and Philips burners that are many years old and still work fine, although the Philips tray sticks a lot.

scdbackup · Post by **scdbackup** » Thu Feb 11, 2016 10:29 am

Hi,

Tony0945 wrote:
> I have Lite-On and Philips burners that are many years old
> and still work fine

Last year i had to put a Lite-On CD-RW of 2003 on the shelf because
my new computer has no PATA sockets. My first Yamaha CD-RW of 1999
died after 1 year, the second after 2.5 years. Then came the immortal
Lite-On.
My first DVD burner, an LG, lasted 3 years until i transplanted it
into a new computer. The successor, a Samsung, began to degrade after
only one year, was nearly unusable for DVD+RW after two years, but stil
was a fine DVD-ROM after 7 years.

My oldest BD burner, an LG GGW-H20, survived a Pioneer which died
within its warranty time after 9 months. I got a noisy Optiarc BD-5300S
in exchange.
The LG lives since nearly 7 years on a strict diet of 2x BD-RE,
because after a year i could not get 2x BD-R any more.
Because the Optiarc bails out on multi-session after about 130 sessions
and the GGW-H20 did up to 330, i bought a LG BH16NS40 a few years ago.
This one did only 128 sessions on BD-R. But after i moved to a new home,
it suddenly bailed out after only 3 or 4 sessions. Elsewise it still
works fine and silent.

So i have the GGW-H20 which burns 2x BD-RE at speed 2.3x (10 MB/s),
the BD-5300S which burns multi-session on BD-R and BD-RE, and the BH16NS40
which i use for everthing except multi-session on BD-R.

The new computer has a LG DVD burner GH24NSC0 for 15 Euro incl. VAT.
Mysteriously it pulls in its tray exactly 200 seconds after it came out,
while Linux blktrace does not show any traffic through the drivers.
At that occasion i learned that meanwhile in germany, the LG support
really is willing to reply to e-mail and to confirm that this is not a
regular feature. (Maybe my EFI is bored while Linux is running ?)

Have a nice day

Thomas

grooveman · Post by **grooveman** » Thu Feb 11, 2016 4:47 pm

Okay, I used option #2, as suggested by scdbackup -- and it worked!

That would explain why my bluray at home works... I use that option in my script (since it is unattended).

The only question that remains is this:

If the fix (patch) mentioned in scd's post was released 3 years ago, why the heck isn't it implemented in the mainstream release for Gentoo (and other distros)?

Thank you SCD!

scdbackup · Post by **scdbackup** » Thu Feb 11, 2016 5:55 pm

Hi,

congrats to your burn success with BD-R.

> If the fix (patch) mentioned in scd's post was released 3 years ago,
> why the heck isn't it implemented in the mainstream release for Gentoo
> (and other distros)?

(... and why the hell does https://wiki.gentoo.org/wiki/CD/DVD/BD_Writing
not mention the existence of cdrskin and xorriso ?)

I could get the attention of Fedora and Debian. Thus Ubuntu and Mint
should have it too, meanwhile.

As for gentoo, all patches seem to be about growisofs-7.0
https://gitweb.gentoo.org/repo/gentoo.g ... -r1.ebuild
https://gitweb.gentoo.org/repo/gentoo.g ... ools/files

The package page
https://packages.gentoo.org/packages/ap ... d+rw-tools
says

"This package needs a new maintainer!
If you are interested in helping with the maintenance of dvd+rw-tools,
please get in touch with our Proxy Maintainers team."

Except Gentoo specifics, i would be willing to help with technical
advise: scdbackup@gmx.net , bug-xorriso@gnu.org

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

If you become maintainer or file a bug about the BD-R problem,
please also consider this bug report with patch:

"Burn failure of growisofs on DVD-R[W] with write type DAO"
https://bugs.debian.org/cgi-bin/bugrepo ... bug=794868

Similar to wodim's -scanbus failure, not the program changed but the
system behavior did. growisofs relied on undue tolerance of older Linux.

The Debian bug refers to a two step bug fix of Fedora in 2012
http://pkgs.fedoraproject.org/cgit/dvd+ ... 791ab048dc
http://pkgs.fedoraproject.org/cgit/dvd+ ... 8537fe1a4a
I.e. also well tested.

Gentoo can still beat Debian with applying it.

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

Another thing worth a bug report is on
https://packages.gentoo.org/packages/ap ... d+rw-tools
the "Full description":

"dvdrtools is a fork of cdrtools, with the primary goal of
supporting writable DVD drives."

"dvdrtools" is not related to "dvd+rw-tools", the source package of
growisofs, dvd+rw-format, dvd+rw-mediainfo et.al.
dvd+rw-tools makes use of mkisofs (or xorrisofs) for ISO production.
It's burn capabilities are implemented independently of cdrtools.
(We all share the specs which we have to follow, of course.)

Have a nice day

Thomas

grooveman · Post by **grooveman** » Fri Feb 12, 2016 3:34 pm

Hmm... still having some data integrity issues when burning Dual layer...

I burned one 33 gig file with a check sum to a UDF formatted 50gig bluray. No errors during the burn, but the checksum fails. Tried this a couple times now.

So I split them, and I burned the two 17gig files on a UDF file system. Made checksums for both. The first file checks out OK, the second, fails. Tried twice now...

This is getting expensive!

I have not used xorriso yet, because the UDF part is too important to me, since the files are large.

I will try the pre-format next..

scdbackup · Post by **scdbackup** » Fri Feb 12, 2016 4:11 pm

Hi,

> This is getting expensive!

That's why i let the users make the dual-layer experiments.

> I have not used xorriso yet, because the UDF part is too
> important to me, since the files are large.

You may well combine xorriso with mkisofs

Code: Select all

mkisofs -J -R -udf -V "Stuff" -iso-level 3 "stuff" \
| xorriso -as cdrecord -v dev=/dev/sr0 fs=128m -waiti -eject -

or you may use cdrecord by Joerg Schilling:

Code: Select all

mkisofs -J -R -udf -V "Stuff" -iso-level 3 "stuff" \
| cdrecord -v dev=/dev/sr0 fs=128m -waiti -eject -

Both burn programs use different implementations of the SCSI task
of burning to BD-R.
(cdrskin would support these options too, but i managed to spoil
version 1.4.2 for this use case, and am not sure whether 1.4.2.pl01
is already in Gentoo. 1.4.0 or older would be ok.)

Nevertheless, there is few reason to use UDF with large files
unless you plan to read the BDs by Solaris, or a BSD Unix.
ISO 9660 may well represent files up to the maximum filesystem
size of 8 TiB. Linux shows them properly.

xorriso in -for_backup mode records MD5 which enable you to test
each data file and the whole filesystem whether they are still ok.
If you plan for long term storage, then consider to burn multiple
copies and to checkread them once per year. Chances are good that
the other copies are still verificable when the first one fails.

> I will try the pre-format next..

If you did not get i/o errors when checkreading, then the reason for
failure is not about bad spots on the medium. And bad spots are the
only reason why formatting and the resulting Defect Management might
be beneficial.

In practice i observe the contrary at least with BD-RE. Many of mine
are well writable and readable if i disable Defect Management during
write. If if i let the old GGC-H20 drive checkread while writing,
it slows down to 0.1x write speed. Afterwards, when checkreading,
the drive clonks miserably by hopping forth and back between normal
data area and Spare Area, where the reserve blocks sit.

For problem diagnosis it would be enlightening if you burn many small
files with xorriso and -for_backup MD5s. Then we could locate the
data files which fail the MD5 check and learn about the storage region
where the reader does not see what the writer wrote.

If you are willing to waste a medium, then we could make a little
program which puts out blocks of 2048 bytes, each with its own
intended block number as repeated content. If we burn this block stream
to BD, we could read it and see which blocks are not where they
should be or do not show the content which they should have.

Tell me if you want to go that way.
(I'd also take media donations and make experiments myself.

)

Have a nice day

Thomas