blu-ray burning failure

pzognar · 12-06-2015, 09:13 PM

Running Slackare 64 -current.

Recently, I attempted to burn a multi-session blu-ray disk. I had worked out the command to do this many months ago, when I was still running Debian.

Code:

growisofs -speed=4 -Z /dev/sr1 \
 -r -v -hide-rr-moved \
 -V "DISK_LABEL" \
 --graft-points \
 some_dir=some_dir \
 some_other_dir=some_other_dir

On the first session, it failed right away with the following error:

Code:

:-( unable to WRITE@LBA=4567a0h: Input/output error
:-( write failed: Input/output error
/dev/sr1: flushing cache
:-( unable to FLUSH CACHE: Input/output error
:-( unable to SYNCHRONOUS FLUSH CACHE: Input/output error
$

Ran it again. Hey, why not? Either the disk is already ruined and it won't matter, or it is not and thus can still be burned to. This time, it appeared to run fine, taking a plausible amount of time to finish. I verified by mounting the disk. I further verified by running a "diff --brief --recursive" against the original directory. That went fine.

A few days later, I tried to add a session.

Code:

growisofs -speed=4 -M /dev/sr1 \
 -r -v -hide-rr-moved \
 -V "DISK_LABEL" \
 --graft-points \
 some_new_dir=some_new_dir \
 some_other_new_dir=some_other_new_dir

The only difference here, aside from the directory names, is using "-M" instead of "-Z" to indicate that we wish to *add to* an existing disk.

The result was the same error as above. Oh.

Said, "OK, I was able to work past that last time: let's try it again this time."

It refused. As if the drive was busy. Tried to eject. It would not. Tried as root. Still could not. Rebooted: overkill works, right?

Tried a burn again. This time, it ran for a while, as if actually burning. It failed after five to ten minutes:

Code:

 76.09% done, estimate finish Sun Dec  6 18:44:08 2015
 76.16% done, estimate finish Sun Dec  6 18:44:09 2015
 76.23% done, estimate finish Sun Dec  6 18:44:12 2015
 76.31% done, estimate finish Sun Dec  6 18:44:13 2015
 76.38% done, estimate finish Sun Dec  6 18:44:15 2015
 76.45% done, estimate finish Sun Dec  6 18:44:16 2015
 76.53% done, estimate finish Sun Dec  6 18:44:19 2015
 76.60% done, estimate finish Sun Dec  6 18:44:20 2015
:-( unable to WRITE@LBA=4f65e0h: No such device
:-( write failed: No such device
/dev/sr1: flushing cache
:-( unable to FLUSH CACHE: No such device
:-( unable to SYNCHRONOUS FLUSH CACHE: No such device
$

Missing device? Suggestive of ... bad cable? Note: this is an external burner.

Tossed the disk. Put in an existing disk of known quality. It mounted fine. OK. To test the connection, or, rather, the ability to sustain a connection, I copied it entire contents to a temp directory on the hard drive. That worked.

So it looks like I have one to two problems.

One: failure at start of a burn. Happens every time.

Two: a one-time loss of connection to the burner (might be random, one time?) during a burn.

Could anyone who has actually burned a blue-ray disk in Slackware tell me how they did it? My usual approach of trial-and-error is not workable because of the expense of blank blue-ray media.

Thank you in advance.

FTIO · 12-07-2015, 01:59 AM

I use K3B on my LG WH16NS40 and it burns blu-rays just fine (except for a little hiccup where at about 30 done the physical memory starts to fall until it's at zero and then bounces back and forth for a while until something decides it's okay to have it back and at around 75% done it will climb back up again and by the end of burning a 25GB BD, it'll have gotten to the point of burning at ~45MB/sec...which I'm happy enough with).

I've never tried a multi-session though, and me living on a disability check makes it even harder to test and end up throwing expensive disks away. Maybe though I'll try one just for t-shirts and giggles and cross my fingers. I'll let you know how it works out probably tomorrow (meh...today now) if I remember to try it out.

scdbackup · 12-07-2015, 02:22 AM

Hi,

the error messages of growisofs do not look like a medium problem
or a failure of the optical drive. In both cases there should
be SCSI error codes shown, like

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

I/o error without SCSI codes and especially "No such device"
rather indicate a problem with computer, cable, or the drive's
communications controller (SATA + USB bridge ?).

> My usual approach of trial-and-error is not workable because of
> the expense of blank blue-ray media.

That's my excuse now, too.
I make daily incremental backups on a BD-R via xorriso and am
confident enough of growisofs to believe that it would do a
similarly successful job here. (growisofs has small bugs around
Blu-ray but they would not cause this failure.)

So if a failure happens before about the 120th session, then
if is probably due to local hardware problems.
(My olde LG GGW-H20 could do 330 sessions, but i cannot get BD-R
any more which it would accept. It still burns with record
breaking 2.3x speed to 2x BD-RE media.
Newer LG and Optiarc bail out somewhere after session 120 on
BR-R. In general BD-RE is better suited for many sessions.)

Have a nice day

Thomas

pzognar · 12-07-2015, 11:51 AM

Thank you, everyone, for the replies.

I've unplugged and replugged the cable. Over time I will just have see if connection errors manifest again.

I wish I could figure out the error when starting a burn.

In the past, I had burned blu-ray from Debian. Debian is notorious for modifying packages... which makes me wonder if there is some bug or aspect of blu-ray burning that they fixed or worked around?

Or could this be a symptom of the recent switch to uedev?

scdbackup · 12-07-2015, 12:41 PM

Hi,

> Or could this be a symptom of the recent switch to uedev?

systemd is the one that nowadays attracts all suspicion for
every problem.

)

With CD or DVD-R[W] Disk-At-Once i would consider a sidewards
access from udev. Some "harmless" inquiry command to check the
drive state.
But firstly it would cause an SCSI error and secondly BD-R are
like DVD+R quite immune against groping.

> Debian is notorious for modifying packages...

Yes. I meanwhile patch my own upstream releases when preparing
the Debian packages of libisofs, libburn, and libisoburn.
(lintian complains, kfreebsd fails ... usual last minute
problems.)

But there is no known fixed growisofs bug which would cause
what you experience.

This unresolved one looks somewhat similar

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=755466
:-( unable to WRITE@LBA=12a3f0h: Input/output error
:-( write failed: Input/output error
/dev/sr0: flushing cache
:-( unable to FLUSH CACHE: Cannot allocate memory

Looks like an extreme system situation.

The confessions of the Debian maintainers are here
http://metadata.ftp-master.debian.or...able_changelog
(Nothing matching to see.)

The new package tracker leads me to the patch collection
https://sources.debian.net/src/dvd%2...ebian/patches/

Number 01 to 08 don't touch SCSI command transport.
Number 10 was proposed by myself.

)
09-wctomb.patch sits in transport.hxx, indeed. But its use is
with error messages about unrecognized media before burning
or formatting begins. The third call of plusminus_locale() is
with the start message of dvd+rw-format. I.e. not in a run of
growisofs.

I am a bit puzzled by the last one:
ignore_pseudo_overwrite.patch
because it seems to (partly) revert a development decision once
made by Andy Polyakov, the author of dvd+rw-tools.
I really would not dare to make this change without thorough
examination what Andy intended to do with Pseudo Overwrite.
On the other hand, the bug report looks like Andy made a mistake.
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=615978

I write BD-R wthout Pseudo Overwrite and believe to do it right.
Andy once mumbled about a workaround for Solaris mount.

Have nice day

Thomas

the_penguinator · 12-08-2015, 05:45 PM

Quote:

Originally Posted by scdbackup

systemd is the one that nowadays attracts all suspicion for
every problem.

)

you were never spanked as a child...were you...;-)

scdbackup · 12-09-2015, 04:17 AM

Hi,

> > [the-name-which-shall-not-be-spoken-or-else-flamewars-break-out]

> you were never spanked as a child...were you...;-)

I was told not to say four-letter-words.
It was pzognar who said "udev". My word has 8 letters. (

)

If one is willing to let udev act during the runtime, then
its (meanwhile) boss is not much of an extra plight.

As upstream programmer of burn software my natural foes are
automount, hald, udev, udisks, et.al.
They cannot help but only do harm to my cause. It is a joy
to run burn software on NetBSD or FreeBSD ... until i dare
to unplug the USB cable of the drive. So i stay with Linux.

Have a nice day

Thomas

pzognar · 12-09-2015, 08:30 PM

Hello again.

@scdbackup. I have to confess... your second-to-last post is detailed and knowledgeable but I am kind of unclear on it. I am sorry.

Update...

I think I have two errors: the fail-right-away problem and the fail-partway-through problem. Recall that the error messages (won't post them again) suggest that the fail-partway-through problem may be a hardware problem.

To narrow the problems down, I used a DVD (not bluray/BD) drive to do a small amount of testing on a rewriteble DVD.

The fail-right-away problem does not happen on the DVD. Interesting.

The fail-partway-through happened *once* on a DVD. Darn. The error message was not identical, however. Recall that when the BD burn fails partway through, this is the error message:

Code:

 76.60 done, estimate finish Sun Dec  6 18:44:20 2015
:-( unable to WRITE@LBA=4f65e0h: No such device
:-( write failed: No such device
/dev/sr1: flushing cache
:-( unable to FLUSH CACHE: No such device
:-( unable to SYNCHRONOUS FLUSH CACHE: No such device

The one time the DVD burn failed, the entire output looked like this:

Code:

$ ./test_burn_2.sh
Executing 'mkisofs -C 16,47120 -M /dev/fd/3 -r -v -hide-rr-moved -V SESSION2 --graft-points mix=mix | builtin_dd of=/dev/sr1 obs=32k seek=2945'
Setting input-charset to 'ISO-8859-1' from locale.
3.01 (x86_64-unknown-linux-gnu)
ISO-9660 image includes checksum signature for correct inode numbers.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Scanning mix
Scanning mix/4m_loops_tone
Scanning mix/loops_drum
Scanning mix/one_shot
Scanning mix/bpm_82
Scanning mix/bpm_82/in
Scanning mix/bpm_84
Scanning mix/bpm_84/in
Using RLO_1000.WAV;1 for  mix/4m_loops_tone/rlo_1_old2.wav (rlo_1_old.wav)
Using 4M_LO000.WAV;1 for  mix/4m_loops_tone/4m_loop_4.wav (4m_loop_3.wav)
Using 4M_LO001.WAV;1 for  mix/4m_loops_tone/4m_loop_3.wav (4m_loop_1.wav)
Using PEICE000.WAV;1 for  mix/one_shot/peice_aon_SD.wav (peice_aon_BD.wav)
Writing:   Initial Padblock                        Start Block 47120
Done with: Initial Padblock                        Block(s)    16
Writing:   Primary Volume Descriptor               Start Block 47136
Done with: Primary Volume Descriptor               Block(s)    1
Writing:   End Volume Descriptor                   Start Block 47137
Done with: End Volume Descriptor                   Block(s)    1
Writing:   Version block                           Start Block 47138
Done with: Version block                           Block(s)    1
Writing:   Path table                              Start Block 47139
Done with: Path table                              Block(s)    4
Writing:   Directory tree                          Start Block 47143
Done with: Directory tree                          Block(s)    23
Writing:   Directory tree cleanup                  Start Block 47166
Done with: Directory tree cleanup                  Block(s)    0
Writing:   Extension record                        Start Block 47166
Done with: Extension record                        Block(s)    1
Writing:   The File(s)                             Start Block 47167
 38.21 done, estimate finish Tue Dec  8 10:01:54 2015
 42.02% done, estimate finish Tue Dec  8 10:01:53 2015
 45.86% done, estimate finish Tue Dec  8 10:01:53 2015
/dev/sr1: "Current Write Speed" is 4.1x1352KBps.
:-( unable to WRITE@LBA=b920h: Input/output error
:-( write failed: Input/output error
/dev/sr1: flushing cache
:-[ FLUSH CACHE failed with SK=6h/POWER ON, RESET, OR BUS DEVICE RESET OCCURRED]: Input/output error
/dev/sr1: stopping de-icing
/dev/sr1: writing lead-out
/dev/sr1: reloading tray
$

The end of the run has a an "Input/output" error instead of the "No such device". I find this interesting.

Also of interest: when burning multi-session, this fail-partway-through type of error has not yet happened on the first session. I wonder if it cannot happen on the first session? I wonder if there is something different about however added sessions work that could be a factor?

All of this, while it does not (yet) fix the problem, makes me wonder if perhaps it is *not* a connection problem? Connection in this case means cable, usb port on computer, usb port on burner/drive.

Not yet tried (I have time/situational constraints): burning a DVD on the BD drive.

p.s.

@the_penguinator: "...spanked..."
@scdbackup "...quite immune against groping."

Didier Spaier · 12-09-2015, 11:09 PM

Quote:

Originally Posted by scdbackup

As upstream programmer of burn software

Hi Thomas,

This sentence make me think that really Slackware should ship xorriso genuinely.

At least we can get it from Robby Worman as a third party (libisoburn) package.

I just need to finish reading the man page

PS Thanks for taking the time to help us Slackers.

Cheers,

scdbackup · 12-10-2015, 02:13 AM

Hi,

> your second-to-last post is detailed and knowledgeable but I
> am kind of unclear on it.

The many words mainly say that Debian did not apply any patch
that would explain why their growisofs should get less errors
with SCSI command transport.

> The fail-right-away problem does not happen on the DVD. Interesting.

Do your BD runs fail reliably ? (Or only sometimes ?)

> The one time the DVD burn failed, the entire output looked like this:
> :-[ FLUSH CACHE failed with SK=6h/POWER ON, RESET, OR BUS DEVICE RESET OCCURRED]: Input/output error

Ths is an SCSI error code. The drive indicates that it
tempoarily lost connection to the computer.

So again, a severe problem with exchanging SCSI commands and
replies between computer and burner.

What do you see in system logs (or output od program "dmesg")
immediately after this happened ?
Any messages about bus reset or attaching a "newly found" device ?
(After the previous device was dropped due to some problem.)

> The end of the run has a an "Input/output" error instead of the
> "No such device".

Both describe nearly the same situation.
I guess "No device" is noticed by the operating system
while the burner is unreachable.

The SCSI error comes from the drive. It probably gets emitted
when the next SCSI command arrives after the drive noticed
the loss of connection and its re-establishement.

> makes me wonder if perhaps it is *not* a connection problem?

It quite surely is a connection problem.

The error message from the operating system says it sparsely.
The drive says it unambiguously.

I expect that the system logs show a disconnect of the drive
(for some reason) and soon later the recognition of the
drive as new device.

> @the_penguinator: "...spanked..."

I deserve it for not knowing that there is now "eudev" which
tries to sabotage my cause without the supervision by
dont-say-its-name. (

)

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

Didier Spaier wrote:
> This sentence make me think that really Slackware should ship
> xorriso genuinely.
> At least we can get it from Robby Worman as a third party (libisoburn)
> package.

xorriso is part of the libisoburn source tarball.
So libisoburn is the right source if you already have libburn
and libisofs installed as dynamic libraries for e.g. Xfburn.

libisoburn's "make" yields libisoburn.so and a dynamically linked
xorriso binary. The binary has just a few dozen kB because everything
is in the libraries.

As a distro you should better not package my GNU xorriso tarball.
It gets built from identical source code, but brings all three libs
in one package and links them statically rather than installing
them as .so.
This xorriso binary has stripped about 1.5 MB of size on amd64.
It is mainly intended for those users who compile from upstream
sources. Runnable without system-wide installation. I.e. you
can build and use it without being superuser and without disturbing
the system libraries.

> PS Thanks for taking the time to help us Slackers.

You are welcome.

Have a nice day

Thomas

scdbackup · 12-10-2015, 02:24 AM

Hi,

after a cup of tea i remember a new fashionable connection
problem:

USB 3.0 has a timeout feature which is said to be wrongly set
by several Linux kernels.
Google "usb3 timeout".
This could explain why you get connection losses.

Is your drive in a USB box and connected to a USB 3 socket ?
If so: does your computer still have some USB 2 sockets ?
Try to plug in there. (The speed of USB 2 suffices for all
burn purposes.)

Have a nice day

Thomas

pzognar · 12-10-2015, 07:36 AM

Quote:

Originally Posted by scdbackup

Hi,

after a cup of tea i remember a new fashionable connection
problem:

USB 3.0 has a timeout feature which is said to be wrongly set
by several Linux kernels.
Google "usb3 timeout".
This could explain why you get connection losses.

Is your drive in a USB box and connected to a USB 3 socket ?
If so: does your computer still have some USB 2 sockets ?
Try to plug in there. (The speed of USB 2 suffices for all
burn purposes.)

Have a nice day

Thomas

Thank you.

Yes... that makes sense, at least for the fail-partway-through problem. I've been burnign blu-rays on USB3 and as far as i can tell,t eh drive is also USB3. I would blame usb3 power management or the kernel before blaming hardware because ... I burned several multi-session blu-rays with this computer and this burner without problems when I was in Debian. Different kernel and all.

I did not realize that USB 2 is fast enough for blu-ray burning. I will test this and maybe using USB 2 could be a workaround.

I still wish I could figure out the other problem, the fail-right-away problem. I think next I will see about burning the rewriteable DVD in the BD drive instead of the DVD drive.

Gotta to do more testing.

p.s. Hey, I just realized: you also had helped me out, back when I was burning blu-rays in Debian. Thank you.

scdbackup · 12-10-2015, 09:18 AM

Hi,

> I did not realize that USB 2 is fast enough for blu-ray burning.

480 Mbit/s raw.
My eight year old machine had only USB 2 and worked well
at least with 18x DVD and 6x BD (27 MB/s).
At least 35 MB/s was possible with USB hard disks.

> p.s. Hey, I just realized: you also had helped me out, back when
> I was burning blu-rays in Debian. Thank you.

I do not remember particularly, i have to confess.

Users and supporters are invited to write to me in private
(scdbackup at gmx dot net) or in public (bug-xorriso at gnu dot org).
Besides burner and ISO 9660 i can help diagnosing problems in the
isofs driver of the kernel. But i have no clue of the SCSI drivers
which transport data between ioctl(SG_IO) and burner.

Have a nice day

Thomas

pzognar · 12-12-2015, 06:56 PM

Tried something different. Decided to try a single-session, not multi-session BD. Also decided to be different by burning from a (huge) image. Based on previous posts in this thread, I also decided to burn from the USB2 port instead of the (usual) USB3 port.

Ran it, using this command:

Code:

growisofs -speed=4 -Z \
 /dev/sr1=a_bd_image.iso

End part of the output:

Code:

23762796544/24021254144 (98.9%) @1.7x, remaining 0:39 RBU 100.0% UBU  45.3%
23788322816/24021254144 (99.0%) @1.7x, remaining 0:35 RBU 100.0% UBU  48.4%
23812702208/24021254144 (99.1%) @1.6x, remaining 0:32 RBU 100.0% UBU  79.7%
23837081600/24021254144 (99.2%) @1.6x, remaining 0:28 RBU 100.0% UBU  45.3%
23861854208/24021254144 (99.3%) @1.7x, remaining 0:24 RBU 100.0% UBU  64.1%
23886659584/24021254144 (99.4%) @1.7x, remaining 0:20 RBU 100.0% UBU  64.1%
23911628800/24021254144 (99.5%) @1.7x, remaining 0:16 RBU  99.7% UBU  45.3%
23936630784/24021254144 (99.6%) @1.7x, remaining 0:12 RBU 100.0% UBU  76.6%
23961010176/24021254144 (99.7%) @1.6x, remaining 0:09 RBU 100.0% UBU  45.3%
23985389568/24021254144 (99.9%) @1.6x, remaining 0:05 RBU 100.0% UBU  54.7%
24010194944/24021254144 (100.0%) @1.7x, remaining 0:01 RBU  33.0% UBU  76.6%
builtin_dd: 11729136*2KB out @ average 1.4x4390KBps
/dev/sr1: flushing cache
/dev/sr1: closing track
/dev/sr1: closing session
:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error
/dev/sr1: reloading tray
$

Despite that one error at the end, the BD was mountable, in Linux *and* in Windows. Did a "diff --brief --recursive" and that found no file errors. Interesting.

scdbackup · 12-13-2015, 01:55 AM

Hi,

> I also decided to burn from the USB2 port instead of the (usual) USB3 port.

Now this looks like success up to a known growisofs bug
with previously unformatted BD-R media.

See
https://bugs.launchpad.net/ubuntu/+s...s/+bug/1113679

One can fix it by the patch proposed in
https://bugs.launchpad.net/ubuntu/+s...679/comments/4

Ubuntu and Debian applied the fix in 2013.

Cheap workaround:
Format the BD-R by dvd+rw-format before using it with growisofs.

People complain about another bug with oversized input images,
which growisofs accepts because they would fit on unformatted
BD-R but do not fit after growisofs automatically formatted
the BD-R. growisofs burns the whole BD-R before it fails with
overflow of media.

(growisofs urgently needs a maintainer with whom i could
discuss such stuff. The first task of such a person would be
to collect and evaluate the various patches from the distros.)

I am quite sure that neither single session nor the fact that
the BD content was provided as an image is decisive for your
nearly success with growisofs.

I blame it all on USB2 versus USB3. The error occasions would
simply be long running SCSI commands. Like FLUSH CACHE with DVD
or a WRITE command that hits a poor spot on formatted BD and
causes lengthy circumvention measures (re-write or relocation to
Spare Area).

Have a nice day

Thomas