Hi, > I confirm it can now write to the USB LG E10L.
:)) > Also, it correctly writes DVD-RWs on the USB LG 2166D where cdrecord > fails (cdrecord is ok for DVD+RW on that). I guess that is the command > # /tmp/cdrecord dev=$cddev -v -data blank=fast you reported Thu, 17 May 2007. > /tmp/cdrecord: Input/output error. read disk info: scsi sendcmd: no error > CDB: 51 00 00 00 00 00 00 00 2C 00 This READ DISC INFO command limits the reply to up to 44 bytes. I assume that sg_io_hdr_t.dxfer_len for the SG_IO driver is set to the same value. The command requests Data Type 000b, which has a reply length of >= 34 bytes, depending on the number of OPC table entries. (See MMC-5, 6.22.3.1 Data Type 000b: Standard Disc Information) So probably libburn's new approach to request only 34 bytes does the trick here. (If libburn would be interested in the OPC entries then it would have to interpret Disc Information Length from the first reply and then call again. But all it wants to know for now is within the standardly promised first 34 bytes of reply.) One has to note that this remedy will fail if some drive decides to deliver less than 34 bytes. The obvious demand of kernel 2.4 USB drivers to see sg_io_hdr_t.dxfer_len reply bytes is cumbersome. I still have to explore wether the dramatic difference between cdrecord and libburn-0.3.6 comes from the oversized i/o buffer in libburn-0.3.6. I first repaired the stalling by the new reply size restrictions for MMC commands. Only later i reduced buffer size to enable record sizes != 2048. Maybe libburn-0.3.6 would receive only harmless protests from the drivers if it used 32 kiB buffer. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
