Description of problem: Unless given an absolute pathname for the lame encoder, grip freezes Version-Release number of selected component (if applicable): grip-3.2.0-16.fc7 How reproducible: Every time Steps to Reproduce: 1. open Grip 2. in the menu, go to "Config" > "Encode" > "Encoder" 3. in the "encoder executable" field, specify anything other than the full path of the lame executable; i.e., don't put "/usr/bin/lame" 4. in the menu go to "Rip" 5. click "Rip+Encode" Actual results: Grip freezes Expected results: Grip should rip the CD to mp3 format as usual Additional info: In Fedora's Grip, the default path is just "lame" instead of "/usr/bin/lame". This triggers this bug.
Looks like an Ubuntu user filed a report upstream on 2006-12-03: http://sourceforge.net/tracker/index.php?func=detail&aid=1608041&group_id=3714&atid=103714
I can confirm the bug report from the ubuntu user but I cannot confirm your report that it freezes. I just get a simple box telling me it cannot find the executable. I am not 100% sure this needs to be fixed because the text entry is supposed to hold the "Encoder executable" and it could be argued that this has to include the full path. It is not too much effort to write a small patch to fix this behaviour but I am not yet sure that it should do it. If I start grip without any existing configuration files it defaults to /usr/bin/lame for lame and not to just lame like you said. If you change it once it will stay that way.
(In reply to comment #2) > I can confirm the bug report from the ubuntu user but I cannot confirm your > report that it freezes. I just get a simple box telling me it cannot find the > executable. Odd, it still freezes on me. I've tried the --verbose flag, but it doesn't give me anything out of the ordinary. If this freeze is non-reproducible, I'll try to troubleshoot this elsewhere. > I am not 100% sure this needs to be fixed because the text entry is supposed to > hold the "Encoder executable" and it could be argued that this has to include > the full path. It is not too much effort to write a small patch to fix this > behaviour but I am not yet sure that it should do it. > > If I start grip without any existing configuration files it defaults to > /usr/bin/lame for lame and not to just lame like you said. If you change it once > it will stay that way. I've tracked down the problem; I installed and ran grip before I installed lame. gripcfg.c's FindExeInPath() function couldn't find lame, so it defaulted to just exename. I guess this is the safest option, particularly when lame RPM is not in the official repos. Thanks for the help Adrian.
Even if you closed the bug I will release a new version with a patch the finds the executable. I have just put FindExeInPath() in the function that does the actual ripping and it will find any executable if it is in $PATH.