Bug 139084

The dvd project problem is already fixed. I am not sure about the DVD Copy. I did not know there were problems, too.
Could you please try the current svn?

I'll give it a try as soon as possible. Thanks for the good work!

With current SVN, also the DVD Copy (on the fly) verification works. By now I've tested only 2 times, but with the same files that have given errors before.

great. thanks.

Hi, I saw that status of this bug is RESOLVED but verification in 1.0_rc4 fails.
Mayby it's different component but I don't like to open new bug.
Issue:
When I burn DVD/CD from image, verification ALWAYS fails.
I noticed that it's releated to image size (image on medium is longer for 1 sector <2048B>). That "extra" sector is all covered by zeros, but it makes verification to fail.
Data is of course good.

Thanks for the hint. I always focused on the project verification. I found the 
bug and fixed it.

Data verification failed again on a DVD project (files on the hard disk burned on a DVD-R 8x DVD).
I'm using 1.0rc5 form packman rpm (openSUSE 10.2 packman repository).

NOTE: if this can help, files are > 600MB (one of these is 1,2 Gb large).

I've tested a bit this problem.
It seems that the problem happens only with DVD-R discs.
I've tried to burn the same DVD project on 4 DVD (2 DVD+R, 2 DVD-r):
with DVD+R, the verification ends with success, with DVD-R the verification fails.
I hope this help...

Another thing that I've noted:
verification fails also with DVD+R in multisession (or Auto) mode. In "No multisession mode" all is ok.
With DVD-R the verification fails also with "No multisession" mode.

Mmmh, verification failed again, on DVD+R with "No Multisession" mode.
So, I think the problem happens randomly...

And you tested the data manually afterwards?

I did some more tests myself and all were successfully verified:

* DVD+RW thousands of small files (approx 3.5 GB)
* DVD-R one file (1.5 GB) multisession
* DVD-R multiple big files append session
* DVD+R multiple files multisession
* DVD+R append session

I've tested the data manually (with md5sum -b) on all the DVD marked invalid by k3b 1.0rc5 verification process, and all data were valid.
This with 4 DVD over 6 DVD totally burned (2 DVD passed data verification normally).
Maybe my version (installed through Packman opensuse 10.2 repository) is unfixed?
I'll try with current SVN version and I'll report the test results made with that.

I've burned 3 DVD+3 using current k3b SVN.
2 of 3 are ok, on the third data verification fails (but the data are ok, checked by md5sum -b.
The burning process I've used is:
1) Open the program, burn the first DVD, close the program.
2) Open the program, burn the second DVD, close the project without closing the entire program, create a new project, burn the third DVD.

Maybe a buffer problem when burning more than one DVD in the same program session (but in two differen projects)?
In my opinion, it should be also checked the verification process on two different projects opened at the same time (for example DVD_Data0 and DVD_Data1), and also try to burn 2 different DVD using the same project (changing only the files in the project).

> Maybe a buffer problem when burning more than one DVD in the same program
> session (but in two differen projects)? In my opinion, it should be also


I used different projects in the same session, different sessions, the same 
project, it alway verifies properly. Sorry, I cannot reproduce it. Not even 
once.

> checked the verification process on two different projects opened at the
> same time (for example DVD_Data0 and DVD_Data1), and also try to burn 2
> different DVD using the same project (changing only the files in the
> project).


I did all that and it always works...

The only thing left is that K3b does not only check the files themselves but 
also the data structures of the file system. You probably used md5sum on the 
files. Thus, you did not check the rest of the DVDs. You could verify that by 
burning with an image that you do not delete. Then compute its md5sum and 
compare it to the md5sum of the burned data. The latter can be extracted via 

dd if=/dev/xxx bs=2048 count=<size of the image as displayed by k3b or size of 
the image file divided by 2048> | md5sum -

Yes, i've used md5sum on the files. I'll try to calculate the digest on the entire image, but in this situation i think i'll close the this bug soon.
It can be a problem of my burner or something else?

> ------- Yes, i've used md5sum on the files. I'll try to calculate the
> digest on the entire image, but in this situation i think i'll close the
> this bug soon. It can be a problem of my burner or something else?


It could be the burner although I don't get why the files are properly written 
then. Sadly I don't know of any other solution... :(

This time the problem was my burner.
I've just upgraded the burner firmware, and now data verification always works. Damned burner... :)

Just a last request: can you try to burn one or more files > 1.5 Gb but < 2 Gb with data verification enabled? 

> ------- Just a last request: can you try to burn one or more files > 1.5 Gb
> but < 2 Gb with data verification enabled?


I did and it worked flawlessly.

Hi,
I experience the same problem with video DVD - DVD+R with rc3 and now rc6.
Speedsetting 8x of max 16x.
Crosscheck I did by comparing the VOB files. By crusader compare and by Total Commander compare. 
I burned ~100 Video DVD with Win + Nero and always verify without problem with my burner.
This morning I tested a rewritable DVD, max Speed 4x - Verify was ok.
Further help is very much welcome!

regards
Klaus
klsgbk@web.de

Sadly, I must say that the problem appeared again after fimware update.
The verification fails sometimes (normally when burning large files, for example creating a DVD with 4/5 files, each approx. 800 Mb large (or 2/3 files 1,4/2,1 Gb large).
Burning DVD with hundreds of small files, the verification works ok.
I don't know where the problem is... My burner and DVDs I'm using are described in the first posted message.

Created attachment 19645 [details]
debugging patch against K3b 1.0rc6

Since I have no way of reproducing the verification problem but others have I
need a way to get more information. Thus, I wrote this patch which hopefully
provides this information.
Please apply it, force a failed verification run, and send me the K3b debugging
output as presented in the debugging window (not the console output, although
both might be best).

thanks Sebastian,
unfortunately there is something bad in the new source:
   "k3bactivepipe.cpp:5: error: stray '@' in program"
I tried to correct this, but have too less experience with C

regards

you need to patch from the libk3b dir. Sorry, I forgot to mention that.

again: I am not an expert:
1. I rename your attachment to "k3bactivepipe.cpp"
2. I copy it in the dir "libk3b"
3. I leave the original "k3bactivepipe.cpp" unchanged in lib3b/tools 
4. I run ./configure > make > make install
this what you propose me to do?
or how else do I patch from libk3b dir?

Klaus, you must apply the patch via the command

patch -p0 < patchfilename

Copy the patch file in the "libk3b" directory (located in the source dir), open a console, go in that directory and launch the command above.

I'll try this patch as soon as possible.

Hi Francesco - thanks!
this is my first patch now - just compiling
should be in bed now; vacations are over :-(

Created attachment 19656 [details]
attachment for # 139084

k3b protocol

ah, my comment disappeared - once again:
the patch was successfully applied; then conf > make > make inst
however I detected no option or tick box for a forced verification.
the saved protocol is submitted anyway under #29

Created attachment 19659 [details]
Debug window output

Created attachment 19660 [details]
Console output

Althougth I've burned on the fly, I would note that the image size burned ( > 4
Gb, 5 files) is larger than the free space available on the partition
containing the temp dir.

In the debug window output, I've noted these lines:

K3bMd5Job
-----------------------
Stopped manually after 4500459520 bytes.

but the track size is 4500477952 bytes... Why was the job stopped? I've done nothing to stop the job...

Guys, I think I found the bug. That is if verification only fails for VideoDVD projects...

Created attachment 19661 [details]
Properly determine the size of a Video DVD project before burning

K3b actually did not use the same mkisofs parameters for the project size
calculation as it did for the actual burning. It missed the Video DVD specific
ones.
Please test if this patch (again to be applied in the libk3b folder via "patch
-p0 < patchfile") solves the verification issue.

I must say that, for me, verification fails on Data DVD Project: must I however try the patch?

> ------- I must say that, for me, verification fails on Data DVD Project:
> must I however try the patch?


Too bad. no, the patch is only for Video DVD... I will keep on searching. But 
for that I need a failed data project run with the new output (the new patch 
also contains it)

The posted failed output was generated with the previous patch installed...
The new patch offers new debug output?

Sorry, no, I got st mixed up. thanks, your output is very helpful.

It makes no sense to me to do further tests with new patches before I do not see the option "force a failed verification run". I raise the question and got no answer. Also my DVD stock is getting smaller ;-)
I see new libs in the k3b folders, but the menu and the output seem to remain on standard rc6. Where might be the problem?

Created attachment 19676 [details]
Maybe the bugfix?

Although I don't understand why yet this could be the fix. Please test.

when I start k3b from menue, it starts fine; when I start from bash /opt/kde3/bin, I get the message "unable to find growisofs exec".  
Per google I find at lot about it, but no clear clue.
As mentioned above, I do not see another behaviour or menu after the first (!!) patch.
I know, this is not a hotline here: But if there is no help for engaged users, who were trying to help, then there is still win-xp for me to help.

You already wrote before: "I detected no option or tick box for a forced verification". And now: "It makes no sense to me to do further tests with new patches before I do not see the option "force a failed verification run"." What do you mean?

Please try the latest patch. Since for me verification ALWAYS succeeds I have no way of testing it myself I have to rely on your tests. Thanks a lot.

As for the growisofs issue: same here. No way to test that for me as it always works here, however I start K3b.

Klaus, the proposed patch doesn't change anything on k3b interface. Sebastian wanted to say "Try burning DVD (rewriteable DVD if your stock is low ;)) until you get a verification error: in that case, post the debugging output (you can save it via the button "Debug output..." located in the k3b burning window)."
There is no additional window/control applying the patch, simply it adds some extra debug text in the "Debug Output" window ;)

For me, i'll soon apply the last patch and post the results when a failure happens.

thanks for your comments. 
forced verify: I understood something extra would come up like verifying now sector 1, 2, 3 - not the regular verify box. Thats why I was unsure, whether I was working with the patched version at all. 
Anyway I attached the output of a failed verify after my test (19656) of patch 1 with message #29.
Now in between I tested the recent patch nbr 3 (from att 19676):
In the menu output it said "verifying track 1". However after 100% verify
the clock continued counting. About 2 minutes later it seemed, that the seconds moved faster in .5 seconds pace.
I waited 10 minutes, then I pressed the abort button and the red "failed line" was displayed. I was a bit confused - and I believe there was no possibility to save a protocol.

Same thing for me: with the new patch (id=19676) data verification never ends... I would ask: the output done with the patch id=19645 isn't suffucient to inspect this bug?

> ------- Same thing for me: with the new patch (id=19676) data verification
> never ends... I would ask: the output done with the patch id=19645 isn't
> suffucient to inspect this bug?


I actually hoped the last patch would fix the problem. I was wrong. Could you 
please provide the output from the last run (the one that never stopped). You 
can find it in ~/.kde/share/apps/k3b/lastlog.log.
Thanks a lot and sorry for the workload. :)

Created attachment 19681 [details]
k3b lastlog

No problem :)

Created attachment 19683 [details]
Yet another attempt for a fix

This patch contains two things:
1. A little change in the code that hopefully fixes the verification issue.
2. If not it adds additional debugging output for further bug hunting.

Thanks a lot, guys.

I'll have a go too, when I am at home later.
Francesco proposed to me to use DVD-RW :)
I mentioned ealier, that with my hard and software DVD-RW normally seem to verify without problems. Only disks DVD+/-R together burning speed of 8x typically show the effect and nearly always then.
 

Hi Sebastian,
cross fingers - positive news - 1st result on patch-4 (19683)
I will post the protocol as well.
1. project incl. verify completed normally with "ta-ta-ta" :)
2. I will try to setup one or two new video projects today. As mentioned: normally almost each verify on DVD with speed 8x failed.
3. Further comment: verifying DVD always mentions track-1, even if there are also track-2 ore more. Would be an issue, if really only track-1 is verified. Maybe change the output to "verifying ..." ;-)

Created attachment 19692 [details]
k3b protocol - patch-4

see my last comment - next time win the same posting ;-)

> 1. project incl. verify completed normally with "ta-ta-ta" :)


yes!

> 3. Further
> comment: verifying DVD always mentions track-1, even if there are also
> track-2 ore more. Would be an issue, if really only track-1 is verified.
> Maybe change the output to "verifying ..." ;-)


Are you talking about Video DVD titles or multisession DVDs. Because the 
tracks are the tracks on the DVD: each session creates a new track. Maybe it 
is a little too technical for the GUI... It went in there because I use the 
term track everywhere else, most noticeable when copying CDs: Audio CDs have 
multiple tracks, and so have multisession CDs. I will try to improve that 
post 1.0.

just finished another video DVD with ta-ta :)

t your question:
yes, in DVD authoring programs each (lets say) movie is called a "track"
On a DVD you can see VTS_01_1, VTS_01_2 etc for "track-1"; maybe followed by VTS_2_1 ..... for track-2; etc. Normally in menues you can select atrack and within the track segmentation in logical chapters.
Together with multisession data discs, I was familiar with "sessions", which might be segmented in tracks on the discs.
Only wanted to say that for video DVD's users may take track for a movie, whereas multisession is not common there. 
Maybe you tweak the output to "verifying disk..." for video DVDs and think about further improvement post 5.0 :))

> just finished another video DVD with ta-ta :)


:)

> t your question:
> yes, in DVD authoring programs each (lets say) movie is called a "track"


don't you mean "title"?

> On a DVD you can see VTS_01_1, VTS_01_2 etc for "track-1"; maybe followed
> by VTS_2_1 ..... for track-2; etc. Normally in menues you can select atrack
> and within the track segmentation in logical chapters. Together with
> multisession data discs, I was familiar with "sessions", which might be
> segmented in tracks on the discs. Only wanted to say that for video DVD's
> users may take track for a movie, whereas multisession is not common there.
> Maybe you tweak the output to "verifying disk..." for video DVDs and think
> about further improvement post 5.0 :))


I cannot change strings anymore pre-1.0. So it has to wait...

Well, this one is fixed then, right?

don't know; it may depend on the SW. I used TMPGEnc Author. They call it Main menu > track menu > chapters
don't worry about the string in 1.0. It was just a comment regarding my "trained" terminology. Whenever you have a chance, you may want to rename it ...
I once succeded with 1.0 rc3 in a positive verify out of several burned disks, but never 2 disks one after the other with good verify. I will do another one maybe tonight - tomorrow is not possible.
But I would say it is very likely that you have fixed it. 

Have a handshake really and thanks from me. 
And also thanks to Francesco, who gave me 2 times the right trigger how to continue.

rgds  Klaus

3rd disk burned now with positive verify - I have nit crosschecked; the was never a difference in recent years.
however, when I read the protocol (from #52), it says:
First written md5 sum: b4ffa52527ece2e820159cc92620ba43
First read md5 sum: 0a20b47754d94972c642e6d5599bd49d

The 2 sums are different with all 3 disks.
I suppose, you are not comparing these 2 values and output the message: "all ok" ? ;)

those two sums can be ignored. they are not used. they are just part of the additional debugging output and are calculated wrong.

SVN commit 633751 by trueg:

* Added more debugging output for better bug hunting
* Fixed Video DVD project size calculation
* Let the MD5 job read all the data and finish gracefully
  instead of stopping it once the verification job "thinks"
  all data is processed.

BUG: 139084, 139391


 M  +26 -5     jobs/k3bdatatrackreader.cpp  
 M  +8 -3      jobs/k3bverificationjob.cpp  
 M  +9 -1      projects/datacd/k3bisoimager.cpp  
 M  +15 -2     projects/videodvd/k3bvideodvdimager.cpp  
 M  +3 -0      projects/videodvd/k3bvideodvdimager.h  
 M  +20 -4     tools/k3bactivepipe.cpp  
 M  +10 -0     tools/k3bactivepipe.h  
 M  +3 -0      tools/k3bmd5job.cpp  


--- trunk/extragear/multimedia/k3b/libk3b/jobs/k3bdatatrackreader.cpp #633750:633751
@@ -184,10 +184,13 @@
   }
 
   emitInfoMessage( i18n("Reading with sector size %1.").arg(m_usedSectorSize), K3bJob::INFO );
-  kdDebug() << "(K3bDataTrackReader::WorkThread) reading sectors " 
-	    << m_firstSector.lba() << " to " << m_lastSector.lba() 
-	    << " (" << (m_lastSector.lba() - m_firstSector.lba() + 1) 
-	    << ") with sector size: " << m_usedSectorSize << endl;
+  emitDebuggingOutput( "K3bDataTrackReader", 
+		       QString("reading sectors %1 to %2 with sector size %3. Length: %4 sectors, %5 bytes.")
+		       .arg( m_firstSector.lba() )
+		       .arg( m_lastSector.lba() )
+		       .arg( m_usedSectorSize )
+		       .arg( m_lastSector.lba() - m_firstSector.lba() + 1 )
+		       .arg( Q_UINT64(m_usedSectorSize) * (Q_UINT64)(m_lastSector.lba() - m_firstSector.lba() + 1) ) );
 
   QFile file;
   if( m_fd == -1 ) {
@@ -236,9 +239,11 @@
   }
 
   kdDebug() << "(K3bDataTrackReader) using buffer size of " << s_bufferSizeSectors << " blocks." << endl;
+  emitDebuggingOutput( "K3bDataTrackReader", QString("using buffer size of %1 blocks.").arg( s_bufferSizeSectors ) );
 
   // 2. get it on
   K3b::Msf currentSector = m_firstSector;
+  K3b::Msf totalReadSectors;
   m_nextReadSector = 0;
   m_errorSectorCount = 0;
   bool writeError = false;
@@ -264,12 +269,17 @@
 	readSectors = maxReadSectors;
     }
 
+    totalReadSectors += readSectors;
+
     int readBytes = readSectors * m_usedSectorSize;
 
     if( m_fd != -1 ) {
       if( ::write( m_fd, reinterpret_cast<void*>(buffer), readBytes ) != readBytes ) {
 	kdDebug() << "(K3bDataTrackReader::WorkThread) error while writing to fd " << m_fd 
 		  << " current sector: " << (currentSector.lba()-m_firstSector.lba()) << endl;
+	emitDebuggingOutput( "K3bDataTrackReader", 
+			     QString("Error while writing to fd %1. Current sector is %2.")
+			     .arg(m_fd).arg(currentSector.lba()-m_firstSector.lba()) );
 	writeError = true;
 	break;
       }
@@ -278,6 +288,9 @@
       if( file.writeBlock( reinterpret_cast<char*>(buffer), readBytes ) != readBytes ) {
 	kdDebug() << "(K3bDataTrackReader::WorkThread) error while writing to file " << m_imagePath
 		  << " current sector: " << (currentSector.lba()-m_firstSector.lba()) << endl;
+	emitDebuggingOutput( "K3bDataTrackReader", 
+			     QString("Error while writing to file %1. Current sector is %2.")
+			     .arg(m_imagePath).arg(currentSector.lba()-m_firstSector.lba()) );
 	writeError = true;
 	break;
       }
@@ -316,6 +329,11 @@
   m_device->close();
   delete [] buffer;
 
+  emitDebuggingOutput( "K3bDataTrackReader", 
+		       QString("Read a total of %1 sectors (%2 bytes)")
+		       .arg(totalReadSectors.lba())
+		       .arg((Q_UINT64)totalReadSectors.lba()*(Q_UINT64)m_usedSectorSize) );
+
   if( m_canceled )
     emitCanceled();
 
@@ -368,7 +386,7 @@
 // here we read every single sector for itself to find the troubleing ones
 bool K3bDataTrackReader::WorkThread::retryRead( unsigned char* buffer, unsigned long startSector, unsigned int len )
 {
-
+  emitDebuggingOutput( "K3bDataTrackReader", QString( "Problem while reading. Retrying from sector %1.").arg(startSector) );
   emitInfoMessage( i18n("Problem while reading. Retrying from sector %1.").arg(startSector), K3bJob::WARNING );
 
   int sectorsRead = -1;
@@ -387,12 +405,15 @@
     if( !success ) {
       if( m_ignoreReadErrors ) {
 	emitInfoMessage( i18n("Ignoring read error in sector %1.").arg(sector), K3bJob::ERROR );
+	emitDebuggingOutput( "K3bDataTrackReader", QString( "Ignoring read error in sector %1.").arg(sector) );
+
 	++m_errorSectorCount;
 	//	  ::memset( &buffer[i], 0, 1 );
 	success = true;
       }
       else {
 	emitInfoMessage( i18n("Error while reading sector %1.").arg(sector), K3bJob::ERROR );
+	emitDebuggingOutput( "K3bDataTrackReader", QString( "Read error in sector %1.").arg(sector) );
 	break;
       }
     }
--- trunk/extragear/multimedia/k3b/libk3b/jobs/k3bverificationjob.cpp #633750:633751
@@ -95,6 +95,8 @@
   d->md5Job = new K3bMd5Job( this );
   connect( d->md5Job, SIGNAL(infoMessage(const QString&, int)), this, SIGNAL(infoMessage(const QString&, int)) );
   connect( d->md5Job, SIGNAL(finished(bool)), this, SLOT(slotMd5JobFinished(bool)) );
+  connect( d->md5Job, SIGNAL(debuggingOutput(const QString&, const QString&)), 
+	   this, SIGNAL(debuggingOutput(const QString&, const QString&)) );
 }
 
 
@@ -255,10 +257,10 @@
       d->dataTrackReader->setSectorRange( d->toc[d->tracks[trackIndex].trackNumber-1].firstSector(),
 					  d->toc[d->tracks[trackIndex].trackNumber-1].firstSector() + d->currentTrackSize -1 );
     
+    d->md5Job->setMaxReadSize( d->currentTrackSize.mode1Bytes() );
+
     d->dataTrackReader->writeToFd( d->pipe.in() );
     d->dataTrackReader->start();
-
-    d->md5Job->setMaxReadSize( d->currentTrackSize.mode1Bytes() );
   }
   else {
     // FIXME: handle audio tracks
@@ -310,7 +312,10 @@
     d->md5Job->cancel();
   else {
     d->alreadyReadSectors += trackLength( d->currentTrackIndex );
-    d->md5Job->stop();
+
+    // close the pipe and let the md5 job finish gracefully
+    d->pipe.closeIn();
+    //    d->md5Job->stop();
   }
 }
 
--- trunk/extragear/multimedia/k3b/libk3b/projects/datacd/k3bisoimager.cpp #633750:633751
@@ -163,6 +163,10 @@
 
   d->pipe->close();
 
+  emit debuggingOutput( "K3bIsoImager", 
+			QString("Pipe throughput: %1 bytes read, %2 bytes written.")
+			.arg(d->pipe->bytesRead()).arg(d->pipe->bytesWritten()) );
+
   if( d->imageFile.isOpen() ) {
     d->imageFile.close();
 
@@ -321,8 +325,8 @@
     s += *it + " ";
   }
   kdDebug() << s << endl << flush;
+  emit debuggingOutput("mkisofs calculate size command:", s);
 
-
   // since output changed during mkisofs version changes we grab both
   // stdout and stderr
 
@@ -404,6 +408,10 @@
       m_mkisofsPrintSizeResult = m_collectedMkisofsPrintSizeStderr.mid( pos+33 ).toInt( &success );
   }
 
+  emit debuggingOutput( "K3bIsoImager", 
+			QString("mkisofs print size result: %1 (%2 bytes)")
+			.arg(m_mkisofsPrintSizeResult)
+			.arg(Q_UINT64(m_mkisofsPrintSizeResult)*2048ULL) );
 
   cleanup();
 
--- trunk/extragear/multimedia/k3b/libk3b/projects/videodvd/k3bvideodvdimager.cpp #633750:633751
@@ -58,6 +58,20 @@
 
 void K3bVideoDvdImager::start()
 {
+  fixVideoDVDSettings();
+  K3bIsoImager::start();
+}
+
+
+void K3bVideoDvdImager::init()
+{
+  fixVideoDVDSettings();
+  K3bIsoImager::init();
+}
+
+
+void K3bVideoDvdImager::fixVideoDVDSettings()
+{
   // Video DVD defaults, we cannot set these in K3bVideoDvdDoc since they
   // will be overwritten in the burn dialog unless we create some K3bVideoDVDIsoOptions
   // class with different defaults. But since the whole Video DVD project is a hack we
@@ -70,13 +84,12 @@
   o.setCreateRockRidge(false); 
   o.setCreateUdf(true); 
   d->doc->setIsoOptions( o ); 
-
-  K3bIsoImager::start();
 }
 
 
 void K3bVideoDvdImager::calculateSize()
 {
+  fixVideoDVDSettings();
   K3bIsoImager::calculateSize();
 }
 
--- trunk/extragear/multimedia/k3b/libk3b/projects/videodvd/k3bvideodvdimager.h #633750:633751
@@ -39,6 +39,7 @@
 
  public slots:
   virtual void start();
+  virtual void init();
   virtual void calculateSize();
 
  protected:
@@ -51,6 +52,8 @@
   virtual void slotReceivedStderr( const QString& );
 
  private:
+  void fixVideoDVDSettings();
+
   class Private;
   Private* d;
 };
--- trunk/extragear/multimedia/k3b/libk3b/tools/k3bactivepipe.cpp #633750:633751
@@ -40,17 +40,20 @@
 
   void run() {
     kdDebug() << "(K3bActivePipe) started thread." << endl;
+    bytesRead = bytesWritten = 0;
     buffer.resize( 10*2048 );
     ssize_t r = 0;
-    ssize_t total = 0;
     while( ( r = m_pipe->read( buffer.data(), buffer.size() ) ) > 0 ) {
 
+      bytesRead += r;
+
       // write it out
       ssize_t w = 0;
       ssize_t ww = 0;
       while( w < r ) {
 	if( ( ww = m_pipe->write( buffer.data()+w, r-w ) ) > 0 ) {
 	  w += ww;
+	  bytesWritten += ww;
 	}
 	else {
 	  kdDebug() << "(K3bActivePipe) write failed." << endl;
@@ -58,10 +61,8 @@
 	  return;
 	}
       }
-
-      total += r;
     }
-    kdDebug() << "(K3bActivePipe) thread done: " << r << " (total bytes: " << total << ")" << endl;
+    kdDebug() << "(K3bActivePipe) thread done: " << r << " (total bytes read/written: " << bytesRead << "/" << bytesWritten << ")" << endl;
     close( closeWhenDone );
   }
 
@@ -115,6 +116,9 @@
   bool closeFdToWriteTo;
 
   QByteArray buffer;
+
+  Q_UINT64 bytesRead;
+  Q_UINT64 bytesWritten;
 };
 
 
@@ -237,3 +241,15 @@
     return false;
   return true;
 }
+
+
+Q_UINT64 K3bActivePipe::bytesRead() const
+{
+  return d->bytesRead;
+}
+
+
+Q_UINT64 K3bActivePipe::bytesWritten() const
+{
+  return d->bytesWritten;
+}
--- trunk/extragear/multimedia/k3b/libk3b/tools/k3bactivepipe.h #633750:633751
@@ -99,6 +99,16 @@
    */
   int out() const;
 
+  /**
+   * The number of bytes that have been read.
+   */
+  Q_UINT64 bytesRead() const;
+
+  /**
+   * The number of bytes that have been written.
+   */
+  Q_UINT64 bytesWritten() const;
+
  protected:
   /**
    * Reads the data from the source.
--- trunk/extragear/multimedia/k3b/libk3b/tools/k3bmd5job.cpp #633750:633751
@@ -204,6 +204,7 @@
 
     if( readSize <= 0 ) {
       //      kdDebug() << "(K3bMd5Job) reached max size of " << d->maxSize << ". Stopping." << endl;
+      emit debuggingOutput( "K3bMd5Job", QString("Reached max read of %1. Stopping after %2 bytes.").arg(d->maxSize).arg(d->readData) );
       stopAll();
       emit percent( 100 );
       jobFinished(true);
@@ -257,6 +258,7 @@
       }
       else if( read == 0 ) {
 	//	kdDebug() << "(K3bMd5Job) read all data. Total size: " << d->readData << ". Stopping." << endl;
+	emit debuggingOutput( "K3bMd5Job", QString("All data read. Stopping after %1 bytes.").arg(d->readData) );
 	stopAll();
 	emit percent( 100 );
 	jobFinished(true);
@@ -301,6 +303,7 @@
 
 void K3bMd5Job::stop()
 {
+  emit debuggingOutput( "K3bMd5Job", QString("Stopped manually after %1 bytes.").arg(d->readData) );
   stopAll();
   jobFinished( true );
 }

question:
how do I apply this SVN: like a patch?
I there something new after the path from #41 (19676) ?

> how do I apply this SVN: like a patch?
> I there something new after the path from #41 (19676) ?


just wait a little. rc7 will be out soon. And that will be the last.

Ok, I've tried with 12 DVD Data project, all of those finished succesfully :)
I think this time the verification bug is really fixed.
In case of future problems, i'll report ;)