abrt 1.0.3 detected a crash. backtrace ----- Summary: TB7b081b94 audio.py:92:seek_to:TypeError: unsupported operand type(s) for *: 'NoneType' and 'float' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/miro/frontends/widgets/gtk/customcontrols.py", line 98, in do_button_press_event self.move_slider_to_mouse(event.x, event.y) File "/usr/lib/python2.6/site-packages/miro/frontends/widgets/gtk/customcontrols.py", line 125, in move_slider_to_mouse wrappermap.wrapper(self).emit('moved', self.get_value()) File "/usr/lib/python2.6/site-packages/miro/signals.py", line 155, in emit if callback.invoke(self, args): File "/usr/lib/python2.6/site-packages/miro/signals.py", line 76, in invoke return self.func(obj, *(args + self.extra_args)) File "/usr/lib/python2.6/site-packages/miro/frontends/widgets/videobox.py", line 370, in on_slider_moved app.playback_manager.seek_to(new_time) File "/usr/lib/python2.6/site-packages/miro/frontends/widgets/playback.py", line 327, in seek_to self.player.seek_to(progress) File "/usr/lib/python2.6/site-packages/miro/frontends/widgets/gtk/audio.py", line 92, in seek_to time = self.get_total_playback_time() * position TypeError: unsupported operand type(s) for *: 'NoneType' and 'float' Local variables in innermost frame: position: 0.13768115942 self: <miro.frontends.widgets.gtk.audio.AudioPlayer object at 0x9dd35b0c> Attached file: cmdline component: Miro executable: /usr/bin/miro.real kernel: 2.6.31.9-174.fc12.i686.PAE package: Miro-2.5.4-1.fc12 uuid: 7b081b94
Created attachment 383196 [details] File: backtrace
Created attachment 383197 [details] File: cmdline
Please describe what you were doing at the time of the crash. We need to be able to reliably reproduce the error.
I've seen this issue pop up from time to time, but I've never been able to reproduce it reliably. I'll tweak the code to harden it some more for Miro 2.6, but it's likely we'll never be able to prove it's fixed or not fixed. Where does the cmdline attachment come from? That's a really screwy command line for Miro.
(In reply to comment #4) > I've seen this issue pop up from time to time, but I've never been able to > reproduce it reliably. I'll tweak the code to harden it some more for Miro > 2.6, but it's likely we'll never be able to prove it's fixed or not fixed. > > Where does the cmdline attachment come from? That's a really screwy command > line for Miro. I don't know, I think it's from the new version of abrt which provides info on the crash.
*** This bug has been marked as a duplicate of bug 569199 ***