On Thursday 05 July 2012 08:47:15 Thomas Schmitt wrote: > Hi, Hi All,
> i am currently the developer of libburn and libisofs. > > > https://bugzilla.gnome.org/show_bug.cgi?id=655601 > > I know about such problems, but i do not know how to get into a > discussion with Brasero developers. > My impression is that the libisofs plugin causes libisofs to end > prematurely. libburn is less of a suspect here. > > > I have seen burn logs where burning ends after about 50 % of > the expected output was produced by libisofs. I.e. libisofs would > want to write more, but for some reason libburn is urged to finish > burning (or falsely decides that burning is done). > https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 > https://launchpadlibrarian.net/71440716/brasero_log.txt > > have: > > BraseroLibisofs Finished track successfully > > BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs > > ... > > BraseroGrowisofs stdout: 3866984448/7761410048 (49.8%) @4.0x, remaining > > 12:06 RBU 40.9% UBU 100.0% BraseroGrowisofs called > > brasero_job_get_action > > BraseroGrowisofs called brasero_job_set_current_action > > BraseroGrowisofs stderr: /dev/sr0: flushing cache > > ... > > BraseroGrowisofs stderr: HUP > > Note that libburn is not involved here. Only libisofs. Burning is done > via growisofs. > Further it seems that BraseroLibisofs is the one which decides when > the connection between both shall end. > > > But in > http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344 > the work of libisofs seems to get completed. > > > brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %) > > So this might be two different problems. > (In this run, libburn was indeed in charge of writing to media.) > > > --------------------------------------------------------------------- > > I am not aware of any changes in libisofs or libburn which about a year > ago could have introduced such problems. > The combination of libisofs and libburn works fine in xorriso. > xorriso does several backups per day for me, which then get thoroughly > checked for readability and correct content. > > If somebody shows up who understands the code of the libisofs plugin > and could make experiments, then i would be glad to help with finding > the cause of the problem. Same issue already reported long ago at: https://mail.gnome.org/archives/brasero-list/2011-July/msg00004.html actors: libisofs and growisofs brasero plugins symptoms: 50% finished at ~49% Looking at the logs and the brasero plugins code, the main suspect most likely hidden at: 1) erroneous read of growisofs std out, wrt written data, and buffer filling, hence a premature leave might occur: plugins/growisofs/burn-growisofs.c static BraseroBurnResult brasero_growisofs_read_stdout (BraseroProcess *process, const gchar *line) { int perc_1, perc_2; int speed_1, speed_2; long long b_written, b_total; /* Newer growisofs version have a different line pattern that shows * drive buffer filling. */ if (sscanf (line, "%10lld/%lld (%4d.%1d%%) @%2d.%1dx, remaining %*d: %*d", &b_written, &b_total, &perc_1, &perc_2, &speed_1, &speed_2) == 6) { BraseroJobAction action; brasero_job_get_action (BRASERO_JOB (process), &action); if (action == BRASERO_JOB_ACTION_ERASE && b_written >= 65536) { /* we nullified 65536 that's enough. A signal SIGTERM * will be sent in process.c. That's not the best way * to do it but it works. */ brasero_job_finished_session (BRASERO_JOB (process)); return BRASERO_BURN_OK; } 2) premature ending of the libisofs thread: static gpointer brasero_libisofs_thread_started (gpointer data) { ... if (brasero_job_get_fd_out (BRASERO_JOB (self), NULL) == BRASERO_BURN_OK) brasero_libisofs_write_image_to_fd_thread (self); ... Nothing more concrete norrowed down yet -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
