first i don't know if it's a mp3tag or foo_run bug, but i put foo_run to open mp3tag and it doesn't open, it work with other programs, only mp3tag doesn't open...
thanks.
edit: forget to say, in windows 7 home premium 32bits it work perfectly, but in windows 7 ultimate 64bits this problem happens.
I had been struggling with this problem for a long time and thanks to this thread I tried escaping the parentheses in (x86) and it worked. Thanks!
However I still cannot get another Run Service command to run. It is one that invokes FooBar itself from a right click on a filename in the FooBar library pane and enqueues the entire directory the file is in. It worked fine for me under XP, but I can't get it to work under Windows 7 x64. The command line I am using is this:
As I understand this thread, originally the open poster "jjforums" asked a question how to apply a command line to run Mp3tag.exe from within FB2K. This problem has been solved.
What do you want to do?
Do you want to apply a command line to run FB2K from within Mp3tag?
Here is an example for a Mp3tag tool entry ...
Name: foobar2000 Fix VBR header
Path: \foobar2000.exe
Parameter : '/hide /runcmd-files="Utilities/Fix VBR MP3 header..." "'%_path%'"'
For all selected files: yes
Thanks. Actually what I want to do is use a command line to enqueue the entire directory in Foobar by right-clicking on a single song while I'm already in Foobar, in the Library view. In fact I just realized that the command I posted actually works (once the parentheses are escaped). The problem is that by default, Foobar does not display the file queue, and I had it set not to begin play automatically. (I use Foobar for tagging as well as simply for listening.) So the files were being enqueued, but I couldn't see them. Then I found the Queue Contents Editor plug-in, and now when I enqueue files in Foobar I can actually see them.
I don't know how I managed to set up Foobar NOT to show what files it's playing when they're not in a playlist, but that was my problem - plus the fact that the parentheses (which some genius at Micro$oft decided to include in the name of the default x86 Program Files folder for Windows 7) needed to be escaped - which I learned about thanks to you guys! Thanks again!