From owner-freebsd-current Thu Jan 6 10: 0:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 3CA1414D77 for ; Thu, 6 Jan 2000 10:00:20 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id TAA20492; Thu, 6 Jan 2000 19:00:16 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200001061800.TAA20492@freebsd.dk> Subject: Re: wormcontrol replacement coming! In-Reply-To: <200001061729.SAA01007@info.iet.unipi.it> from Luigi Rizzo at "Jan 6, 2000 06:29:04 pm" To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Thu, 6 Jan 2000 19:00:16 +0100 (CET) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Luigi Rizzo wrote: > > > > I've just done a replacement for wormcontrol that allows burning CDR/CDRW > > > > with just one command. Its simpleminded but it works. > > btw for the records -- on 2.2.x i noticed i needed some wait between > the transfer of data to CDR, and the "fixate" command (in other words, > the fixation would often immediately fail if done within the same wormcontrol > instance in charge of the data transfer.) > > I got lazy and instead of investigating the problem i realised that issuing > the "wormcontrol fixate data" manually after the previous one was done did > fix things, so i have no idea if it was related with my port of the worm > support to 2.2.x, with the possible absence of closing and reopening the device, or with just the delay between the commands. Any idea ? I've not seen the fixate fail, but I've seen the second write to a multitrack disk fail if the device is not closed inbetween. The problem was that the b_offset that is used to calculate the LBA to write to, is not reset between the writes, so the address doesn't corresspond with the address found with the next_writeable function. This is fixed now... I've also investigated using the READCD cmd instead of READ_BIG to read the CD, this allows one to read _any_ data in _any_ format off the CD, thereby eliminating the need for rippers, you just dd the audio CD into a file, handy :). It seems to work pretty well, so I might commit that too... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message