Created attachment 333258 [details] miro output 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): Miro-2.0-1.fc10.x86_64 How reproducible: always Steps to Reproduce: 1. mv .miro dotMiroOld 2. miro Actual results: "internal error" window pops up Expected results: No "internal error" window. Additional info: 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 func(*args, **kwargs) File "/usr/lib/python2.5/site-packages/miro/startup.py", line 230, in reconnect_downloaders item.reconnect_downloaders() File "/usr/lib/python2.5/site-packages/miro/item.py", line 1467, in reconnect_downloaders item.setup_links() File "/usr/lib/python2.5/site-packages/miro/item.py", line 1261, in setup_links moviedata.movieDataUpdater.requestUpdate (self) File "/usr/lib/python2.5/site-packages/miro/moviedata.py", line 201, in requestUpdate self.queue.put(MovieDataInfo(item)) File "/usr/lib/python2.5/site-packages/miro/moviedata.py", line 90, in __init__ fileutil.expand_filename(self.videoPath), fileutil.expand_filename(self.thumbnailPath)) 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 Miro-2.0-1.fc10.x86_64
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: https://develop.participatoryculture.org/trac/democracy/changeset/9243 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. http://admin.fedoraproject.org/updates/Miro-2.0-2.fc10
(In reply to comment #9) > Miro-2.0-2.fc10 has been submitted as an update for Fedora 10. > http://admin.fedoraproject.org/updates/Miro-2.0-2.fc10 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.