Print

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

[Soundman]

Hi, Matt, Nikolay.

I hope this does not seem rude, but I want to express my strong plea for a little Automation feature.  While I previously posted a big wishlist, I can trim the urgent need down to just one simple thing:

Please parameterize the Play() and DoCommand() methods so they have all the variations of Play found in the GUI under Right-click -> Send To -> Play -> ... (e.g. Add as next to Play, Remove, Replace shuffled, etc.)

My whole HTPC project has been held up, waiting on this for three months!  

Since the Play() method already takes a (currently ignored) integer parameter, and the GUI already implements all the commands needed, then I just can't believe this would be hard to add to Automation.

Holding my breath for a reply....
Soundman

[Agonostis]

An echo of the plea.

[Soundman]

Bump.

[nila]

I'd say it doesn't look like it's gonna happen any time soon.

Just build your own plugin to do this - it shouldn't be tooo hard and you'll get a result ALOT faster than you will by the looks of this thread so far.

Plus if you make your own plugin to do it you'll have more control over it

[Zoner]

Plus if you make your own plugin to do it you'll have more control over it

How so?

[Rob L]

Well, you can obviously get the "Playing now" list and manipulate it how you like, surely?

[ender13]

if someone gets this to work could you please post info!!!

[Soundman]

Well, you can obviously get the "Playing now" list and manipulate it how you like, surely?

Yes, I can, and I have written all the code to do that.  The problem is that it is unusably slow.  It is only possible to iterate through the playing now list at a rate of about 160 files per second.  To do this, I have to load the entire playing now list into an array, load the entire IMJFilesAutomation list also, locally integrate the two, then propagate any changes back to playing now (typically, clear it, then write my array back out to it.

This adds up to a net speed of maybe 60 or 80 files per second, where N is the sum of the size of the current Playing Now and the IMJFilesAutomation list being applied.

Soundman

[ender13]

um...(ignore my stupidity if this is really obvious) but what does it do in simple terms?

[RhinoBanga]

Yes, I can, and I have written all the code to do that.  The problem is that it is unusably slow.  It is only possible to iterate through the playing now list at a rate of about 160 files per second.  

How are you reading?

I just wrote a test program and it iterated over 1246 entries, pulling out the track name, in 31 milliseconds on a P4 1.7ghz:


    DWORD                       start   = ::GetTickCount();
    IMJCurPlaylistAutomationPtr ptr     = Global::getCurrentPlaylist();
    IMJFileAutomationPtr        file;
    _bstr_t                     name;
    for( long loop1 = 0; loop1 < ptr->GetNumberFiles(); ++loop1 )
    {
        file = ptr->GetFile( loop1 );
        name = file->GetName();
    }
    DWORD stop = ::GetTickCount() - start;
    char msg[ 256 ];
    sprintf( msg, "Reading %d entries took %g seconds elapsed", ptr->GetNumberFiles(), ((float)stop) / 1000.0 );
    AfxMessageBox( msg );

[Rob L]

Really?? Blimey!

The reason I didn't respond was that I realised that he had a point - I tested it on my machine and was surprised to find that for some reason reading the list of files from the currently playing list took longer than reading them from a view scheme.

But either way, it's a lot slower than you're getting!

It takes me about 60 seconds to read all 9000 entries from the current playlist, or about 30 seconds if I just read them all from a view scheme.

The only differences between what I was doing and what you're doing is that I'm doing it in VB and actually storing the data into an array (which is what I imagine is slowing it down). Obviously you're not actually doing any processing of the entries. On the other hand, I was also doing it on a significantly faster machine (P4 2.6GHz)

[RhinoBanga]

How many fields are you reading?

In my sample I am just pulling out the track name.

Maybe I'll time how much overhead there is pulling out other fields.

[Rob L]

Ah, yes, well that is another difference!

I was reading:

.Album
.AlbumArtist
.Filename
.Name
.TrackNumber

[RhinoBanga]

Well I just timed it on my main machine.

A P4 2.5ghz oc'd to 2.75ghz took 1.453 seconds to read all your fields in 12224 entries, which equates to 8412 entries a second.

Taking out the filename brought it down to 0.328 seconds which equates to 32768 entries a second.

Then taking out album brought it down to 0.297 seconds.

Looks like it's the filename fetch which is the resource hog ... but the fact remains iterating over an MC files collection is not slow.

[Rob L]

OK... although it still leaves *mine* much slower - I guess the most likely culprit is going to be the fact that I'm doing it in Visual Basic. Ah well... Guess I'll have to brush up on my C++!

[Soundman]

I'm Glad to see this topic spark some interest.  Yes -- the performance problem boils down to which kind of COM interface you are using.  I forget the terminology here, but scripting languages like JavaScript, VBS, Perl, and even full Visual Basic access COM through a late-binding dispatcher.

On the other hand C++ can be written to access the COM interfaces in a more direct, early binding fashion.

I am writing my stuff using JavaScript embedded in a web page. The performance is terrible, as I described earlier.

I tried modifying the "Web Remote" example plugin to manipulate Playing Now in C++, but I found that MJCurPlaylistAutomation::AddFile() method always crashes no matter what parameters I use (I posted about this in mid-2003).

Although I am a professional C/C++ developer, it is not on a Windows platform, and I guess I have just not gotten the hang of doing COM right, or perhaps I have a compiler / configuration problem.

The bottom line is that, JRiver's SDK has lots of potential, but if you use a scripting language, you can't do anything that requires iterating over large lists.   I wish that would change.

Thanks,
Soundman

[salsbst1]

...scripting languages like JavaScript, VBS, Perl, and even full Visual Basic access COM through a late-binding dispatcher.

Not true.  If you reference a type library and declare your variables as typed (as opposed to "as object") then VB is early bound.

Dim myMJ as MJAutomation

will give you a huge performance boost over

Dim myMJ
'or
Dim myMJ As Object
'or
Dim myMJ As Variant

[Soundman]

Hello, salsbst1.

That is very interesting.  It sounds like you are talking about full Visual Basic, however.  Can this be done in JavaScript (or VBS)?  Any hint as to how?

Thanks,
Soundman

[Rob L]

Actually, though I was already doing that in 'full' Visual Basic. I tested it both ways after seeing the post, and it does make a difference, but VB is still *way* slower than RhinoBanga is reporting....

[RhinoBanga]

That's the nature of the beast.

VB will be slower than C++ in almost all cases.

What sort of timings are you getting?

[Rob L]

Well, apart from the stuff I mentioned above, I think the quickest I managed to get was about 15 seconds for a collection of about 9000 files.

I've been upgrading to the latest versions of MC10 regularly though so that may have been making some difference...

[RhinoBanga]

I'll knock up a simple VB test tonight and do some comparisons.

One question ... is this in or out of process activation?

[Rob L]

Erm, good question... what's the difference?
 

[RhinoBanga]

Are you a plugin within MC are are you creating a stand-alone EXE/DLL which is talking to MC?

[Rob L]

It's actually a standalone EXE at the moment, though I'll be changing that as soon as I get time :-)

[RhinoBanga]

Well that will account for a big amount of performance loss.


My timings were done in-process.


I'll let you know how I get on.

[Rob L]

So you reckon the answer might be for me to do it as a plugin?

[salsbst1]

So you reckon the answer might be for me to do it as a plugin?

MC doesn't expose an in-process API other than to plugins (which is a shame, but I guess there are reasons).  The only way to get in-process speed is to do a plugin.

[Rob L]

OK... though odd.
The only difference I could see between my code and the sample included in the SDK was that theirs was a control. So presumably there is actually no code difference - the same code just acts differently in the different scenarios...

[salsbst1]

Your code won't really act any differently, but Windows has to do a lot more work when threads from two different EXEs talk to each other.  It's called cross-process marshalling and it's slow.

By doing a plugin you stay within Media Center's EXE and avoid cross-process marshalling.

[Rob L]

OK, thanks. Some extra motivation for me to get on converting it then I guess
 

[Soundman]

FWIW,

My timings with JavaScript iterating through the files in a MJFilesAutomation collection are:

160/sec out of process using MCIO
80/sec out of process using MC's native support for this
320/sec in-process JavaScript.

All of these are dismal, of course.  I suppose I'll have to switch to C++ to get reasonable timings, but I lack a decent compiler at the moment.

Soundman