[Pkg-libburnia-devel] Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
undelborg at gmail.com
Fri Jun 19 22:33:45 UTC 2015
Here comes what I was able to find over the Internet.
Burning issue with another Plextor drive and openSUSE 11.2:
Very old kernel bug related to burning:
There are some other posts reporting issues with Plextor drives under
Linux, however most of them are unanswered.
I'm thinking of recompiling the kernel to "tweak" it for my case. can you
suggest any options that i can try to enable/disale? I can only thing about
legacy scsi support.
Have a nice weekend
2015-06-19 19:45 GMT+03:00 Thomas Schmitt <scdbackup at gmx.net>:
> > growisofs was able to write the largest volume of data. Brasero, k3b and
> > xfburn all failed after just some seconds.
> But K3b used growisofs for burning.
> To my personal experience with nearly failing hardware
> it is quite futile to search for patterns in the instability.
> (And i spent some time with diagnosing such situations.)
> > However, k3b has successfully simulated the burning.
> This needs less electrical power than real burning.
> > Plextor uses 2 USB cables (one for power)
> Do you have a dedicated power supply for it ?
> Something like on http://www.notebookreview.com/assets/30825.jpg
> If so, try whether it works better then.
> > I have also found in Google that something similar users experienced in
> > openSUSE 11.2 it was fixed after update to 11.3.
> Can you remember some URL ?
> Would be interesting to read if it affected DVD burning.
> Whatever, as long as the system call ioctl(...,SG_IO,...)
> returns with indication for SG_ERR_DID_ERROR, i can hardly
> do anything for you.
> If other burn software yields significantly different results
> then it might be due to small differences in write parameters.
> E.g. whether DVD-R is written as DAO or as Incremental, or
> whether on DVD+R a track was reserved before writing.
> During data transfer both programs use WRITE(10) but might
> have a different rythm with inquiring the buffer fill.
> But on the next error prone drive, the situation can be just
> the other way: libburn succeeds and growisofs fails.
> We'd need some time to find out which difference between
> growisofs and libburn would cause the different performance.
> And only your computer system can tell.
> The only hint i can give now is to post a bug for the kernel,
> saying the component "host_status" of "sg_io_hdr_t" as
> defined in /usr/include/scsi/sg.h has the value of 7 after
> (Specs: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html)
> Have a nice day :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pkg-libburnia-devel