From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
I recently upgraded to xcdroast-0.98a15-6.FC2.1 and noticed that the
progress bars during a burn do not work. Rather, the progress
information is printed into the log window. It seems like something
in xcdroast isn't parsing that info and translating it into the bars.
At least, until the end of the burn, when the bars suddenly "pop"
into a near-finished state.
It does seem to burn OK, but I haven't tried anything more than an ISO
[root@ixion scratch2]# cat /proc/version
Linux version 2.6.7-1.494.2.2smp (firstname.lastname@example.org)
(gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Tue Aug 3
09:59:49 EDT 2004
Note, there is a bug similar to this for devel and a *different*
version of xcdroast:
I don't know how xcdroast-0.98a15-5 and xcdroast-0.98a15-6.FC2.1
differ or how FC2 and devel differ, so I filed another bug.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create ISO and start xcdroast.
2. Write ISO to CD
3. Watch as the info window progress bars.
Actual Results: The bars don't do anything, the percentage indicator
seems to be too much to the right, and progress info is spit into the
Expected Results: The progress bars should fill up from left to right
as a good left-to-right progress bar should.
Created attachment 104627 [details]
Logfile from xcdroast ISO burn
Ahhh...noticed something. When I open that attachment in less, the
progress lines are ended with ^M characters. When you view it here,
they are not visible; it must be saved. Should a GNU/Linux program be
sending ^M as linebreaks, or is this normal for xcdroast?
I should say, I've never saved output from xcdroast, so I have no
basis on which to judge whether ^M characters should be there.
UHHHH...wha? I use Fedora Core 2, not Redhat 9. I have
system-config-network-1.3.17-0.FC2.1, so this seems like a downgrade,
and then I'm not sure how this affects xcdroast, really.
sorry, wrong window :)
Also seeing this in Fedora Core 3 test 3. This did work in FC3 test 2
Just a couple of notes:
1. It's not just the progress bars. The entire xcdroast gui is frozen
while burning. You can see it by opening another window in front of
xcdroast and then iconifying it. It's like control is simply never
returned to gtk to repaint the window while burning. The exception is
the text area in the burn window where cdrecord's output gets.
2. There is loads of info from cdrecord in the abovementioned text
area. I guess this should be catched by xcdroast and used for progress
bar updating? I've never seen all that output previously.
FC3 - grabbing audio tracks shows similar problem as described here.
Burning seems ok however.
Not for me. After upgrading to FC3 from FC2, I still see the same
effect. Checking my RPM database, I see that the upgrade via Anaconda
did *not* pick up the FC3 xcdroast, rather I still had:
So, not wanting to comment prematurely, I go to my local mirror and
pickup the FC3 version, in case it got fixed:
# rpm -Uvh xcdroast-0.98a15-6.i386.rpm
package xcdroast-0.98a15-6.FC2.1 (which is newer than
xcdroast-0.98a15-6) is already installed
Huh. Well, an --oldpackage later, the FC3 version is installed, and
blammo, the same problem burning ISOs as I previously saw.
And, like Mr. Eriksson, I too see the whole GUI being "frozen".
Created attachment 108597 [details]
Tim Waugh's linebuffer patch (which solved bz#127658) is responsible for this.
This patch defines a new function read_line_wait() in tools.c where Tim's
changes are kept separately while the read_line() function is restored to its
old behavior. read_line_wait() is now called from getcdtoc_out(), which should
keep bz#127658 closed.
Merci beaucoup Didier!
:) You're welcome!
I noticed something else, though. Not sure whether it's a related
issue or not. Whenever I burn on-the-fly (at least in simulation
mode), xcdroast ends up with the message "Error writing tracks", even
though AFAICT the actual operation went fine. Until now, I haven't had
the time yet to check whether ISO or CDDA burning has the same
problem, and I don't have enough CDRs to spare at the moment to do
tests in non-simulation mode. Any idea?
No, sorry, no such bug report yet..
Just for the record: I always burn on the fly, and I never get any
oops... reopen... did only update FC2, yet...
This error is showing up with
and a look at http://cvs.fedora.redhat.com/viewcvs/rpms/xcdroast/ shows that the
frozen gui patch wasn't applied in devel, only in the FC-3 rpms.
Umm, is there some reason why the frozen progress bars patch got applied to the
FC3 rpm, but not to the one in devel? The rawhide package and the package in
FC4T1 show this error again. Can someone apply the patch to the version in
devel as well?
Adding comment for FC4T2-- still broken. Still needs fixing in devel as well,
and it's a trivial fix to add the patch. Sorry to keep bugging, but this would
be a pretty annoying regression from FC-3 to FC-4.
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Just noticed that this still doesn't work. Did that patch ever get applied, and
if not, why?
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Whoa...sorry, didn't know this was still open. I'm fairly sure it was solved
sometime in 5. Closing.