Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Change in Foobar2000 scripting behaviour (Read 781 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Change in Foobar2000 scripting behaviour

Morning everyone. Long time Foobar2000 user here. Love this application.

I'm hoping someone here can provide insight in the change in Foobar2000 behaviour recently. The most frustrating part is that Foobar2000 hasn't actually been updated. But the change is there.

In the past I have started Foobar2000 with a script as follows:

Code: [Select]
subprocess.call('start "Energy List" "'+FOOBARPATH+'" /command:"Shuffle (tracks)" "E:\\Music\\Playlists\\Energy.fpl" /command:"Set to -6 dB"', shell=True)

In the past this command has ran the given parameters sequentially in order. So for example this would set the tracks to shuffle mode, load a playlist, then change the volume.

Now though, without updating Foobar2000 the playlist is always loaded first. Disregarding parameter order. So now the shuffled playlist always starts at the first entry. Because the shuffle command is called after the playlist is loaded.

So I can no longer call a shuffled playlist from within code or via a script. Very frustrating. Can anyone here provide insight into where this change has came from? I'm assuming Windows 10 has changed something silently. I'm using the most up to date portable version of Foobar2000.


Re: Change in Foobar2000 scripting behaviour

Reply #2
I'd make 2 separate calls. Surely that would work?? Obviously omit start from the second one.

So, initially this is what I did to patch it. Good idea.

It doesn't work sadly. I'll show you the code:

Code: [Select]
                
subprocess.call('start "Energy List" "'+FOOBARPATH+'" /command:"Random" "E:\\Music\\Playlists\\Energy.fpl" /command:"Set to -6 dB"', shell=True)
time.sleep(1)
FoobarCommand(FOOBARPATH, "Next")
time.sleep(1)
FoobarCommand(FOOBARPATH, "Shuffle (tracks)")
FoobarCommand(FOOBARPATH, "Reshuffle")       

This however causes Foobar2000 to become "confused". Even with the 1 second sleep timers you can see there, the application often errors. It will sometimes just add the playlist to the existing playlist. Or not execute the commands in order etc. The code in my first post is the only way I have found (with a huge amount of testing) to get foobar2000 to execute commands reliably, in order.

The random command there is necessary in order for the shuffled playlist to have a random initial entry point. Without it the shuffled playlist always starts from the beginning of the playlist. And from there the shuffled playback order is always the same unless you restart Foobar. I am not even sure my "Reshuffle" command there even works. I've just put it in out of desperation.

Even with the above code it works only about 30% of the time. The rest of the time things will arrive in a haphazard order and fail to fire. It's really really hacky and janky. Sometimes randomly the playlist won't open in a new playlist, it just gets added to the existing playlist for some reason. The behaviour is odd.

I have always just assumed the Foobar2000 devs wanted me to pack it all into one command. As my original code always executed perfectly, I assumed it was an intentional design choice. Why it no longer works with no change to Foobar? I am just assuming Windows has changed.

Re: Change in Foobar2000 scripting behaviour

Reply #3
I have no idea where that subprocess.call originates from but I was thinking more like this.

Code: [Select]
subprocess.call('start "'+FOOBARPATH+' /command:"Shuffle (tracks)" /command:"Set to -6 dB"', shell=True)
subprocess.call('"'+FOOBARPATH+'" "E:\\Music\\Playlists\\Energy.fpl"', shell=True)

The order of menu commands in the first call would be irrelevant if doing the playlist bit last.

edit: here's some random off topic spam. Command line users might find these useful...

https://jscript-panel.github.io/other/run-main/
https://jscript-panel.github.io/other/play-track/

Re: Change in Foobar2000 scripting behaviour

Reply #4
You would hope this would work. However on my system at least it doesn't. At the moment now from some reason it always starts from the first entry in the playlist. Even if shuffle is called prior to opening the playlist.

How you wrote it there is actually how I initially tried to patch it.


Re: Change in Foobar2000 scripting behaviour

Reply #6
Look at the built in command line help, what about using /add for the playlist?

I didn't know there was one. Where is the command line help?



Re: Change in Foobar2000 scripting behaviour

Reply #9
Ah, it is a popup window. You'd have to test it locally.

Code: [Select]
Available switches:
  /add <list-of-files> - appends the specified files to the current playlist instead of replacing the playlist content and playing them immediately
  /immediate - suppresses the delay when adding files
  /play, /pause, /playpause, /prev, /next, /rand, /stop - playback controls
  /exit - exits foobar2000
  /show, /hide - shows or hides the main foobar2000 window
  /config - opens the Preferences dialog
  /command:<menu command> - invokes the specified main menu command
  /playlist_command:<context menu command> - invokes the specified context menu command on current playlist selection
  /playing_command:<context menu command> - invokes the specified context menu command on currently played track
  /context_command:<context menu command> <files> - invokes the specified context menu command on the specified files

Re: Change in Foobar2000 scripting behaviour

Reply #10
Ah, it is a popup window. You'd have to test it locally.

Code: [Select]
Available switches:
  /add <list-of-files> - appends the specified files to the current playlist instead of replacing the playlist content and playing them immediately
  /immediate - suppresses the delay when adding files
  /play, /pause, /playpause, /prev, /next, /rand, /stop - playback controls
  /exit - exits foobar2000
  /show, /hide - shows or hides the main foobar2000 window
  /config - opens the Preferences dialog
  /command:<menu command> - invokes the specified main menu command
  /playlist_command:<context menu command> - invokes the specified context menu command on current playlist selection
  /playing_command:<context menu command> - invokes the specified context menu command on currently played track
  /context_command:<context menu command> <files> - invokes the specified context menu command on the specified files

Right, ok. Thanks for this. I've made a little progress. The code now looks like this which is a little less convoluted:

Code: [Select]
subprocess.call('start "Energy List" "'+FOOBARPATH+'" /command:"Shuffle (tracks)" "E:\\Music\\Playlists\\Energy.fpl" /command:"Set to -6 dB"', shell=True)
time.sleep(1)
subprocess.call('"'+FOOBARPATH+'" /rand', shell=True)

I wasn't aware of the "/rand" command. I think the core of the problem here is that even if shuffle is selected before the playlist is opened, it always starts at the beginning of the playlist. With that extra command there it at least gives me a random playlist insertion point, which then gives me a newly shuffled playlist.

How did you see those list of commands your side? I'll take a screenshot of it and put it in my Foobar2000 folder.



Re: Change in Foobar2000 scripting behaviour

Reply #12


Thanks for this.

Right. I just ran the code 10 times. It only got "confused" 2 times out of 10. By confused I mean it drops a command or adds the playlist to the current playlist instead of opening a new one etc. I'm just assuming this is some sort of race condition.

So things work 80% of the time now instead of 30%. This is decent progress for me.

Re: Change in Foobar2000 scripting behaviour

Reply #13
I might modify one of my components to handle this scenario. I could make it create a new playlist within fb2k based on the name extracted from the full path. And playing the first track or random would guarantee to only happen when the playlist is ready.

Re: Change in Foobar2000 scripting behaviour

Reply #14
I might modify one of my components to handle this scenario. I could make it create a new playlist within fb2k based on the name extracted from the full path. And playing the first track or random would guarantee to only happen when the playlist is ready.

Something is wrong on a deep level here. I have a feeling the fact the script I'm calling is ran as admin might have something to do with it? This would account for the change in behaviour not being connected to a change in Foobar2000 but Windows itself I think.

Behaviour is still unstable for me here sadly. I think I spoke too soon earlier.

Re: Change in Foobar2000 scripting behaviour

Reply #15
I might modify one of my components to handle this scenario. I could make it create a new playlist within fb2k based on the name extracted from the full path. And playing the first track or random would guarantee to only happen when the playlist is ready.

There used to be a plugin that just let you run commands instead of referencing the same Foobar2000 binary. This stopped the "confusion". It was 32-bit though and was never rebuilt if I remember.