Bug 137975

Summary: cannot burn correctly big files (regression!)
Product: [Applications] k3b Reporter: Maciej Pilichowski <bluedzins>
Component: Burning/HardwareAssignee: Sebastian Trueg <trueg>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: OpenSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: project for one large file (4GB)
debug output (real success, not k3b-fake)
log (incorrect burning)
0.12.17 real success log
creating iso log
Disables the usage of mkisofs parameters -biblio, -copyright, and -abstract

Description Maciej Pilichowski 2006-11-27 17:10:13 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    SuSE RPMs

0.12.17 -- no problems with 4GB files. This 1.0 preview -- I burned three disc (growisofs 7.0) and:
a) first was corrupted in the middle (burning failed
b) second was corrupted near closing the session
c) burned ok, verified ok, but I can use it at all -- when I put it in the drive there are some noises and no data 

ad.c) what k3b verified then?

It is simply DVDR burn, I put one 4GB file with RR format, nothing fancy.
Comment 1 Maciej Pilichowski 2006-11-27 17:12:58 UTC
1.0.pre2 to be exact.

ad.c) it says "I can use", there should be of course "I cannot use"

btw. (b) and (c) make the same noises :-) when putting them into drive to get anything from the disc.
Comment 2 Sebastian Trueg 2006-11-28 21:15:07 UTC
Please try 1.0beta1
Comment 3 Maciej Pilichowski 2006-12-02 17:41:27 UTC
I don't have data for DVDR, but I just tested 1.0beta1 with DVDRW.

2.7GB in one file. The disc is not empty, but I just to overwrite data. Normally I just dragged the file to the file-pane and burn it. Now:
a) with auto-mode k3b says (after burning!) the data does not fit on disc (it is true, but I don't want to append anything)
b) when I say explicitly "no multisession" I am unable to burn at all "/dev/sr1 cannot be umounted, in use" -- but only k3b uses this drive

I will test DVDR ASAP.
Comment 4 Sebastian Trueg 2006-12-03 16:07:04 UTC
Blame SuSE's subfs/submount. I cannot do anything about it. SuSE 10.2 does not contain it anymore AFAIK. K3b 1.0 will warn about it again.
Comment 5 Maciej Pilichowski 2006-12-03 18:04:20 UTC
? Sebastian, I didn't change Suse version, I changed k3b -- 0.12.17 works fine, pre2 does not, I didn't test beta1 with DVDR, so I don't understand closing with wontfix.
Comment 6 Sebastian Trueg 2006-12-03 19:06:50 UTC
because you describe the exact situation in which k3b cannot unmount and since you are running suse... I thought you were also using submount. Please correct me if I am wrong. 0.12.17 cannot handle submount either.
Comment 7 Maciej Pilichowski 2006-12-04 11:20:47 UTC
The point is I didn't change suse, and as I pointed out in #0 -- 0.12.17 burned DVDR ok. Pre2 does not.

I was to eager to check the big files than I testes DVDRW (#3) forgetting they behaves differently. So sorry for making a mess, #0 stays valid, #3 not.

How should I check what I use?
ps ax | grep mount
gives nothing. No matter what I use pre2 burned actually the disc (2 of 3) but not correctly. If it would be a problem with mounting it is just at start (and 0.12.17 would fail too). 
Comment 8 Sebastian Trueg 2006-12-04 13:32:32 UTC
On Monday 04 December 2006 11:20, Maciej Pilichowski wrote:
> The point is I didn't change suse, and as I pointed out in #0 -- 0.12.17
> burned DVDR ok. Pre2 does not.


forget pre2. and dvdr is of no interest. it will never be mounted before 
burning.

> How should I check what I use?


less /etc/fstab
Comment 9 Maciej Pilichowski 2006-12-04 14:50:28 UTC
> forget pre2.

Ok, so I post here comment when I test beta1 with the big file (currently I don't have anything to burn).


> > How should I check what I use? 
> less /etc/fstab 

I better include line for burner because for me is just normal fstab.

/dev/disk/by-id/usb-_NEC_DVD_RW_ND-3540A	/media/cdrecorder	subfs	user,noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
Comment 10 Sebastian Trueg 2006-12-04 17:03:11 UTC
On Monday 04 December 2006 14:50, Maciej Pilichowski wrote:
> /dev/disk/by-id/usb-_NEC_DVD_RW_ND-3540A	/media/cdrecorder	subfs	user,noaut
>o,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0


like I said: stupid subfs. There is nothing I can do. subfs is simply bad 
design.
Comment 11 Maciej Pilichowski 2006-12-04 20:27:26 UTC
Ok, opensuse 10.2 will be released soon and I am going to upgrade (hope it is fixed). But nevertheless -- as you said (as I understood you :-)) ) subfs has nothing to do with DVDR, so if I test it against beta1, I could reopen this report, right?
Comment 12 Sebastian Trueg 2006-12-04 21:53:06 UTC
On Monday 04 December 2006 20:27, Maciej Pilichowski wrote:
> Ok, opensuse 10.2 will be released soon and I am going to upgrade (hope it
> is fixed). But nevertheless -- as you said (as I understood you :-)) )
> subfs has nothing to do with DVDR, so if I test it against beta1, I could
> reopen this report, right?


yes.
Comment 13 Maciej Pilichowski 2006-12-23 09:58:18 UTC
Ok, let's get back to this one -- the same system, same hardware, the only difference is k3b. RC2 vs. 0.12.17.

Burning of one large file -- 4GB. The same as the report.

RC2:
a) disc burned, error while checking
b) disc ~burned, k3b crash (infitive loop -- bug really), I cannot give any details, because on infinitive loop k3b does not refresh GUI, so it was when closing session, or near starting verifying it
c) burning without verify, burned

ad.all) after burning there was no file on disc, so I don't really believe in this error in (a), to have an error you have to have something, and since there is no file, what k3b checked?

0.12.17:
a) disc burned, failed to switch verification (for the first time) with strange message saying that without RR it is unable to verify, ok, I manually verified the disc, everything is ok.

So for now:
RC2: 6 discs, 100% failure, 0% success
0.12.17: 2 discs (plus ~40 before this report), 0% failure, 100% success

This file is all the time burned via project file, so I will attach it in a moment.

There is one thing though, k3b -- growisofs really -- displays info about mounting disc with such big file that I should use udf mode. I don't use it (subfs) I just mount the disc. For all disc burned with 0.12.17 (again, ~40 discs) it just works. So I expect I don't have to do anything extra for disc burned with RC2.
Comment 14 Maciej Pilichowski 2006-12-23 10:18:57 UTC
Created attachment 19014 [details]
project for one large file (4GB)

Maybe that will give some hints.
Comment 15 Sebastian Trueg 2006-12-23 12:01:14 UTC
rc2 is already deprecated. dvd verification in svn is fixed.
Comment 16 Maciej Pilichowski 2006-12-23 12:38:40 UTC
Ok, for next testing I will download source from svn, but I am not talking about verification, but reliable burning (as more important thing).
Comment 17 Sebastian Trueg 2006-12-31 00:32:28 UTC
Any news on this one?
Comment 18 Maciej Pilichowski 2006-12-31 14:49:21 UTC
Bad one:
a) disc burned, crash on verify, however k3b recognized the label
b) disc burned, verified

None of them I could mount and read after, which is surprising that k3b was able to verify (b). There is one disturbing issue -- when I put such disc (a or b) into the drive it makes some un-funny noises, like cracking or something, and after 
mount /media/dvd
I get there is no media in the drive.

Discs burned with 0.12.17 make :-))) wshhhh noise, only spinning (speeding up the disc). Of course I can mount them and read.

ad.b) judging from noises verification was in x4 speed, because drive was really quiet, with 0.12.17 it is noisy as hell, because it speeds up I guess to x16 (to max. read, not write, speed)

I will test DVDRW in a second (I no longer use subfs).
Comment 19 Maciej Pilichowski 2006-12-31 17:42:12 UTC
Surprise, DVDRW works. The only difference I can see, RW is x4 speed, and R is from x8-x4 (info from k3b while burning). So maybe 0.12.17 did better job detecting speed and keeping it stable?
Comment 20 Sebastian Trueg 2007-01-03 16:37:27 UTC
Any news on this one? Again: I don't understand the problem.
Comment 21 Maciej Pilichowski 2007-01-03 19:49:11 UTC
Hell of the party at NYE it must have been :-D The bug was clear to you till now :-)

The problem is (in short) that k3b 0.12.17 is 100% reliable while burning single big file (4GB) and all newer version are 99% unreliable (1% goes for breaktrough with DVDRW and RC3).
Comment 22 Sebastian Trueg 2007-01-03 23:31:32 UTC
Do you have debugging output from a failed burn, please?
Comment 23 Maciej Pilichowski 2007-01-04 10:24:35 UTC
Nope. But I will burn disc soon and send the data. So in any case, what output you have in mind (just running k3b from console)?
Comment 24 Sebastian Trueg 2007-01-04 15:01:38 UTC
I need the debugging output K3b provides at the end of each operation. Use the "debugging output" button in the progress dialog.
Comment 25 Maciej Pilichowski 2007-01-04 19:39:17 UTC
To be sure the debug info will kick in, I recompile k3b with k3b debug option. And... this time (for the first time) it worked.

About speed, the disc is x16, recognized speed x16, used speed around ~x4. But I doubt it is the issue because it happened before with RC3 (without k3b-debug-option).
Comment 26 Maciej Pilichowski 2007-01-04 19:41:03 UTC
Created attachment 19105 [details]
debug output (real success, not k3b-fake)
Comment 27 Sebastian Trueg 2007-01-05 00:31:42 UTC
well, I cannot really do anything with a successful burn, right? ;)
Comment 28 Maciej Pilichowski 2007-01-05 16:11:15 UTC
I know :-) I will try to break something really soon :-D
Comment 29 Maciej Pilichowski 2007-01-18 12:04:32 UTC
One disc burned, verified -- unreadable. 
Second disc burned, I skipped verification -- seems to be just fine.

But... I forgot that k3b can positively verify disc and disc is still no use, and thus I forgot to save the log :-( Gosh, sorry...
Comment 30 Maciej Pilichowski 2007-02-13 15:38:19 UTC
Created attachment 19662 [details]
log (incorrect burning)

disc burned "successfully", verified "successfully" -> real verification showed
the disc is unreadable
btw. I guess both logs are identical
Comment 31 Maciej Pilichowski 2007-02-13 16:26:30 UTC
Created attachment 19664 [details]
0.12.17 real success log
Comment 32 Maciej Pilichowski 2007-02-13 16:29:04 UTC
So, today results:
1RC6 -> 2 discs -> burnt ok -> verified ok -> both disc are unreadable

0.12.17 -> 1 disc -> burnt ok -> verified ok -> it is really working fine

I attached logs from RC6 failure (I mean real, for k3b it is success) and 0.12.17 success log. Maybe there is some important difference (btw. what I meant before about being identical that RC5 real-success and RC6 fake-success logs are identical).
Comment 33 Sebastian Trueg 2007-02-13 16:38:46 UTC
It would be great if I could get my hands on one of those DVDs.
Comment 34 Sebastian Trueg 2007-02-13 16:43:06 UTC
Try just creating an image with K3b 1.0rc6 and burn that to a DVD. Before you may check if the image is valid using isoinfo.
Comment 35 Maciej Pilichowski 2007-03-12 10:43:30 UTC
I have more space on disk so I did some test.

I created two isos -- one with 1rc6 and one with 0.12.17. And then I burned them, but using the other version. Effects:

a) iso files differs
b) 1rc6 cannot correctly make iso file
c) 1rc6 can burn correctly correctly prepared iso file

So the title of this report should really says, that 1.x version cannot make iso files! And here lies regression from 0.12.17.
Comment 36 Sebastian Trueg 2007-03-12 11:04:39 UTC
What is wrong with the iso?
Please provide debugging output from both attempts to create the image.
Without this information I cannot do anything.
Comment 37 Maciej Pilichowski 2007-03-12 12:58:57 UTC
> What is wrong with the iso? 

I don't know, but if you try to burn it you will get unreadable (except for k3b verification) disc (the same you have :-) ).

Creating the iso is successful (i.e. k3b thinks it is ok).
Comment 38 Maciej Pilichowski 2007-03-12 13:23:43 UTC
Created attachment 19942 [details]
creating iso log
Comment 39 Maciej Pilichowski 2007-03-12 13:24:51 UTC
Btw. RC6 "kills" the system with creating iso. Long after creating the iso file there is no response from the system, only HDD works like crazy. No such thing with 0.12.17.
Comment 40 Sebastian Trueg 2007-03-12 19:09:36 UTC
I could not mount the DVD either. However, I was able to extract the image up to 93% and that image is mountable and contains the file dictionary.db. So it seems that the image is not completely screwed. This is very weird. The only difference I could make out in the logs is the usage of the mkisofs parameters
"-abstract", "-copyright", and "-biblio".
So the only test I can think of is disabling these and see what happens. I will create a patch.

BTW: The verification works since the image is written properly. That it cannot be mounted is another problem which is not tested during verification.
Comment 41 Sebastian Trueg 2007-03-12 19:11:31 UTC
Created attachment 19949 [details]
Disables the usage of mkisofs parameters -biblio, -copyright, and -abstract
Comment 42 Maciej Pilichowski 2007-03-12 19:47:21 UTC
> This is very weird. 

I guess it takes only creating 4GB file and test rc6 and 0.12.17 to see the difference.

> So the only test I can think of is disabling these and see what happens. I
> will create a patch.

Does k3b adds some info ("iso created by...") to the iso file? If yes, I have to wait till I have some something to burn.
 
> BTW: The verification works since the image is written properly. That it 
> cannot be mounted is another problem which is not tested during
> verification. 

? Sounds strange. Note how burning and verification goes:
1) k3b burns the disc
2) k3b ejects ! the disc
3) k3b gets the disc back
4) is this disc mounted?
5) k3b verifies the disc? or the burned file?

(4) seems strange here, how k3b is able to get to the content of the disc and the user (me :-) ) cannot? 
I cannot, because I cannot even mount the disc, in the same drive which k3b used to verify it.
 
 
Comment 43 Sebastian Trueg 2007-03-12 20:24:02 UTC
> 4) is this disc mounted?


no, never, the burned data is compared, not the filesystem.

> 5) k3b verifies the disc? or the burned file?
>
> (4) seems strange here, how k3b is able to get to the content of the disc
> and the user (me :-) ) cannot? I cannot, because I cannot even mount the
> disc, in the same drive which k3b used to verify it.


Note that there is a difference between accessing the data on the DVD and the 
filesystem which is supposed to be part of the data.
Comment 44 Maciej Pilichowski 2007-03-12 21:52:00 UTC
Sebastian, I think it is not reliable then. If users burn project with two files, the files itself should be verified so the disc should be mounted etc. but if you burn the iso file, the steps as you described should be taken.

So, verify should vary depending what you are burning.
Comment 45 Sebastian Trueg 2007-03-13 09:16:15 UTC
> Sebastian, I think it is not reliable then. If users burn project with two
> files, the files itself should be verified so the disc should be mounted
> etc. but if you burn the iso file, the steps as you described should be
> taken.


That is what I did before but it was not reliable at all due to all the 
charset problems I could never solve. Anyway there is no difference since the 
data has to be the same anyway.

> So, verify should vary depending what you are burning.

Comment 46 Maciej Pilichowski 2007-03-13 10:12:18 UTC
> Anyway there is no difference since the  data has to be the same anyway. 

But you saw by yourself there _is_ difference. This whole report-thread is about this -- each time k3b verified data but yet the disc was unreadable. Each time k3b "lied" verifying the disc and saying it was ok -- note, that I manually reverified it -- if I didn't I would end up having a pile of corrupted discs. And now think about making backups using k3b...

If k3b mounted disc and verified _file_ instead of the image verification would fail! And that is expected behaviour.
Comment 47 Sebastian Trueg 2007-03-13 10:29:29 UTC
> > Anyway there is no difference since the  data has to be the same anyway.
>
> But you saw by yourself there _is_ difference. This whole report-thread is
> about this -- each time k3b verified data but yet the disc was unreadable.
> Each time k3b "lied" verifying the disc and saying it was ok -- note, that
> I manually reverified it -- if I didn't I would end up having a pile of
> corrupted discs. And now think about making backups using k3b...


Actually K3b verified what it wrote. That is what verification is meant to be. 
If the image creation is faulty that is another issue.

> If k3b mounted disc and verified _file_ instead of the image verification
> would fail! And that is expected behaviour.


I won't get into this again: I was not able to make it work. If you can do it, 
please be my guest.
Comment 48 Maciej Pilichowski 2007-03-13 10:46:51 UTC
> Actually K3b verified what it wrote. That is what verification is meant to
> be. 

From users point of view there is input (I) and result (R). And this is all about
I -> R

You cannot (*) state that you have process
I -> A -> B -> C -> R
and you really check integrity of B -> R instead of I -> R. Except for you nobody sees those A B and C.

(*) technically you can, but this is not the point

> I won't get into this again: I was not able to make it work. 

So it is better to disable it. K3b now works with unreliable "feature" without even warning user that k3b does not verify input with output, but only mid-data with output. 

You can of course insist it is a feature not a bug, but it does not change a thing -- without I->R verification it is completely useless and the only chance you can be sure you have the correct data on disc is to do it by yourself.
Comment 49 Sebastian Trueg 2007-03-13 10:55:00 UTC
> So it is better to disable it. K3b now works with unreliable "feature"
> without even warning user that k3b does not verify input with output, but
> only mid-data with output.


You are the only one having this problem and I have no idea what it is. Could 
you please be supportive and try the patch.

> You can of course insist it is a feature not a bug, but it does not change
> a thing -- without I->R verification it is completely useless and the only
> chance you can be sure you have the correct data on disc is to do it by
> yourself.


Again: show me the proper way to do it and I will. Until then, verification 
will work as it does now and I will not disable it but try to find the bug.
And please don't tell me to mount and compare the files. That is simply not 
feasible. There simply is no way ATM to have a reliable mapping from the 
files in the project to the files created my mkisofs in the image.
Comment 50 Maciej Pilichowski 2007-03-13 11:45:55 UTC
> You are the only one having this problem and I have no idea what it is.

Have you tried to create 4GB iso file?

> Could you please be supportive and try the patch. 

I answered this one I guess.

> Again: show me the proper way to do it and I will. Until then, verification 
> will work as it does now and I will not disable it but try to find the bug. 

In other words you prefer to misinform users instead of showing at least warning that it is not real verification.

Enough of this -- I think I am wasting my time here, either you care about quality or not. 
Comment 51 Sebastian Trueg 2007-03-13 12:22:58 UTC
> > Could you please be supportive and try the patch.
>
> I answered this one I guess.


Don't you have a rewritable DVD that you can use to test it with some bogus 
data?

> Enough of this -- I think I am wasting my time here, either you care about
> quality or not.


yes, let's end this.
Comment 52 Maciej Pilichowski 2007-03-13 13:41:39 UTC
> Don't you have a rewritable DVD that you can use to test it with some bogus 
>  data? 

I have. And I have written some time ago, and you confirmed that :-), that RW discs behaves differently. In other words burning RW disc is ok.

But if you think it will help track the bug, please let me know, I will do the test.
Comment 53 Sebastian Trueg 2007-03-13 13:48:18 UTC
> > Don't you have a rewritable DVD that you can use to test it with some
> > bogus data?
>
> I have. And I have written some time ago, and you confirmed that :-), that
> RW discs behaves differently. In other words burning RW disc is ok.


ah, right, I forgot about that.
Comment 54 Maciej Pilichowski 2007-03-19 17:49:18 UTC
Good news, I think, of course it could be just good luck, but 1.0 with patch was able to burn the disc correctly. I will do more tests, but not soon (I don't have any data to burn right now).
Comment 55 Maciej Pilichowski 2007-03-21 16:03:05 UTC
this time I tested rc6 with patch. Another successful burn -- I think you can apply the patch to the source.
Comment 56 Sebastian Trueg 2007-03-21 16:48:22 UTC
SVN commit 645043 by trueg:

Do only set the bibliography, the abstract, and the copyright file if they are specified by the user.
It seems that setting an invalid one can cause the resulting image to be bogus. Thus, future versions of K3b
should check if the files actually exist in the image and maybe provide a file selector instead of the simple
line edit.

BUG: 137975


 M  +2 -0      ChangeLog  
 M  +35 -32    libk3b/projects/datacd/k3bisoimager.cpp  


--- trunk/extragear/multimedia/k3b/ChangeLog #645042:645043
@@ -8,6 +8,8 @@
  * Fixed DVD copy when reading from a DVD+RW.
  * Fixed --without-alsa configure check
  * Fixed a crash in Video DVD ripping when the title does not contain an audio stream
+ * Only use the mkisofs parameters -biblio, -copyright, and -abstract if they have been set. Using them
+   with invalid values (empty) seems to result in broken iso images sometimes.
 
 1.0
 ===
--- trunk/extragear/multimedia/k3b/libk3b/projects/datacd/k3bisoimager.cpp #645042:645043
@@ -163,7 +163,7 @@
 
   d->pipe->close();
 
-  emit debuggingOutput( "K3bIsoImager", 
+  emit debuggingOutput( "K3bIsoImager",
 			QString("Pipe throughput: %1 bytes read, %2 bytes written.")
 			.arg(d->pipe->bytesRead()).arg(d->pipe->bytesWritten()) );
 
@@ -295,19 +295,19 @@
     jobFinished( false );
     return;
   }
-    
+
   initVariables();
 
-  delete m_process;    
+  delete m_process;
   m_process = new K3bProcess();
   m_process->setRunPrivileged(true);
   m_process->setSplitStdout(true);
-    
+
   emit debuggingOutput( "Used versions", "mkisofs: " + d->mkisofsBin->version );
-    
+
   *m_process << d->mkisofsBin;
 
-  if( !prepareMkisofsFiles() || 
+  if( !prepareMkisofsFiles() ||
       !addMkisofsParameters(true) ) {
     cleanup();
     jobFinished( false );
@@ -346,7 +346,7 @@
 	   this, SLOT(slotCollectMkisofsPrintSizeStdout(const QString&)) );
   connect( m_process, SIGNAL(processExited(KProcess*)),
 	   this, SLOT(slotMkisofsPrintSizeFinished()) );
-  
+
   // we also want error messages
   connect( m_process, SIGNAL(stderrLine( const QString& )),
 	   this, SLOT(slotReceivedStderr( const QString& )) );
@@ -408,7 +408,7 @@
       m_mkisofsPrintSizeResult = m_collectedMkisofsPrintSizeStderr.mid( pos+33 ).toInt( &success );
   }
 
-  emit debuggingOutput( "K3bIsoImager", 
+  emit debuggingOutput( "K3bIsoImager",
 			QString("mkisofs print size result: %1 (%2 bytes)")
 			.arg(m_mkisofsPrintSizeResult)
 			.arg(Q_UINT64(m_mkisofsPrintSizeResult)*2048ULL) );
@@ -527,7 +527,7 @@
   }
   kdDebug() << s << endl << flush;
   emit debuggingOutput("mkisofs command:", s);
-  
+
   if( !m_process->start( KProcess::NotifyOnExit, KProcess::AllOutput) ) {
     // something went wrong when starting the program
     // it "should" be the executable
@@ -600,39 +600,42 @@
   QString s = m_doc->isoOptions().volumeSetId();
   truncateTheHardWay(s, 128);  // ensure max length
   *m_process << "-volset" << s;
-  
+
   s = m_doc->isoOptions().applicationID();
   truncateTheHardWay(s, 128);  // ensure max length
   *m_process << "-appid" << s;
-  
+
   s = m_doc->isoOptions().publisher();
   truncateTheHardWay(s, 128);  // ensure max length
   *m_process << "-publisher" << s;
-  
+
   s = m_doc->isoOptions().preparer();
   truncateTheHardWay(s, 128);  // ensure max length
   *m_process << "-preparer" << s;
-  
+
   s = m_doc->isoOptions().systemId();
   truncateTheHardWay(s, 32);  // ensure max length
   *m_process << "-sysid" << s;
-  
+
   s = m_doc->isoOptions().abstractFile();
   truncateTheHardWay(s, 37);  // ensure max length
-  *m_process << "-abstract" << s;
+  if ( !s.isEmpty() )
+      *m_process << "-abstract" << s;
 
   s = m_doc->isoOptions().copyrightFile();
   truncateTheHardWay(s, 37);  // ensure max length
-  *m_process << "-copyright" << s;
+  if ( !s.isEmpty() )
+      *m_process << "-copyright" << s;
 
   s = m_doc->isoOptions().bibliographFile();
   truncateTheHardWay(s, 37);  // ensure max length
-  *m_process << "-biblio" << s;
+  if ( !s.isEmpty() )
+      *m_process << "-biblio" << s;
 
   int volsetSize = m_doc->isoOptions().volumeSetSize();
   int volsetSeqNo = m_doc->isoOptions().volumeSetNumber();
   if( volsetSeqNo > volsetSize ) {
-    kdDebug() << "(K3bIsoImager) invalid volume set sequence number: " << volsetSeqNo 
+    kdDebug() << "(K3bIsoImager) invalid volume set sequence number: " << volsetSeqNo
 	      << " with volume set size: " << volsetSize << endl;
     volsetSeqNo = volsetSize;
   }
@@ -678,7 +681,7 @@
   if( filesGreaterThan2Gb )
     emit infoMessage( i18n("Found files bigger than 2 GB. These files will only be fully accessible if mounted with UDF."),
 		      WARNING );
-  
+
   bool udf = m_doc->isoOptions().createUdf();
   if( !udf && filesGreaterThan2Gb ) {
     emit infoMessage( i18n("Enabling UDF extension."), INFO );
@@ -850,13 +853,13 @@
       // that contain one or more backslashes
       if( item->writtenPath().contains("\\") )
 	m_containsFilesWithMultibleBackslashes = true;
-      
-      
+
+
       if( item->isDir() ) {
 	stream << escapeGraftPoint( item->writtenPath() )
 	       << "="
 	       << escapeGraftPoint( dummyDir( static_cast<K3bDirItem*>(item) ) ) << "\n";
-	
+
 	int x = writePathSpecForDir( dynamic_cast<K3bDirItem*>(item), stream );
 	if( x >= 0 )
 	  num += x;
@@ -877,21 +880,21 @@
 {
   stream << escapeGraftPoint( item->writtenPath() )
 	 << "=";
-  
+
   if( m_doc->bootImages().containsRef( dynamic_cast<K3bBootItem*>(item) ) ) { // boot-image-backup-hack
-    
+
     // create temp file
     KTempFile temp;
     QString tempPath = temp.name();
     temp.unlink();
-    
+
     if( !KIO::NetAccess::copy( KURL(item->localPath()), KURL::fromPathOrURL(tempPath) ) ) {
       emit infoMessage( i18n("Failed to backup boot image file %1").arg(item->localPath()), ERROR );
       return;
     }
-    
+
     static_cast<K3bBootItem*>(item)->setTempPath( tempPath );
-    
+
     m_tempFiles.append(tempPath);
     stream << escapeGraftPoint( tempPath ) << "\n";
   }
@@ -971,8 +974,8 @@
 	  *t << escapeGraftPoint( static_cast<K3bBootItem*>(item)->tempPath() ) << " " << item->sortWeight() << endl;
 	}
 	else if( item->isDir() ) {
-	  // 
-	  // Since we use dummy dirs for all directories in the filesystem and mkisofs uses the local path 
+	  //
+	  // Since we use dummy dirs for all directories in the filesystem and mkisofs uses the local path
 	  // for sorting we need to create a different dummy dir for every sort weight value.
 	  //
 	  *t << escapeGraftPoint( dummyDir( static_cast<K3bDirItem*>(item) ) ) << " " << item->sortWeight() << endl;
@@ -1002,16 +1005,16 @@
   // while single backslashes at the end of a filename need to be escaped
   // with two backslashes.
   //
-  // There is one more problem though: the name in the iso tree can never 
+  // There is one more problem though: the name in the iso tree can never
   // in any number of backslashes. mkisofs simply cannot handle it. So we
-  // need to remove these slashes somewhere or ignore those files (we do 
+  // need to remove these slashes somewhere or ignore those files (we do
   // that in K3bDataDoc::addUrls)
   //
 
   //
   // we do not use QString::replace to have full control
   // this might be slow since QString::insert is slow but we don't care
-  // since this is only called to prepare the iso creation which is not 
+  // since this is only called to prepare the iso creation which is not
   // time critical. :)
   //