Red Hat Bugzilla – Bug 487442
Miro pops up "internal error" when run with no .miro directory
Last modified: 2009-03-02 11:58:18 EST
Created attachment 333258 [details]
Description of problem:
When I move my .miro directory and then run miro, it pops up an "internal error" window.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mv .miro dotMiroOld
"internal error" window pops up
No "internal error" window.
output attached. Note that the program continued running after the error; I closed it manually. I can do it again and watch a video to make it crash, if you want.
Bug filed per request at https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2084
philiprhoades reported on the bodhi the following error, which looks very similar to this one:
With a new user and empty home dir and even though I think I had the right rpm before I also uninstalled Miro and did:
yum --enablerepo=updates-testing install Miro
but when I stopped a video playing I still got a crash - do you want me to mail the crash report lines somewhere?
Also, when I try to restart now I get:
2009-02-26 11:25:41,678 INFO Checking movies directory '/home/tst/Videos/Miro/'...
2009-02-26 11:25:41,708 ERROR xine_extractor cannot be found.
2009-02-26 11:25:41,712 WARNING Unknown startup error: Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/miro/startup.py", line 83, in wrapped
File "/usr/lib/python2.5/site-packages/miro/startup.py", line 230, in reconnect_downloaders
File "/usr/lib/python2.5/site-packages/miro/item.py", line 1467, in reconnect_downloaders
File "/usr/lib/python2.5/site-packages/miro/item.py", line 1261, in setup_links
File "/usr/lib/python2.5/site-packages/miro/moviedata.py", line 201, in requestUpdate
File "/usr/lib/python2.5/site-packages/miro/moviedata.py", line 90, in __init__
File "/usr/lib/python2.5/site-packages/miro/plat/utils.py", line 292, in movie_data_program_info
return app.renderer.movie_data_program_info(moviePath, thumbnailPath)
File "/usr/lib/python2.5/site-packages/miro/plat/renderers/xinerenderer.py", line 221, in movie_data_program_info
return ((path, movie_path, thumbnail_path), None)
UnboundLocalError: local variable 'path' referenced before assignment
2009-02-26 11:25:44,544 INFO Shutting down Downloader...
I suspect that this might be a platform-specific issue with x86_64. My guess is that the patch to put xine_extractor in /usr/libexec wasn't sufficient and only worked on i386.
I was only able to test on a i386 machine and it worked for me there.
seeing this same error on subsequent miro runs after the first successful upgrade from 1.2 (on x86_64).
[jaf@nano:0j:138h:0e:2.90MB xine-lib]$ rpm -qf /usr/libexec/xine_extractor
temporary workaround hack:
patch movie_data_program_info at the bottom of /usr/lib64/python2.5/site-packages/miro/plat/renderers/xinerenderer.py to forcefully return resources.path('/usr/libexec/xine_extractor')
I checked in a fix to that code so that it raises a NotImplementedError rather than kicking up an Internal Error:
That fix will be in Miro 2.0.2.
At some point after 2.0.2, I'll fix the code so that it's easier to change the location of the xine_extractor without having to skim through all the code. Sorry about that.
(In reply to comment #5)
> I checked in a fix to that code so that it raises a NotImplementedError rather
> than kicking up an Internal Error:
worked here on F10 i386
Work(In reply to comment #2)
> I suspect that this might be a platform-specific issue with x86_64. My guess is
> that the patch to put xine_extractor in /usr/libexec wasn't sufficient and only
> worked on i386.
> I was only able to test on a i386 machine and it worked for me there.
It might be the case. For some reason, my x86_64 machine defaults to using the Gstreamer backend, even after I moved ~/.miro out of the way, so I never noticed the xine_extractor bug.
Do we backport the change, or presumably 2.0.2 will be out soon enough?
(In reply to comment #7)
test on a i386 machine and it worked for me there.
> It might be the case. For some reason, my x86_64 machine defaults to using the
> Gstreamer backend, even after I moved ~/.miro out of the way, so I never
> noticed the xine_extractor bug.
> Do we backport the change, or presumably 2.0.2 will be out soon enough?
I'm backporting the patch now, and spinning a new update as it would be good to get more feedback quickly on bodhi in case there are yet more problems before 2.0.2... ;)
Miro-2.0-2.fc10 has been submitted as an update for Fedora 10.
(In reply to comment #9)
> Miro-2.0-2.fc10 has been submitted as an update for Fedora 10.
The upstream patch (now packaged in Miro-2.0-2) stops Miro from crashing due to an invalid path to xine_extractor, rather than fixing the path itself. This means that the still packaged /usr/lib/xine_extractor util is no longer being used, so any newly downloaded Miro videos will no longer have their media length and thumbnail metadata extracted.
(note: the xine_extractor path crash is completely unrelated to the xine-lib crash issue)(In reply to comment #9)
Hmm, looks like it might be easy to modify the existing patch to hardcode the new location to /usr/libexec/xine_extractor.
as suggested in comment #4 ... ;)
Miro-2.0-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update Miro'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2139
Miro-2.0-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.