José Romildo Malaquias <[email protected]> wrote:
> On Fri, Nov 20, 2009 at 04:48:25PM +0100, Joerg Schilling wrote:
> > José Romildo Malaquias <[email protected]> wrote:
> >
> > > > There was a report for broken Pioneer formware that hits in -v mode and
> > > > causes the firmware from the drive to through away the data before
> > > > writing
> > > > it to the medium.
> > >
> > > Do you mean a test without -V or -v ?
> >
> > Without -v, as in this case cdrecord does not read the drives buffer fill
> > ratio.
> > It seems that there is a bug in Pioneer firmware that is triggered by
> > calling
> > SCSI get buffer cap (0x5C)and that results in throwing away the DMA data.
>
> Good news!
>
> With the command (without using the -v option)
>
> $ script -f -c "cdrecord -V debug=2 -sao -eject speed=8 fs=256m
> driveropts=burnfree /var/tmp/image.iso" cdrecord.log
>
> cdrecord completed successfully. The sha1 sums (calculated in a
> different computer) for both the image and the recorded media are
> identical!
OK, could you please use an original cdrecord without your recent self made
patch and then apply this patch:
------- cdrecord.c -------
--- /tmp/sccs.RvayQW So Nov 29 18:48:57 2009
+++ cdrecord.c So Nov 29 18:47:24 2009
@@ -2590,7 +2590,7 @@
if (fper >= 0)
printf(" (fifo %3d%%)", fper);
#ifdef BCAP
- if (bsize > 0) { /* buffer size
known */
+ if (bsize > 0 && bytes > bsize) {
/* buffer size known */
scgp->silent++;
per = (*dp->cdr_buffer_cap)(scgp, (long *)0,
&bfree);
scgp->silent--;
This should avoid some calls to the buffer cap function before the drive's
internal buffer was filled the first time.
Then please test again with -v
Jörg
--
EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
