Writing dialog hangs after gobject.GError from nautilusburn.Recorder

[Martijn Vermaat]

After writing seems (and is) successful, the tray opens and the writing dialog
hangs with state "fixating disc".

The commandline shows:
---
  Traceback (most recent call last):
    File "/usr/lib/python2.4/site-packages/serpentine/recording.py", line 257,
in __thread
      self.preferences.writeFlags)
  gobject.GError: The system is too slow to write the CD at this speed. Try a
lower speed.
---

I think nautilusburn.Recorder is throwing this gobject.GError which is not
handled by Serpentine, causing the thread to hang. This is especially annoying
since any temporary created cache files are not removed.

I don't have enough Serpentine power to implement a good fix, but I think a
simple try/except around the Recorder call in recording.py at line 257 could go
a long way.

Steps to reproduce: Burn any content with Serpentine at a speed your computer
can't hold up with. Try an old computer with a fast cdr, or stress your
harddrive while writing the disc. After the writing is complete, Serpentine
should hang with the message "fixating disc".

PS: Maybe similar GError's could occur in the same location, I don't know.

[Daniel Holbach (dholbach)]

Might this be related to http://bugzilla.ubuntu.com/show_bug.cgi?id=13484?

[Tiago Cogumbreiro (cogumbreiro)]

Yes, this is an easy fix. It's exactly what you've said, I wasn't aware of that
exception, an error dialog should be shown to the user.

I'll try to attend to this bug tomorrow.

However I don't think it's related to bug 19727

[Martijn Vermaat (mvermaat)]

Created an attachment (id=4489)
Simple patch for catching the exception

This is a naive patch for this problem, but at least it keeps the writing
dialog from hanging.

(I did not test the patch!)

I really think we should try to fix this problem in Breezy if that's still
possible, on Ubuntu forums I saw several people affected by this bug. It's
confusing the user.

[Tiago Cogumbreiro (cogumbreiro)]

I'll try to address that problem. However your patch misses one point since it
should be operations.ERROR instead of nautilisburn.RECORDER_RESULT_ERROR

But thanks anyways. I wasn't aware this error affected so many people.

[Martijn Vermaat (mvermaat)]

Actually, I thought it was more appropriate to use
nautilisburn.RECORDER_RESULT_ERROR here. It will be set to operations.ERROR in
the next few lines.

Because consider what happens if the integer value of operations.ERROR happens
to be the same as that of nautilusburn.RECORDER_RESULT_FINISHED. I don't know if
that's the case, but I guess it could be?

Anyway, maybe a real patch should do a little more than my quick hack, so I'll
leave that to you. Thanks for the fine program and for looking at this bug!

I should also add that the problem occured for me on a Athlon 800Mhz with a
Plextor 52x burner. Considering dma is turned off by default in Ubuntu and
Serpentine defaults to the maximum writing speed I think that explains why more
people are experiencing this.

[Tiago Cogumbreiro (cogumbreiro)]

(In reply to comment #5)
> Actually, I thought it was more appropriate to use
> nautilisburn.RECORDER_RESULT_ERROR here. It will be set to operations.ERROR in
> the next few lines.
>
> Because consider what happens if the integer value of operations.ERROR happens
> to be the same as that of nautilusburn.RECORDER_RESULT_FINISHED. I don't know if
> that's the case, but I guess it could be?
It's not a matter of what's appropriate but of how things are structured.
When an operation is finished correctly you should use operations.SUCCESSFUL
(have a glance at operations.py),
when it's aborted operations.STOP and when something goes wrong
operations.ERROR, so you never get nautilusburn.RERCORDER_RESULT_* there.

> Anyway, maybe a real patch should do a little more than my quick hack, so I'll
> leave that to you. Thanks for the fine program and for looking at this bug!
I'll attend at it right now :) And thank you very mutch for your patch and
attention!

> I should also add that the problem occured for me on a Athlon 800Mhz with a
> Plextor 52x burner. Considering dma is turned off by default in Ubuntu and
> Serpentine defaults to the maximum writing speed I think that explains why more
> people are experiencing this.
Yeah, I didn't thought of that. You're absolutely right.

[Tiago Cogumbreiro (cogumbreiro)]

(In reply to comment #6)
>> Actually, I thought it was more appropriate to use
>> nautilisburn.RECORDER_RESULT_ERROR here. It will be set to operations.ERROR in
>> the next few lines.
>>
>> Because consider what happens if the integer value of operations.ERROR happens
>> to be the same as that of nautilusburn.RECORDER_RESULT_FINISHED. I don't know if
>> that's the case, but I guess it could be?
> It's not a matter of what's appropriate but of how things are structured.
> When an operation is finished correctly you should use operations.SUCCESSFUL
(have a glance at operations.py),
> when it's aborted operations.STOP and when something goes wrong
operations.ERROR, so you never get nautilusburn.RERCORDER_RESULT_* there.

Ignore that, your patch was right, last time I review a patch halp sleeping :(

I'm really sorry about that confusion.

[Tiago Cogumbreiro (cogumbreiro)]

I've fixed it in SVN, it will be included in the next release.

[Tiago Cogumbreiro (cogumbreiro)]

Fixed in Serpentine 0.6.4

[Sebastien Bacher (seb128)]

This upload fixes the issue:

 serpentine (0.6.4-0ubuntu1) dapper; urgency=low
 .
   * New upstream version:
     - the save playlist dialog now displays the save format (Ubuntu: #18643).
     - fix a crash happening after ejecting the CD (Ubuntu: #16860).