Version: 2.0.0 (using KDE 4.4.5) OS: Linux I was buring an ISO to a CD RW, for which K3B offers the speeds 4x and 10x. Burning speed was set to Auto. When burning started I got the following message: Medium or burner does not support writing at 10x speed Switching burn speed down to 1 750x This does not make sense. When I saw the status messages during burning, I realised that this "1 750" was the burning speed in KB, which IS 10x. After burning was completed, the average speed was shown as 1556KB/s (8,89x). Also note the descrepancy in number formatting: said messages have a space between thousands and hundreds, while the average burning speed label does not. Reproducible: Didn't try
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
(In reply to Justin Zobel from comment #3) > Thank you for reporting this issue in KDE software. As it has been a while > since this issue was reported, can we please ask you to see if you can > reproduce the issue with a recent software version? > > If you can reproduce the issue, please change the status to "REPORTED" when > replying. Thank you! I currently don’t have any media to test. But the code lines in question haven’t been changed since early 2010. So unless cdrdao changed its output since, the bug probably is still present.