[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed
Date: Sat, 13 Apr 2019 14:31:25 +0200


Adalbert Han├čen wrote:
> I would propose to ask the maintainers of xfburn

There are none, to my knowledge.
The other GUI programs Brasero and K3B are orphaned similarly.
(Well, with K3B i know at least somebody who can bring code changes into
 the official version.)

As the situation is, i will try to fix the problem in libburn and
simply force a more reasonable use of Stream Recording. (My own GUI demo
xorriso-tcltk has "Defect Mgt" disabled by default, which means that
Stream Recording is enabled by default. So many of my fingers point back
to me if i accuse Xfburn of overdoing it.)

> How shall we proceed with the open tread in
> https://askubuntu.com/questions/1131646/xfburn-fails-burn-run-failed
> I propose to give an answer myself:

This will be necessary as my web browser is disliked there.

I propose that i write a technical diagnosis which you quote literally
and that you surround it with your experiences and tips around Xfburn.
(See below)

> It was found that in this situation, the CD drive indicated not to
> be able to perform StreamRecording, however the underlying libburn requested
> it to do so. An amendement of libburn is started but until this finds its
> way to a stable release which probably will not find their way back to older
> versions up to and including version 0.5.4 for Xfce 4.12 (and possibly even
> newer ones),

This part is technically incorrect.

There are drives which with some media announce not to do Stream Recording.
libburn has a bug by trying despite this announcement.
This bug will be fixed in future libburn-1.5.2. (Maybe not before september.)

As soon as libburn-1.5.2 is installed as libburn4.so, Xfburn will be
allowed to always ask for Stream Recording. libburn will prevent it quite
silently if it seems not appropriate.
That's the magic of dynamic linking.

The problem with your drive in the W530 is that it lies about its
capability for Stream Recording.
The drive in the T400 warns that it cannot do Stream Recording with CD-R.
Probably it really cannot.
My drive LG BDDVDRW GGC-H20L warns too, but tolerates it in the end.

> Probably one more line about SAO or TAO should be added.

Not necessary. It was a possible issue as long as i believed in problems
between drive and medium. (Because the W530's drive showed such a misleading
error code.)
A well working drive should support both. If it reproducibly fails with
one of them and succeeds with the other, then it is half dead already.

> 2. xfburn in its current version sometimes detects the wrong capacity of CD
> media (e.g. 650MB instead of 700MB).

It does not detect the medium capacity. It rather announces which known
media capacity it would need at least for the job as is defined so far.

> For the successfull trials this has
> been corrected manually. No trial has been done whether this is necessary or
> not.

There is no need to choose another size if the medium is actually larger.
(If you exceed 50 GiB, the last size step is 2 TiB, just as backstop.

My technical diagnosis:

It turned out that the drive cannot stand SCSI command WRITE12 with
Streaming bit set, at least if a CD-R is inserted. This command is
caused by Xfburn option "Stream Recording".

libburn up to version 1.5.0 is sloppy about asking the drive in advance
whether it would accept such a command. Xfburn urges it to do this
beginning at block 32. Thus the first two WRITE commands are WRITE10
and only the third one switches to WRITE12 with Streaming bit.
This third command yields the error.

Most drives seem to tolerate this, even if they announce not to do.
But the drive in question not only takes offense, but also gives a wrong
announcement that it would accept WRITE12 with Streaming bit.

So libburn-1.5.2 and later will take precautions not to apply this
gesture to drives which do not announce to accept it.
It is not yet decided whether Stream Recording will be omitted with all
media types except DVD-RAM, BD-R, and BD-RE. For now it seems that no
other remedy is possible for the drive which caused this question here.

As soon as future libburn-1.5.2 is installed as dynamic library, freshly
started Xfburn will automatically take advantage of the improvement.

End of technical diagnosis.

> I'll do the outstanding trials later (and sacrifice up to 4 more CDs for
> that).

Actually i only have one sacrifice proposal:
Check whether the T400's drive tolerates Stream Recoding with CD-R.

Everything else is assessed now. As said above, i need to decide whether
i can make libburn safe for your W530's drive without taking away any
useful opportunities from better behaving drives.

> I propose that I start a bug report on https://bugzilla.xfce.org/

Disabling the Stream Recording option by default would make life safer
for those drive which cannot tolerate it.

But it would also lure people into the awful Defect Management of
DVD-RAM, BD-R, BD-RE. If that management begins to replace poorly readable
blocks by reserve blocks, madness breaks out.
I.e. even with bad media, it is better to suppress Defect Management
by Stream Recording. With good media, Defect Management is just slow
and useless.

But this applies only to three media types.
So if i'd propose a remedy to Xfburn, it would be what i ponder now
for libburn:
  Determine the medium type (i.e. "profile") by libburn call
  burn_disc_get_profile() and pre-enable Stream Recording only with
  these profiles:
      0x12 "DVD-RAM"
      0x41 "BD-R sequential recording"
      0x43 "BD-RE"

I am not sure how well this would fit into the architecture of Xfburn.
The GUI elements and their defaults might not know much about the drive
and the medium.

I considered to post a bug report for Debian. But that would mean to
enter Xfburn development for proposing a patch. My system is actually
not new enough to have a contemporary XFCE library empire.
I could try to bring a patch in Debian's libburn-1.5.0 package. But my
Debian sponsor will demand tests which i cannot do on a virtual machine.

So maybe an accelerated release of libburn-1.5.2 is the best way to go.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]