Run Script vs. Step-through Script

[Jeff Bellune]

I'm getting different results when stepping through a script than what I get when I run the same script. Stepping through it produces proper results; running it causes errors. How is that possible?

Here's the script. The audio files that will make up the M3U playlist are selected before running the script:

Code: Select all

//Create the m3u playlist then open it in Mp3tag.
  setting BackgroundFileOps, 0;  //Trying to slow things down.
  writefile ("<curfolder>.m3u", getinfo("SelectedItemsPathNames"), o);  //Write the .m3u file.
  selectitems "<curfolder>.m3u";  //Select the .m3u file so we can get its full path in the next step.
  $newFileNamePath = get("SelectedItemsPathNames");
  run """C:\Program Files (x86)\Mp3tag\Mp3tag.exe"" /fn:""$newFileNamePath""", , 1,1;  //Run Mp3tag with command-line parameters. Make script wait modally.
  selectitems "$newFileNamePath";  //Ensure the .m3u file is selected before we try to delete it.
  delete 1, 0, :list;  //Delete the m3u file because we're done.

When I run the script, it fails at the "run" line because Mp3tag reports that it can't access the file. But when I step through the script, Mp3tag opens the .m3u file properly. I've tried many things, including the openwith command. I've tried declaring and setting variables at each step in an effort to try to slow down the processing of the script when I run it. What am I doing wrong?

Thanks,
Jeff

[SkyFrontier]

Later I'l try to analyze this carefully.
My first suggestion would be using the run, wait; but it's already there.
The second: try adding a test value like "wait 10000" before the stage at which your problem happens; then decrease it to something like "wait 50", increasing it as it is necessary - solved little problems like yours with this little weird tricky.

Let me know of any progress, please.

[highend]

getinfo

Öhm... use get... getinfo is deprecated and probably the reason why the script fails.

and you don't have to select items to work with them...

Try this:

Code: Select all

  $m3uFile = "<curpath>\<curfolder>.m3u";
  writefile($m3uFile, get("SelectedItemsPathNames"));  //Write the .m3u file.
  run """C:\Program Files (x86)\Mp3tag\Mp3tag.exe"" /fn:""$m3uFile""", , 1,1;  //Run Mp3tag with command-line parameters. Make script wait modally.
  delete 1, 0, $m3uFile;  //Delete the m3u file because we're done.

[Jeff Bellune]

I made the change in my version of the script from "getinfo" to "get", but it didn't help. The problem was that the script needed some time after writing the file to find the new file and select it. A wait state of about 500 seems to be stable.

highend's version of the script works great! It may not seem like much, but after working on this for a few hours, I think that the idea to concatenate the <curpath> variable with the <curfolder> variable is a very insightful and an almost brilliant logical step. I read many parts of the help file, but I never picked up on the difference between those two variables and how they could streamline the script.

Thanks!

Jeff

[PeterH]

Maybe
Setting "BackgroundFileOps", 0; // DISABLE BACKGROUND Processing!
at beginning of the script might help?

(In this form it's only for the execution of this one script, then resetted to prev value.)

[Jeff Bellune]

Maybe
Setting "BackgroundFileOps", 0; // DISABLE BACKGROUND Processing!
at beginning of the script might help?

(In this form it's only for the execution of this one script, then resetted to prev value.)

That was the first line after the comment in my original script. I hoped it would fix the problem, but it didn't. Thanks for the suggestion anyway.

Cheers,
Jeff

[Jeff Bellune]

Update:

These lines of code:

Code: Select all

$m3uFile = "<curpath>\<curfolder>.m3u";
writefile($m3uFile, get("SelectedItemsPathNames"));

fail if the current folder is a paper folder. Better is to write the file to the user's temp folder:

Code: Select all

$m3uFile = "%temp%\PassToMp3tag.m3u";

Cheers,
Jeff