# growisofs -Z /dev/scd0 -dvd-video output
Executing 'mkisofs -dvd-video output | builtin_dd of=/dev/raw/raw1 obs=32k seek=0'
:-( unable to PREVENT MEDIA REMOVAL: Bad file descriptor
This was using a new DVD+RW media on a HP 300n IDE drive unit.
The device is set to use the /dev/raw/raw1
Inserted media into another drive and it appears to be burning
normally. Except that it reported the speed at 2.5x instead of 2.4x.
This unit was not bound to a raw device. It completed the burn in
22 minutes as I would expect for 4.2 GBytes.
This is interesting. dvd+rw-tools 5.17
If you have burnfree ON the drive just
dramatically slows down.
*If* it turns to be true, then it would be the first DVD recorder I've
seen to do such thing. I mean I so far haven't seen a single DVD
recorder which would decrease DVD recording velocity because buffer
underrun protection was
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check the
On Friday 30 January 2004 02:59, Andy Polyakov wrote:
Meaning that you can't reproduce the problem... Well, varying
results might be indication of poor media support in firmware. I
would still recommend to try -speed=1 option and maybe even stick
to it for *this* media brand/batch, just to
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check
From: Andy Polyakov [EMAIL PROTECTED]
If you have burnfree ON the drive just
dramatically slows down.
*If* it turns to be true, then it would be the first DVD recorder I've
seen to do such thing. I mean I so far haven't seen a single DVD
recorder which would decrease DVD recording velocity
On Fri, Jan 30, 2004 at 02:15:00PM +0100, Andy Polyakov wrote:
Sorry, you repeat useless statements :-(
Does anybody else feel that way?
Surely you've picked up by now that if you're not Joerg you must be
wrong. By definition, I guess... :-(
--
Steve McIntyre, Cambridge, UK.
On Thu, Jan 29, 2004 at 11:28:03AM -0500, Thomas J. Magliery, Ph.D. wrote:
Well, I've played with this for way more than an hour already. Why not?
The folks at linux-usb-devel (i.e., Alan Stern) also want me to recompile my
linux kernel with usb-storage debugging on. So this could take a
On 28. January 2004 at 10:02AM -0600,
Ramasubramanian Ramesh [EMAIL PROTECTED] wrote:
I asked this in debian-user and got no answer so I thought
this is a better place. How do I get udf writing working in
kernel 2.6? I have udftools installed. However when I try a
pktsetup, it complains
[EMAIL PROTECTED]
I don't know if the list is still active or if it accepts posts
from non-members.
Still running, low volume (as usual). Some development is happening.
Posting by subscribers only.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
On Thu, Jan 29, 2004 at 11:05:41PM +0100, Joerg Schilling wrote:
I just did run a test that verifies that the 708 in fact
returns 36 bytes. So the problem is definitely caused by a
Linux driver bug.
I tend to believe that growisofs just does not check the SCSI
status byte and for this
... tried using -speed=4 and it still took 28 minutes. Here the
reported speed was 4.1x though. This recording time would seem to
me to be closer to 2x speed. The write LED is illuminated
constantly so I do not think there are any buffer under-runs that
would account for the slower
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check the
14 matches
Mail list logo
