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:
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.
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
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 however.
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: 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".
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.
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 error messages.
oops... reopen... did only update FC2, yet...
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?
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 ? Thanks.
Whoa...sorry, didn't know this was still open. I'm fairly sure it was solved sometime in 5. Closing.