2 Complex Development Questions...

[bspachman]

I'm not sure if this belongs here or in the "Feature Requests" sections, but here goes...

1) Has anyone checked out the new "remote" underpinnings available in MediaCenter 9 (as of build 126)? If not, check out this thread at the JRiver boards:

http://www.musicex.com/cgi-bin/yabb/YaBB.cgi?board=beta;action=display;num=1047347478

One big questions is: will this fuctionality be able to be exposed in NetRemote? I'm imagining it would take an upgrade of both the NetRemote MJ/MC driver and the MC WebRemote plugin to know about that additional commands, but that passing the data to the Control Core might be fairly painless. What do you think?

2) Along more cross-platform lines, I'm interested in interfacing my Macintosh with MediaCenter. I've researched some things and have found Glissando (but am not interested in a flash-based client). I've also found a program for MacOSX that is basically an XML Parser/JavaScript runtime engine. I've seen the xml commands that Glissando passes to the WebRemote plugin as well as the xml responses that the WebRemote plugin returns.

My main question is: is there a way (in JavaScript or using UNIX shell commands) to pass the xml commands to the WebRemote plugin & receive the responses? Everything I've tried so far (a custom URL.fetch JS method & the "curl" URL application) seems to return web pages from the WebRemote plugin.

Thanks!
Brad

[Ben S]

Hi Brad.

1) I've seen it, but haven't done anything to implement it yet. I'm hoping either Warren can pick up the Media Center side of things, or that it can wait for a bit, as there are some other things I definitely need to get to before going back to add more functionality to WebRemote.

2) The xml in the webremote plugin is setup to act as a "flash server", so it doesn't "speak" normal http. You could use Perl (or php, or whatever) to connect to the socket and push/pull the xml that way?

[bspachman]

Ben,

1) Thanks for the update. I'm starting to follow the NetRemote threads as a natural outgrowth of my work with Girder and MediaCenter. I don't have the hardware to support NetRemote usage yet, but the project is amazing so far--keep it up!

Personally, I'm a Macintosh person, so the more standards the project embraces, the better. Which leads me to #2...

2) Perl, eh? I'm not a programmer by any means (although I can occasionally hack up a script). I've gone out and gotten a couple of books about JavaScript so I learn how to work with this new JS engine on the Macintosh. However, OSX has access to perl, so maybe I can do the network connectivity there.

Anyone have any pointers to perl documentation that is focused on the network communication side of things?

Best,
Brad

[brockgr]

Try these:

http://perldoc.com/ - Man pages
http://perldoc.com/perl5.8.0/pod/perlipc.html - Perl socket tutorial
http://perldoc.com/perl5.8.0/lib/IO/Socket.html - Perl socket library
http://search.cpan.org/ - Modules (XML etc)
http://search.cpan.org/dist/Win32-Girder-IEvent/ - Example use of sockets (blatant self promotion :wink:)

Gavin

[bspachman]

Gavin,

Thanks much for the pointers! They've gotten me jumpstarted a little bit. I don't want to turn this board into a perl discussion, but if you don't mind a few pointers, I'd appreciate it. Here's a section of code that appears to work fine with the MJ int_webremote.dll. It returns the WebRemote "home page" to standard out:

#!/usr/bin/perl

use IO::Socket;

$server = "192.168.123.133";
$document = "";

$remote = IO::Socket::INET->new(Proto=>"tcp", PeerAddr=>$server, PeerPort=>"8080", Reuse=>1)
or die "Can't connect to \"$server\"\n";

# set buffering off
$remote->autoflush(1);

# write HTTP request to server
print $remote "GET $document HTTP/1.1\r\n\r\n";

# receive everything the server sends and print it to the screen
while &#40;<$remote>&#41; &#123; print &#125;
close &#40;$remote&#41;;
From this example, you can see my MJ WebRemote is running at IP address 192.168.123.133 on port 8080. For some reason, the $document variable is needed in the GET statement. Leaving it out or substituting "" results in the WebRemote returning "I didn't understand command HTTP/1.1" Any ideas why?

However, the real problem for me is when I try to send the XML commands. Here's an example:

#!/usr/bin/perl -w

# setup the variables
$server = '192.168.123.133';
$port = '8080';
$fullPath = $server . "&#58;" . $port;
$command_xml = "<?xml version='1.0'?>\r\n<REQUEST command=\"getCurrentPlaylist\" value=\"\" />\r\n\r\n\x00";

# connect to the server
use IO&#58;&#58;Socket;
$socket=IO&#58;&#58;Socket&#58;&#58;INET->new&#40;$fullPath&#41;
or die "Couldn't connect to $fullPath&#58; $@\n";

# send a command
print $socket "$command_xml";

# receive the xml data from the server
$socket->autoflush&#40;1&#41;;
while &#40;<$socket>&#41; &#123; print &#125;

# close the connection
close&#40;$socket&#41;;
This code just appears to hang in the breeze. A packet sniffer reveals that the XML command is sent and a packet is returned that contains the information I expected. However, that return packet isn't written to standard out, which means I can't get it into a variable for further processing.

Any ideas as to what I'm doing wrong--or should I investigate another method altogether?

BTW, your perl stuff for Girder looks quite interesting--when I get a handle on what the heck I'm doing, I'll be checking it out in greater detail! :)

Thanks,
Brad

[brockgr]

First, why is $document needed? No idea - that doesn't make any sence.

The second one is more interesting. What is the "\x00" at the end of the string for? You don't need to send NULL's I would of thought. The reason you are not geting data back (I would guess) is that the $remote->autoflush(1); is too low down - myabe your print statement is getting buffered?

Cheers,

Gavin

[bspachman]

First, why is $document needed? No idea - that doesn't make any sence.
It's a mystery to me, too. I suspect the WebRemote plugin is a "special" server, so it may not conform to all of the RFCs.


The second one is more interesting. What is the "\x00" at the end of the string for? You don't need to send NULL's I would of thought. The reason you are not geting data back (I would guess) is that the $remote->autoflush(1); is too low down - myabe your print statement is getting buffered?
As for the NULL, again, something in the WebRemote doesn't like the sent command if it doesn't contain the NULL at the end. From Ben's response above, I can only assume it's something to do with being a "Flash Server". I guess I'll check out Macromedia to see if I can get any useful info there.

I figured that buffering is my problem, but no matter where I place the "autoflush" statement, it makes no difference. I also tried adding a "$|=1" definition at the beginning of the script--it didn't help either.

The other possibility I thought of is that the response from the "Flash Server" also ends with an explicit NULL. Could that be gumming up my works? I tried "chop"ping the return values with:

while &#40;<$socket>&#41; &#123;
chop;
print;
&#125;
and eliminating the last 5 NULLs with:

$answer = substr&#40;<$socket>,0,-5&#41;;
print "The response is&#58; $answer\n";
Neither example helped.

Anyone else have any insights?

Brad

[Ben S]

Is there a way to read character by character instead of reading a string from the stream?

The "flash server" concept is that the socket is left open, and each side sends data ending with a null, to signify the end of transmission.

You're right. WebRemote -is- a special server. I wouldn't be surprised if it doesn't conform to any of the RFC's. I hacked up the code that I originally downloaded to be happier about things, but overall it works with IE's default fetch, and NetRemote, which is all I made sure of. My bad! :)

As to the flash server, this is even -more- cobbled.

WebRemote listens for a request. On a "tingle", it reads the first line. If the first line starts with "<?xml", it enters flash xmlserver mode. (No get required or allowed) You should see "Initiating XMLSocket handler" in the MJB output window on successful connect this way.

Now WebRemote reads characters into the buffer until a null (0) is reached.

WebRemote does what it wants to do, and then pumps the data out, finishing with a null character.

[brockgr]

Try "getc()".

Gavin