Hi, I'm running gentoo with xfce de installed. I emerged xfburn 4.0 without hal because I use udev + notify for mounting memory sticks and mount command is shared for all users for mounting cdroms, so I don't need hal at all. My problem is that when I try to start xfburn, I need to wait for a long time ~ 5 minutes or even more until xfburn window will be shown. dmesg | tail says nothing. /var/log/messages shows nothing either. PS I posted the text above to http://forums.gentoo.org/viewtopic-t-751076.html, but no answer followed -------------------------------------------------------------------- I've got an answer from bugs@da.mcbf.net (David Mohr) -------------------------------------------------------------------- Hi, could you please open up a bug report on http://bugs.xfce.org ? If you read the README, you'd know that running without hal support is not very well tested :-) But I'll look into the issue. An interesting piece of information might be the output of strace. Run $ strace -oxfburn.slow.strace xfburn and attach the xfburn.slow.strace file to the bug report. Thanks, ~David -------------------------------------------------------------------- Also I've noticed that when xfburn starts after ~ 5-10 minutes it shows /dev/hda in its detected devices. I'm wondering why it is so, I think it should be /dev/cdrom. It's interesting to notice that it starts slowly the first time after system start and it could start normaly (immediately) the second time and furtherly.
Created attachment 2270 $ strace -oxfburn.slow.strace xfburn $ strace -oxfburn.slow.strace xfburn
We can see it passes a long time doing nothing, that it timeouts a lot: ********** poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 3, 9) = 0 (Timeout) <=== HERE THE TIMEOUT REPEATED ENDLESS ********** The messages before the first Timeout are: ********** poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 3, 0) = 1 ([{fd=6, revents=POLLIN}]) select(7, [6], NULL, NULL, {0, 0}) = 1 (in [6], left {0, 0}) getuid() = 1000 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\0"..., 1}], msg_controllen=0, msg_flags=0}, 0) = 1 getsockopt(6, SOL_SOCKET, SO_PEERCRED, "H\21\0\0\350\3\0\0\350\3\0\0"..., [12]) = 0 select(7, [6], NULL, NULL, {0, 0}) = 0 (Timeout) ********** All in all, I don't think it is a problem in xfburn, to be sure I will compile it without hal support, and if I can reproduce than I'm wrong ;)
Well, I have no clue, I builded without hal, I get also Timeouts, but they are not endless. The app starts in one instant.
Thank you for your reply. Could you make a prediction what could it be? I reinstalled all gtk and X environment and xfburn also, but got no result. May be it would be better for me to try the last version of xfburn (0.4.1)? If you have nothing to offer I will need to try another cd burning app :(.
Thanks for looking into this Mike. The offending line seems to be nanosleep({0, 1002000}, NULL) = 0 though, which is likely caused by the loop around receiving a ready status from the drive through libburn. net_immigrant, could you check if there's an unstable version of libburn available in gentoo? If so, can you emerge it and see if that improves things? If not, let me know, and we'll make sure that's the cause before filing a bug with them.
Ah! Well that's it indeed, there are: 192840 nanosleep syscalls, which makes a total of 193225680000ns, which gives around 3 minutes. In my case the total is less than a second. I have libburn 0.6.4.p100.
thank you very much, guys. You are real cool ppl if you can find a problem in such a huge strace log. I installed dev-libs/libburn-0.6.4 as you told me (that is the latest unstable (~amd64 for gentoo) version) and everything worked fine! I'm amazed! Thank you
I'm really sorry for disturbing you again, but something strange happens to xfburn. It waits the time again. I don't know why it is so. It waits only the first time I start it during X session. It can start immediately the second time, but it also can start with delay :(
when I go to xfburn's preferences and push "Scan for devices" it scans very long time. Maybe there is an option to disable scanning?
No problems about reopening, if it's not fixed, it's not fixed. I will prepare a tarball with some debugging statements later for you to try, which should give us some more info to work with. And no, we need to scan for your drives - that should work just fine, and if it doesn't we'll fix that instead of creating a very little used option to specify the drive to work with.
Sorry, it took me a while. Please try rev. 7713, which has a bit of debugging output, and add post the console output here. Also please make sure to update to the newest libburn. Thanks!
Hi, there hasn't been any activity on this bug in a while. If you still encounter this problem, please try running 'cdrskin --devices' on the command line and let me know how fast that command processes.
thank you for your help. I forgot to commit a new status to the bug. All I've done is recompiled the kernel manually with different options. After that xfburn starts working. Now I'm having another problem with xfburn. When I burn an MP3 disk and try to play it in my car, it doesn't plays. But if I burn the same MP3 data using Nero under win XP at my work, it plays OK in the car. Do you know where the problem may come from?
Thanks for the feedback, I'm glad it is working ok now. Regarding the MP3 disc problem, I'm assuming that you burned a data disc with mp3 files on it, not an audio disc, correct? Are you sure you did the same in Nero? Can you see the contents you expect if you put the disc in the computer? I have certainly burned MP3 discs with xfburn and played them in my car, so there is no problem that I'm aware of. But this is really off-topic for this bug. If you need more feedback, please ask on the xfce mailing list, or open up a new bug.