Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

I'd like to be able to create a Smartlist via the COM interface but I've hit some trouble.

In the documentation, it says:

Code: [Select]

string Get(string bstrProperty)

Description: lookup a property associated with a playlist
Parameters:

    bstrProperty: the name of the property

Return Value: the value of the property for this playlist
Properties (not complete list):

    Type: 0 = playlist, 1 = playlist group, 2 = smartlist, 3 = special (e.g. 'Current Playcharts')
Yeah, well... That's not too handy.  I can make a new Playlist via the IMJPlaylistsAutomation interface, and then I can check the type, and change it, but I can't set it up fully as a Smartlist with only that information.  So, I tried the "guessing" method.  I connected to a known Smartlist in my Library, and did:

IMJPlaylistAutomation.Get("Search");

And, eureka, it spit out the Search for my Smartlist.  So, I thought... Cool!  Let's try.

(Make a new Playlist)
IMJPlaylistAutomation.Set("Type", "2");
IMJPlaylistAutomation.Set("Search", "my cool search");

But, alas... This was bad.  Very bad, actually.  MC, while running, didn't show my new Playlist at all.  Then, when I exited MC and re-opened it, my Library was hosed (MC crashed on launch).  I swapped out my playlists.jmd file in the Library for a backup and that saved me, but it didn't get me any closer to my goal.

So, I assume I need to set more Properties than just that.  But I don't have a list.  Any suggestions?

[glynor]

So... I played some more with this tonight (digging around the playlists.jmd file with a hex editor and whatnot), and I got it kinda working.  But, boy, is it fragile.

If you do a sequence of MCC Commands to change views along with the automation commands I described above... It works.  But, it seems to depend on the conditions (maybe the way in which the views are displayed before it starts?) being "just so".  Here's essentially what I'm doing:

Launch MC and make sure it is showing some view other than the Playlists Root View (I'm going to Playing Now, but Audio or whatever seemed to work too).
Do the Automation commands above to create a standard Playlist, then convert it to a Smartlist.
Switch MC to the Playlists Root View and Refresh the view (both via MCC Commands).
Restart MC.

This works around 50% of the time.  It seems like it is far less reliable if the smartlist you create isn't in the root of the Playlists view.  I've found that it is 100% reliable if you first nuke the Playlists in MC altogether (delete the playlists.jmd file), but with an existing set of playlists, it is flaky.  Unfortunately, when it flakes out, it leaves MC in a state where it won't launch at all, and you have to nuke the playlists.jmd file.  So, no good at all.  Unusable.  I could mess with it more, but I think I'm surrendering.

You can't create Smartlists in an automated fashion.  At least, not from out-of-process (maybe it would work from inside the process via a plugin, who knows).  If you do, you risk hosing your Library.  If someone from JRiver can chime in and tell me there's an awesome, supported way to do it (maybe via REST or something I haven't looked at), I'll try again, but for now... I'm out on this plan.

[wig]

That experiment sounded interesting, Glynor. You know I'm all about smartlists; what were you hoping to accomplish?

[glynor]

I was trying to build a setup wizard for MCAutoQueue that could automatically create the necessary "queuing smartlist".

I can do everything else automatically, basically (by importing some "sample" files that have the needed tags), except make the smartlist.  But, that part doesn't work, and we can't hose end-user's libraries.  Too bad, it would have been slick.

I might check the REST interface, but I don't think it can make smartlists either.

[Matt]

How about a new function like:
MCWS/v1/Playlists/Add?Type=Smartlist&Path=Group\Name&Search=abba&Mode=Overwrite

You'd call it with COM using pMJ->ProcessWebService(...).

It would return the new playlist ID.

You'd have to parse a little XML in the response, but that code should be reusable for other MCWS functions you might call.

[glynor]

That would be awesome.

Honestly, it is pretty drop-dead simple to parse XML responses from REST-based servers in .NET.  This might actually inspire me to do what I've been planning and add the MCWS functions to my handy little wrapper (which will expose .NET-native "objects" for the various stuff in MCWS with a singleton connector).

Not hard.  Just a bunch of typing.  

I didn't bother before because:

1. .NET isn't really cross-platform anyway (there is Mono, but it isn't ideal in a bunch of ways).
2. Nothing I was doing required accessing MC via the network (and in most cases, you need to be attached to the "server copy" anyway and have local access to the files).

[Matt]

That would be awesome.

It's been added to MC19.

It probably won't get ported back to MC18, since only bug fixes will go to the MC18 code now.

[glynor]

That's fine.  Thanks!!

[glynor]

Hey, Matt... Any documentation on using the ProcessWebService() method?

I'm not figuring it out... It seems like the string it outputs is always "1" if I load a valid MCWS url, and "0" for everything else.  I can't actually get it to give me the response from the server.  But, I'm wondering how I'm supposed to form the URLs I send with it.  Do I use the whole thing including the http://localhost:<PORT>/ or something else?

I'm probably going just build a real REST client, but I was curious about the capabilities of using that method via COM.  Also, a couple questions (what I was trying to figure out)...

1. Does using ProcessWebService() via COM require authentication (assuming authentication is enabled in MC)?
2. Do those commands work even if MCWS is disabled (as it is by default) in MC?

[glynor]

1. Does using ProcessWebService() via COM require authentication (assuming authentication is enabled in MC)?

If so, that'd probably explain my useless results...

[glynor]

If so, that'd probably explain my useless results...

Nope, no change if I use a token...

[glynor]

Okay... I've figured out more.  The ProcessWebService() method exposed by COM seems to be what you used to build this:

18.0.153 (3/18/2013)

5. NEW: The command line allows making MCWS web service calls: MC18.exe "/MCWS/v1/Playback/Pause?State=-1" (does not require Media Network to be running or a server to be listening).

Unfortunately, it seems to be just a one-way function, only useful for sending commands to MC, and not for retrieving information from MC.  The string the method returns seems to be just a boolean that indicates whether the command was successful or not (and even that is dubious, as it seems to just be always true if the MCWS server "heard" the request).

Is this the way it is supposed to be?  If so, you can't really use it for what you suggested because there's no way to get the XML response from MCWS via COM (unless I'm missing something, which is entirely possible).  Using the new MCWS stuff via COM without having to worry about authentication or whether Media Network is on or off would be handy, when you're talking to a local copy of MC anyway so you can get a COM instance.  That's how I'd use it here, for example, even if I had a real REST client built, because it wouldn't require the users to have activated Media Network or any authentication stuff.

In my particular instance... I can probably "hack" it:  Send the "create playlist" command, then parse through the Playlists item via the other old COM functionality to retrieve the Playlist ID that I just made.  But, this could be prone to error...

Is that function designed to only allow "send this to MC and forget it" (like Play/Pause/Next type playcontrol commands)?  Or is it just messed up?

[Matt]

Is this the way it is supposed to be?

Yes and no.

It's functioning as coded, but I agree it'd be better to return the actual MCWS string response.  The reason it doesn't is that sometimes MCWS returns files, etc. so it's not universally serializable to a string.

Let me put it on my list of good intentions.

[glynor]

Let me put it on my list of good intentions.

Thanks, that would be great.

I hadn't thought about the fact that it sometimes (often) responds with files directly.  Though, of course, it is still just a HTTP response, so there's a URL in there.  I'd be completely happy if, when the server responds with a file, the COM server just wrapped the HTTP link in the response in a simple XML document (<FileResponse>...</> or whatever), and sent that.

Most of the time I don't want those directly anyhow, because I have direct access to the filesystem, which is better/quicker/more productive.  Then I could grab it myself if I want it, which I probably don't, but I might want the filename or something, I suppose.

Even if those just returned null or whatever I'd be happy, if we could get most of what you can do through MCWS without authentication and requiring MC to have it enabled.

[Matt]

Next build:
Changed: The automation call ProcessWebService(...) returns the response instead of just 0 or 1.

It took a while, but it's there!