From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9AD331381F3 for ; Wed, 10 Jul 2013 09:30:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D05BE09DB; Wed, 10 Jul 2013 09:30:52 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by pigeon.gentoo.org (Postfix) with ESMTP id 29076E0983 for ; Wed, 10 Jul 2013 09:30:51 +0000 (UTC) Received: from scdbackup.webframe.org ([212.46.126.165]) by mail.gmx.com (mrgmx102) with ESMTP (Nemesis) id 0LvPgd-1UFIdd1DZz-010cxa for ; Wed, 10 Jul 2013 11:30:50 +0200 Date: Wed, 10 Jul 2013 11:30:31 +0200 From: "Thomas Schmitt" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] k3b burning BD-Disk pretends to fail at 99.99% Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <51dd1cf8.mBFUTA6CuM2lPji9%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <51dd1cf8.mBFUTA6CuM2lPji9%Joerg.Schilling@fokus.fraunhofer.de> Message-Id: <838628621963559120@scdbackup.webframe.org> X-Provags-ID: V03:K0:LRNoiw4r9O7uohfWkWnd2bWifFZQzAPMGv/m6xS0Yzy5FUpVWg/ sTis4lG4tQda6hl8Kimsksw2ZTPyY1wBSFCrhOxXt8KUE0AJ4MX61zv210b4rj6uEWtQAvt 82CcYuER7ZgttgDiX0QRnnnbC3TJ3pRhQ48qS7iqujZXkVve5lZZ02UMH088GWekw/8vYCl 52GhPqkuzIbrClXrkhPZQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: a5cbf5fa-8b28-422d-9b3e-cea6c8454e55 X-Archives-Hash: d8818a2903ca251fd1cdf95cd6fe67c9 Hi, i wrote: > > One big problem is the substantial price of BD-R experiments. Joerg.Schilling@fokus.fraunhofer.de wrote: > the OP seems to have turned several BD-Rs into coasters already. The OP reports: > > > I compared each and every file on the disk with its original, > > > but yould not find any problem. This matches Andy Polyakov's diagnosis that the media are ok afterwards. The flawless readbility, the timepoint of failure, and the i/o error reported by K3b, alltogether make me believe that it is the 5 year old bug. Of course, everybody has to decide by himself where to invest test media. My proposal is to fix and test growisofs. --------------------------------------------------------------------- (Joerg and i know each other from many encounters in the past. We do not necessarily agree on technical questions. My apologies for getting off the original topic now.) Joerg.Schilling@fokus.fraunhofer.de wrote: > Many people reported problems even with writing DVDs using growisofs that > went away after upgrading to cdrtools. "With some fantasy you can see the weirdest things in the mist." (Franquin via Gaston Lagaffe) It is not impossible that a drive refuses on one way of burn preparation while still working with a different one. One might get lucky with the defaults of one burn program and experience failure with those of the other burn program. But normally a drive is on the edge of failure if it behaves that way. The luck may turn quite quickly then. Joerg.Schilling@fokus.fraunhofer.de wrote: > Note that I already mentioned that growisofs is a layzy written program I would compare its style rather to BASIC than to assembler. :)) But that does not influence its SCSI standards compliance. Joerg.Schilling@fokus.fraunhofer.de wrote: > has many places where is returns the unly slightly modified result of a SCSI > mode sense operation while running a SCSI mode select operation. As it only > slightly modifies the received data instead of constructing SCSI standard > compliant data, these mode select operations do not always have the desired > effect. How else should one learn the current settings in order _not_ to change those which are non-changeable ? In the source files of growisofs i can spot only one occasion of MODE SELECT. This is in transport.hxx where Andy composes a mode page 05 for DVD-R[W]. I read in SPC-3 6.9.3 that the drive shall throw error if one attempts to change a non-changeable value. But not that the drive is allowed to return values which may cause error if sent back to the drive. So if the code of transport.hxx is wrong, then not because it would send back values which it got from the drive, but because it does not inquire by PC=01b whether its self-constructed values are allowed to be changed. (I don't do this either. It is worth consideration, though.) Joerg.Schilling@fokus.fraunhofer.de wrote: > This kind of problems is independent from the media type Mode page 05 is only appropriate for CD and DVD-R[W]. (MMC-5 7.5.2, 7.5.3) So this problem is highly dependent on the media type. Have a nice day :) Thomas