Queuing with JTFE from media library

[etsaman]

Hi DrO,

1st question : is there a way to "queue" to JTFE directly from the media library or via a command line?

What I'm trying to accomplish here is to "queue" a song that is contained within my file structure but not present in the current playlist.
Since I'm calling this from an external program (home automation - Homeseer), it has to be as simple as possible.

My current workaround, is to "add to playlist", monitor the number of entries in the playlist and once it detects a new entry, it emulates keystrokes ("End" then a bunch of "down") so the focus is on the last line of the playlist and press "Q"; not the most elegant way to do it, but it's the only way I found so far.

The current behavior in the media library:

"Enqueue"=add to playlist
"Send to" / "add to queue" = add to playlist

would essentially need something like "add to JTFE" instead; or a way to do it via a command line call.

2- Can you confirm where JTFE stores its queue list so we could potentially access it from Homeseer for external display purposes?
(found gen_jumpex.m3u8 in the C:\Users\Admin\AppData\Roaming\Winamp folder but seems empty)

3- Are there WMcommands or other ways to interact with JTFE externally? (queue to JTFE, access the Queue, move entries up/down, etc)

Thanks for your help!

Yann

[dro]

1) Prefs -> Playlist -> Jump to File -> Media Library tab -> queue manager view needs to be enabled. That will allow add to queue & other related options on the send-to menu though it's not enabled by default & is something I want to change later on so the send-to feature isn't dependent upon the media library core plug-in (gen_ml.dll) being present.

2) When it's running there isn't a static copy to view & the file you've found is only used when closing & the option to remember the queue is enabled. However it's an implementation detail which I had been looking to change as part of other consolidation & general clean-up with the jtfe mode moving from being a specific plug-in to part of the wacup core.

3) Not that works at the moment as its dependent upon me finishing off the file association / shell integration support & not having Winamp's original code running so the hacks that I'd had to use up to 5.666 aren't needed (none of that code is enabled under WACUP).

-dro

[etsaman]

1) both of these "queue" features add the file to the "playlist editor" you then have to manually go in the playlist editor and press Q....
What I'm looking for is to "JTFE queue" the file directly from the library (same as pressing "Q" in playlist editor), or even better, straight from windows explorer context menu or winamp's command line.

2) and 3) fingers crossed for progress on these two as I had to build complex macros to achieve very simple tasks....

Really love JTFE but really need a way to access it easily from my Android devices and/or automate it via simple commands. (Homeseer)

Thanks again for all your support,
Cheers!

[dro]

There was an explorer menu option with the older version of the plug-in under 5.666 but it also didn't work too reliably but is on the list of things for the native support for additional explorer menu actions. The majority of it comes down to needing a known api in place that can deal with things so plug-ins can react accordingly without basically the hackish way that I'd tried to get things like the external queuing to work.

Unless I'm mis-reading things, it seems you're saying that queuing up items from elsewhere in the JTFE queue isn't also adding them into the main playlist editor - is that so or am I just mis-reading things?

-dro

[etsaman]

What I mean is that there is no way to add "new" (not already in the playlist) items directly to the JTFE queue from explorer, the command line, Ajaxamp or the MediaLibrary
You have to add/queue items to the playlist, go back to the playlist, find the item at the bottom of the list and press "Q"

The use case:

- a playlist is currently playing on random, let's say my "Rock songs" folder
- someone asks for two songs contained within my "Christmas songs" folder;
- I will add them via JTFE and once these two songs have played, the "Rock" playlist will simply resume.

Now, since winamp doesn't provide any direct remote interface, I had to figure out a simple way to interact with Android devices.
Most Winamp features are available via simple WMcommands, the Homeseer plug-in or Ampwifi (Android app) which are all great workaround I've been using successfully.
however, there doesn't seem to be a simple way to access JTFE features.
Therefore I had to build a complicated macro routine to automate the actions and keystrokes required to do it; and I still don't have a way to view or edit the actual JTFE queue....

So unless an Android remote interface is in the works (fingers crossed), I'm looking for a simple way to queue items in JTFE and access/manipulate the queue so that I can do this via any of the above mentioned mediums.

Thanks for your help!

[dro]

Ok, was just a cross-wire on the terms being used & not what I thought was meant, just that I need to get flexible command-line support in place (which would then allow more actions to potentially be done based on what the plug-in(s) decide they want to implement).

-dro

[etsaman]

Thanks Darren, that would be great;

I am in touch with the developer of Homeseer's Winamp plugin (JonO)
https://forums.homeseer.com/forum/3rd-party-developer-area/general-developer-discussion/jon00/94458-jon00-winamp-controller-for-homeseer-3-and-homeseer-4
He did a great job implementing the plugin but it still misses JTFE interaction;

Same goes for the Android app: Ampwifi (Michael Veroukis)
He is still active and looking for alternatives to Ajaxamp to better interact with Winamp
http://www.blitterhead.com/ampwifi-android-app

I will stay tuned so we can hopefully add JTFE support via new command-line support.

Keep us posted, cheers

[mveroukis]

Interesting, never heard of Homeseer. Jon00 has a really weird website which seems to be running on his home pc? Anyway, it seems like his Winamp plugin has a good list of features. Has the author indicated that he's willing to open up the plugin in anyway or even expose a REST api?

Are there IPC messages to interact with the JTFE? I don't remember seeing any but I may have missed them.

[dro]

I'd assume most of the interaction is just via the command-line (good thing 5.66x had that fleshed out in a few areas to make doing some of the SendMessage equivalents easier).

JTFE sort of has a SendMessage api along with a Wasabi based api but it's not all that great & I was intending on dropping/replacing it as it (the sendmessage api) doesn't fit in well with how the plug-in needs to work going forward.

-dro

[etsaman]

Hi Darren, hope all is well;

Until some sort of command line is implemented for JTFE, is there any way to "extract" the JTFE/queue manager playlist so it can be pulled every x seconds and shown in a third party app ?

Also wondering if WMuser commands (or any other shortcut) allows to close / open the video and visualization windows (not toggle commands)
Since it doesn't return status, the toggle commands can't be used to just close or just open a window.
you essentially don't know if the toggle command will close or open the window....

If there is any list of "unpublished" commands, I'd really like to see it =)
I have attached a list of what I could find so far. If  I am missing any commands let me know where to find the rest or send it over my way.

Thanks

[dro]

The jtfe api which isn't a plain wm_command solution doesn't have a dump queue mode though I'm trying to get something done for the next build.

Looking though the menu & accelerator tables is one way to try to work out what wm_command actions there are. Not that all actions use that & it can then be wm_wa_ipc or other custom messages based off dynamically assigned values or the comparable registermessage solution.

I don't however remember seeing specific messages to close the windows & it's just toggle actions since the winamp/wacup core handles the state internally. I can however look at adding such methods with the matching show but it'll be easier via a wm_wa_ipc message (wm_user) to match some of the existing messages.

-dro

[etsaman]

Thanks for the feedback, let me know if you make any progress with JTFE in the next build, I'll be glad to do some testing.
Cheers,

[dro]

For the window handling you should be able to use the following with the next build:

Code: [Select]

#define IPC_GETWND 260
/* (requires Winamp 2.9+)
** HWND h=SendMessage(hwnd_winamp,WM_WA_IPC,IPC_GETWND_xxx,IPC_GETWND);
** returns the HWND of the window specified.
** Note: this does not support the WACUP message addition
**       of IPC_GETWND_MAIN since you have to use a valid
**       main window HWND to start with, need I say more?
*/

#define IPC_GETWND_MAIN -1 // use one of these for the param
#define IPC_GETWND_EQ 0    // see api notes on what is valid
#define IPC_GETWND_PE 1    // (IPC_GETWND_MAIN new to WACUP)

//#define IPC_GETWND_MB 2  // deprecated from 5.22+ when the
                           // minibrowser support was killed

#define IPC_GETWND_VIDEO 3
#define IPC_GETWND_ML 4    // added WACUP 1.0.11+ but may not
                           // be applicable based on install!

#define IPC_ISWNDVISIBLE 261 // same param as IPC_GETWND
/* (requires Winamp 2.9+)
** This returns the current visible state of the window.
** Under WACUP using IPC_GETWND_MAIN as the param is
** supported & will return the main window state.
*/

#define IPC_SHOWWND 262 // same param as IPC_GETWND
/* (added WACUP 1.0.11+)
** This will show the specified window if its closed
** and it will return non-zero on success. If the
** window is already visible then nothing is done
** though the return is zero for you state usage.
*/

#define IPC_HIDEWND 263 // same param as IPC_GETWND
/* (added WACUP 1.0.11+)
** This will hide the specified window if its open
** and it will return non-zero on success. If the
** window is already hidden then nothing is done
** though the return is zero for you state usage.
*/

IPC_SHOWWND & IPC_HIDEWND are the main WACUP additions (the other change being some ML & main window specific stuff on the older APIs). That should allow you to hopefully open / close those windows as needed along with using the returned state & IPC_ISWNDVISIBLE if needed beforehand to deal with state persistence as needed.

Will provide the JTFE queue saving details once that's been finished.

-dro

[dro]

For the queue saving option, you can use wacup.exe /TEMP_SAVEPLAYBACKQ whilst WACUP is running (doing it when it's not running will be ignored) & that will save the current queue out to the gen_jumpex.m3u8 file in the settings folder (as normally happens on unloading the plug-in if the restore option is enabled).

If there's nothing in the queue at the time of the command-line action then the gen_jumpex.m3u8 file will be removed if it already exists otherwise the contents of the file will be updated. No queue, no file for simplicity.

There's handling to have the request fail if the process is deemed to have hung & the name of the option is prefixed with "TEMP_" as that's the intention for it in its current incarnation. I would prefer it to be outputting in a different format & to control the location but that's more of a pain to have strings passed around which is why I've re-used the existing handling just to get something working for you.

-dro

[jon00]

For the queue saving option, you can use wacup.exe /TEMP_SAVEPLAYBACKQ whilst WACUP is running (doing it when it's not running will be ignored) & that will save the current queue out to the gen_jumpex.m3u8 file in the settings folder (as normally happens on unloading the plug-in if the restore option is enabled).

If there's nothing in the queue at the time of the command-line action then the gen_jumpex.m3u8 file will be removed if it already exists otherwise the contents of the file will be updated. No queue, no file for simplicity.

There's handling to have the request fail if the process is deemed to have hung & the name of the option is prefixed with "TEMP_" as that's the intention for it in its current incarnation. I would prefer it to be outputting in a different format & to control the location but that's more of a pain to have strings passed around which is why I've re-used the existing handling just to get something working for you.

-dro

To provide queue information in my plugin would require me to poll WACUP with the TEMP_SAVEPLAYBACKQ command every few seconds and then act (if necessary) on the generated file. Whilst feasible, having the queue list just replicated in a m3u file would be much easier to manage as you can the use a filewatcher class to monitor file changes. Any thoughts?