[Libburn] Condensed list of problems with libburn

[Derek Foreman]

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

On Mon, 12 Dec 2005, scdbackup at gmx.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 = %d\n",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.