Bug 134334

Summary: xcdroast progress bars don't work
Product: [Fedora] Fedora Reporter: Matt Thompson <fortran>
Component: xcdroastAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: alfredo.maria.ferrari, dm, idletask, jbourne, mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: xcdroast-0.98a15-8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-22 15:43:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Logfile from xcdroast ISO burn
none
xcdroast-frozen_gui.patch none

Description Matt Thompson 2004-10-01 14:21:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922 Galeon/1.3.17

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
burn.

My info:

[root@ixion scratch2]# cat /proc/version
Linux version 2.6.7-1.494.2.2smp (bhcompile.redhat.com)
(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:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131284

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):
xcdroast-0.98a15-6.FC2.1

How reproducible:
Always

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
log window.

Expected Results:  The progress bars should fill up from left to right
as a good left-to-right progress bar should.

Additional info:

Comment 1 Matt Thompson 2004-10-01 14:22:58 UTC
Created attachment 104627 [details]
Logfile from xcdroast ISO burn

Comment 2 Matt Thompson 2004-10-01 14:25:27 UTC
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.

Comment 3 Harald Hoyer 2004-10-01 15:12:58 UTC
ftp://ftp.redhat.com/pub/redhat/linux/updates/9/en/os/noarch/

redhat-config-network-1.2.15-1.noarch.rpm
redhat-config-network-tui-1.2.15-1.noarch.rpm


Comment 4 Matt Thompson 2004-10-01 15:27:09 UTC
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.

Comment 5 Harald Hoyer 2004-10-01 20:20:24 UTC
sorry, wrong window :)

Comment 6 James Bourne 2004-10-17 19:55:23 UTC
Also seeing this in Fedora Core 3 test 3.  This did work in FC3 test 2
however.


Comment 7 Daniel Malmgren 2004-11-12 12:21:42 UTC
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.

Comment 8 Adam Pribyl 2004-12-06 21:06:48 UTC
FC3 - grabbing audio tracks shows similar problem as described here.
Burning seems ok however.

Comment 9 Matt Thompson 2004-12-06 22:33:12 UTC
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:

xcdroast-0.98a15-6.FC2.1

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
Preparing...               
########################################### [100%]
        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".

Comment 10 Didier Heyden 2004-12-15 10:09:54 UTC
Created attachment 108597 [details]
xcdroast-frozen_gui.patch

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.

Comment 11 Harald Hoyer 2004-12-15 11:17:27 UTC
Merci beaucoup Didier!

Comment 12 Didier Heyden 2004-12-16 10:13:51 UTC
:) 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?


Comment 13 Harald Hoyer 2004-12-16 10:35:38 UTC
No, sorry, no such bug report yet..

Comment 15 Daniel Malmgren 2004-12-16 13:26:48 UTC
Just for the record: I always burn on the fly, and I never get any
error messages.

Comment 16 Harald Hoyer 2004-12-16 17:00:30 UTC
oops... reopen... did only update FC2, yet...

Comment 17 John Thacker 2005-03-26 21:50:19 UTC
This error is showing up with
xcdroast-0.98a15-10
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?

Comment 18 John Thacker 2005-04-15 13:44:20 UTC
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.

Comment 19 Matthew Miller 2005-04-26 15:27:30 UTC
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.

Comment 20 Daniel Malmgren 2005-09-18 11:21:22 UTC
Just noticed that this still doesn't work. Did that patch ever get applied, and
if  not, why?

Comment 21 Christian Iseli 2007-01-20 00:56:39 UTC
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 ?

Thanks.

Comment 22 Matt Thompson 2007-01-22 15:43:12 UTC
Whoa...sorry, didn't know this was still open.  I'm fairly sure it was solved
sometime in 5.  Closing.