Condensed list of problems with libburn

Hmm, I probably should've replied solely to this email. 
oops. 

On Mon, 12 Dec 2005, scdbackupgmx.net wrote:

> Hi,
>
> as announced: my condensed problem list which emerged
from
> the development of cdrskin.
>
> Sorted by personally-felt-pain priority.

Thanks!

>
------------------------------------------------------------
-----------------
> If a drive device file (here /dev/sg0) offers
r-permission
> but not w-permission then the call  burn_drive_scan() 
hangs
> quite forever. The CPU load goes up to 100 %.
> Ctrl+C is necessary.
>
> So this is an evil user trap:
>  crw-rw-r--    1 root     disk      21,   0 Sep 23 
2003 /dev/sg0
>
> There might be valid sysadmin reasons for such a
setting.
> Then it prevents the use of any other drive, too.

I think I've fixed this.  The fix is to disallow the use of
any device 
with such permissions.  I don't believe this breaks any
valid 
configurations.

>
------------------------------------------------------------
-----------------
> I found no means for an application to determine the
version
> of libburn at compile time and at run time.
>
> If there aren't any yet, i propose macros
>  #define BURN_LIBRARY_VERSION "0.2"
>  #define BURN_SNAPSHOT_DATE
"2005.12.08.203854"
>
> and a function
>  void burn_version_strings(char library_version[80],
>                            char snapshot_date[80])

I can see how a run time version string would be nice for
weeding out 
already-solved bug reports.  Other than that, why does the
app need to 
know what version it's using?

>
------------------------------------------------------------
-----------------
> The following call does not eject my HL-DT-ST DVDRAM
GSA-4082B
> (Linux 2.4.21-215-athlon, ide-scsi) :
>
>  burn_drive_release(drive, 1);
>
> Maybe noteworthy, some superuser commands:
>  # ls -l /dev/sg0
>  crw-rw-rw-    1 root     disk      21,   0 Sep 23 
2003 /dev/sg0
>  # eject /dev/sg0
>  eject: unable to eject, last error: Operation not
permitted
> Whereas eject succeeds on
>  # ls -l /dev/sr0
>  brw-rw----    1 thomas   floppy    11,   0 Sep 23 
2003 /dev/sr0
>

Still unresolved.  I'll try to reproduce here.

>
------------------------------------------------------------
-----------------
> RIP-14.5 (kernel 2.6.14) only:
> The following call sequence returns false status
information about the media
> if the tray was out and gets loaded by
burn_drive_grab():
>  burn_drive_grab(drive, 1);
>  ...
>  ret= burn_disc_erasable(drive);
>
> This sequence returns a correct reply:
>  burn_drive_grab(drive, 1);
>  burn_drive_release(drive,0);
>  burn_drive_grab(drive, 1);
>  ...
>  ret= burn_disc_erasable(drive);
>
> RIP-14 is a rescue system:
>  http://www.tux.org/pub/people/kent-robotti/looplinux/rip

>
> See also below, differing speed info on first and
second query after load.
> (The speed thing happens on 2.4.21 too.)

Still unresolved.  I'll try to test here.

>
------------------------------------------------------------
-----------------
> The following call does not cause padding to be
appended
>  int padding= 52428800;
>  burn_track_define_data(tr,0,padding,1,BURN_MODE1);
>
> Actually parameter "tail" is ignored in 
burn_track_define_data() .

Oops.  Not only is it not defined, but it's not honoured in
the sector 
generation code.  heh.

Neither is the offset option.

oh dear.

Should be fixed in cvs... I haven't tested it myself yet,
will try to do 
that tomorrow.

>
------------------------------------------------------------
-----------------
>
------------------------------------------------------------
-----------------
> There are two groups of messages printed by libburn
> regardless of verbosity level :
>
> ignored nwa: 0
>
> ctladr|trno|indx|form|scms|  msf
> ------+----+----+----+----+--------
> 4  1 | 00 | 00 | 01 | 00 |00:00:00
> 4  1 | 01 | 00 | 10 | 00 |00:00:00
> 4  1 | 01 | 01 | 10 | 00 |00:02:00
> 4  1 | AA | 01 | 01 | 00 |11:08:00
>
> There should be a way to disable them.

Done in cvs.

>
------------------------------------------------------------
-----------------
> The following call returns confusing values with 4x and
4x-12x CD-RW
>  ret= burn_drive_get_write_speed(drive);
>  printf("  burn_drive_get_write_speed =
%dn",ret);
>
> yields directly after loading the
>  burn_drive_get_write_speed = 4234
> and on second try
>  burn_drive_get_write_speed = 1764
>
> With kernel 2.6.14 and LITE-ON burner :
>  8448 resp. 2112
>
> No difference between 4x and 12x media.

Absolutely bizarre.  Those values should be returned
directly from the 
drive and independent of kernel version.

I'll dig around, but since I don't have 2.4.x here, I hope
you don't mind 
if I bounce potential fixes off you... 

>
------------------------------------------------------------
-----------------
> I feel itched by the fact that source data size is type
int and
> not off_t or double.

I propose uint64_t (and c99 dependency)

>
------------------------------------------------------------
-----------------
>
------------------------------------------------------------
-----------------
>
------------------------------------------------------------
-----------------
> Verbosity level 1 is quite unusable because it
> reports many times and very fast
>  logical unit is in the process of becoming ready
>
>
>
------------------------------------------------------------
-----------------
> The following does not prevent actual burning on my LG
GSA-4082B:
>  burn_write_opts_set_simulate(o, 1);

Does it prevent burning on your lite-on?  Is cdrecord
capable of 
simulating on that drive (in SAO or RAW)?

It's possible that the drive doesn't support simulation in
the requested 
write mode.
_______________________________________________
libburn mailing list
libburnlists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libburn