blu-ray burning failure
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 \ Code:
:-( unable to WRITE@LBA=4567a0h: Input/output error A few days later, I tried to add a session. Code:
growisofs -speed=4 -M /dev/sr1 \ 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 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. |
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. |
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 |
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? |
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 |
Quote:
|
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 |
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 Code:
$ ./test_burn_2.sh 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." :D |
Quote:
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 :D PS Thanks for taking the time to help us Slackers. Cheers, |
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 |
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 |
Quote:
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 p.s. Hey, I just realized: you also had helped me out, back when I was burning blu-rays in Debian. Thank you. :) |
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 |
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 \ Code:
23762796544/24021254144 (98.9%) @1.7x, remaining 0:39 RBU 100.0% UBU 45.3% |
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 |
All times are GMT -5. The time now is 09:06 PM. |