[Libburn-hackers] Re: Real-time data stream

Thomas Schmitt scdbackup at gmx.net
Tue Aug 28 06:55:56 CDT 2012


[libburn-hackers list should work now]

> >> 3. Delay for several seconds.
> > This is quite demanding to the drive.
> Does this method of working appear on the
> DVD+R/DVD-R/DVD-RW(unformated)?

It should work very well with DVD+R. I am not sure how much DVD-R[W]
inherited its properties from CD-R.

On CD with write type DAO or SAO, there would be capacity wasted
by insufficient data supply by the input stream. The drive will have
to write some invisible blocks in order to resume writing, when new
data arrive.

I assume that there will be no such problem with DVD-R[W] and
"Incremental Streaming", which gets used if you order BURN_WRITE_TAO
for DVD-R[W].

> Track 1 : sector 24 of 2097302  [fifo active,  0% fill]
> ......
> Then the program seems like died loop and can't exit.

Obviously libburn did not take notice that the pipe was closed.
I will have to investigate.

Please send me the complete program which made this happen.

> I have to restart pc (keep disc in the drive).

That's the reason why i have some USB attached drives. One can
reset them by power-off-power-on without rebooting. At least on
Linux, which has a robust USB driver.

> telltoc : SORRY : Unsuitable media detected. Profile 0000h 
> Eject the disc and insert it again.
> Media current: DVD-RW sequential recording

Probably the burner took offense from being started up with a blank
medium inside. (Chances are that the medium was not altered by
the aborted burn run, because the drive was still waiting for
its buffer to fill with data.

> fpid=fork();

Why did you fork ?
Your program will stay running during burn_disc_write() and
libburn will create a program thread for burning (i.e. a
lightweight child).

I assume that the father keeps pipe[1] open, so that pipe[0]
does not produce EOF for libburn.

If you want to risk more experiments, then do
as first action of the father, before it calls libburner_payload().

See also the example at the end of man 2 pipe:
  close(pfd[1]);          /* Close unused write end */
  close(pfd[0]);          /* Close unused read end */
The difference to you program is that your child is the writer
and the father is the reader. In the manual example it is vice
Rule of thumb: Close immediatly what you do not plan to use.

But actually i meant that the drive-watching loop in
libburner_payload() should feed the pipe. As said, you do not need
a child process for concurrent execution. Without child, you do not
have a doubly open file descriptor, and thus no need for closing
its input immediately in the process which does not read

If you refrain from experiments, then send me your program.
I will try to get it working.

Have a nice day :)


More information about the Libburn-hackers mailing list