Sorry for posting to this list, I think the kde-users is a better place for this discussion.  I see more people get involved in the discussion. <blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Gene Heskett <gene.heskett@verizon.net> To: kdepim-users@kde.org Date: Thu, 24 Apr 2008 11:32:28 -0400 Subject: Re: [kdepim-users] K3b headache (Franco <deloptes@yahoo.com> Yes, that is at least the std behavour. In my test yesterday, not ejecting and  reloading the disk would only allow dd to access the last block of the image  written, the last 2048 bytes.  dd returned without error for whatever that's  </deloptes@yahoo.com></blockquote> this is really interesting ... on my system it checks all the bytes on both external cd/dvd and internal one.<deloptes@yahoo.com></deloptes@yahoo.com> <deloptes@yahoo.com></deloptes@yahoo.com><blockquote class="replbq" style="border-left:

 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><deloptes@yahoo.com>worth.  And it was capable of repeating that read action, getting the same <br>sha1sum answer each and every time at about 3 second intervals.<br><br>My intuitive reaction to this is that we WILL be forced to eject the disk, and <br>that k3b will need a different patch so it will just set there and wait, say <br>for a minimum of 1 minute when it gets an ENOTREADY from the drive after a <br>reload operation.  Presently, it appears that k3b treats this as an instant <br>real error and bails out.  Any other time its waiting for a disc, its just <br></deloptes@yahoo.com></blockquote>this seems to be easy doable (see below)<deloptes@yahoo.com></deloptes@yahoo.com><br><deloptes@yahoo.com></deloptes@yahoo.com><blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><deloptes@yahoo.com>waits, and then updates the gui when it can in the

 background, but not for <br>the verify pass reload, for some reason that is a failure.<br><br>Perhaps this background disc scan used in other places could be used for the <br>delay for the disc ready when verifying?  It certainly seems do-able to me, <br>but I've not had a chance to troll through the code yet, life keeps getting <br>in the way, and younger minds more fam with C++ stuff could probably find it <br>far quicker than I could.  I've never written a single line of C++ stuff in <br>my 73 years.<br><br></deloptes@yahoo.com></blockquote>what are the developers good for ;-) C++ like any other programming language makes a lot of fun (except you can brake your machine)<br><br>If the reason is really the wait time after reload it could be easy doable with few lines of code.<br>I am still preoccupied and can not spent any time on this issue, but if I have few hours I'll try to have a lookin it, as I am getting more interested in the problem.<br><br>I would recomend to

 try contact the developers first and reactivate the bug on this issue.<br>I'm pretty sure that this is due to a change of the k3b code or some underlaying library, because the issue is somehow new to me about a year now. <br>I still have a debian sarge system and it works like a charm there .... no comments :-)<br><br>best regards<br><br><BR><BR><p> 

      <hr size=1>Be a better friend, newshound, and 

know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a>