[Mug-why]

Well, I’m not as negative about this as you are Gabriel. 😉

I think most of the usage issues you mention are fairly easily dealt with (activation of this ‘listening’ feature as an option at the Wii, or else some kind of simple password system would prevent control conflicts).

I do like your idea of a simple port listener and a basic protocol – certainly I am not thinking of cgi! I am really only interested in implementing a single command – being able to tell it to start playing a nominated file via the LAN (presumably http). In terms of what the http server would serve, as I said, just some kind of logfile to show whats going on would be enough (would likely only be used to diagnose problems). So this doesn’t seem like it would be too much of an additional load for the Wii.

Also, bear in mind that GeeXBox for the Wii includes telnet, ftp and http servers (http://farter.users.sourceforge.net/geexboxforwii/usage/networking/), so it doesn’t sound like its impossible for the Wii to do this kind of thing in addition to playing files.

Also, ideally this would not be “controlling MPlayer directly” – above I am trying to understand the calls that WiiMC uses to MPlayer, so I see it as equivalent to what is activated by the WiiMC menu functions. But in terms of testing the concept, better to get something/anything working and then refine it.

Anyway, I have been slowly downloading/installing/testing the necessary bits to compile WiiMC on my windows system so I can have a go at this. So I am interested in your experience trying to compile. I understand you have still not managed to compile in linux (http://www.wiimc.org/forum/viewtopic.php?f=5&t=1378&hilit=compiling+instructions), did you ever successfully compile under windows?

Cheers,
fttb

[Mug-why]

Ok, thanks.

After having a look at the code in the repository I may have some small idea what is going on. Would appreciate any thoughts/comments…

Seems like the MPlayer underneath WiiMC is being given commands via mp_input_queue_cmd() (in …/mplayer/input/input.h) and various other hooks in …/mplayer/mplayer.c (e.g. lines 4726-):
http://code.google.com/p/wiimc/source/browse/trunk/source/mplayer/mplayer.c

/****************************************************************************

* Wii hooks

***************************************************************************/



void wiiLoadFile(char *_filename, char *_partitionlabel)

{

if (partitionlabel)

free(partitionlabel);

partitionlabel = (_partitionlabel) ? strdup(_partitionlabel) : strdup("");



if(filename)

free(filename);

filename = strdup(_filename);



}



void wiiGotoGui()

{

mp_cmd_t * cmd = calloc( 1,sizeof( *cmd ) );

cmd->id=MP_CMD_QUIT;

cmd->name=strdup("quit");

mp_input_queue_cmd(cmd);

}



void wiiPause()

{

mp_cmd_t * cmd = calloc( 1,sizeof( *cmd ) );

cmd->id=MP_CMD_PAUSE;

cmd->name=strdup("pause");

mp_input_queue_cmd(cmd);

}



etc...

The “main loop” is in …/wiimc.cpp (lines 708-):
http://code.google.com/p/wiimc/source/browse/tags/1.1.8/source/wiimc.cpp

// create GUI thread



while(1)

{

ResetVideo_Menu();

WiiMenu();



if(ExitRequested)

break;



MPlayerMenu();

}



// application exiting

StopGX();

UnmountAllDevices();



etc...

What this seems to be doing is using WiiMenu() to find out what kind of file to play, then handing control to MenuBrowse() to select the particular file etc, then using the …/mplayer/mplayer.c hooks above.

There seem to be various threads active, some for the GUI’s, some for MPlayer.

Seems to me the theoretical solution would be to:
* include source from something like WiiWebServer (http://wiibrew.org/wiki/Wii_Web_Server);
* somewhere in wiimc.cpp before the main loop, fire up another thread that sleeps most of the time but listens occasionally to the httpd, and serves some kind of logfile (which could perhaps be an echo all the stdio output?), and implements a few simple commands (using the “hook” calls above) based on what it receives.

That would be a start anyway.

This is a pretty ambitous thing for me to contemplate (I mainly use VB/excel). Does this interest anyone? Does this sound sensible/insane?

Cheers,
fttb.

[Mug-why]

Hi jhb50, thanks for dropping by, and thanks for your suggestion. 🙂

Its not really a “problem” – there are lots of reasons why a remote interface would be helpful and fun, this is just one.

But to explain my particular situation: I turn off the projector to save bulb life (we are often playing music this way for most of the day), because it gets very hot, and because it makes noise when its running. And the issue is that it takes quite a bit of time for the thing to turn itself off and on, and its in a slightly inconvenient location etc.

Also, while its an excellent feature to be able to use the WiiMote to do things within a playlist(s) as you have described, if I want to select something that is not within what has been set up initially (or do anything more complicated than what you have described) then I need to turn on the projector to see what I’m doing. Also, in doing what you have described I am limited in terms of range of the WiiMote. And it would just be amazingly cool to be able to control WiiMC from other PC’s on the LAN (e.g. smartphone/tablet)… 😀

Certainly I could buy something like a small LCD screen with A/V connectors (less common than you’d think), but this would still be less cool than being able to control WiiMC from anything on the LAN. 😉

Anyway, I am sure there are a multitude of different reasons that the other users interested in seeing this feature can supply as well.

What do you think of Gabriel’s suggested approach below?

Can you see any way to use the “slave” facility (e.g. described here http://code.google.com/p/wiimc/source/browse/trunk/libs/libmpg123/doc/README.remote?spec=svn625&r=625) so that WiiMC would respond to commands written to it in a file/pipe in some shared location?

Thanks for your time.

Regards,
fttb.

[Mug-why]

Exactly.

To be clear, while embedding an http server and interface in WiiMC would allow for a very general level of control, I appreciate the extra difficulty involved. I wasn’t really suggesting this.

I was thinking instead, as a simpler to implement alternative solution, just the ability for other applications to feed commands to a pipe/file stored somewhere “generally available” – such as a file on a LAN share, as per:
http://code.google.com/p/wiimc/source/browse/trunk/libs/libmpg123/doc/README.remote?spec=svn625&r=625

My understanding is that doing this in conjunction with somehow activating/configuring “slave mode” in mpg123 (which seems to sit within WiiMC) would allow other applications to control WiiMC by simply writing to this file/pipe.

I was really hoping that someone with more ability had already tried to do this! 😉

Thanks,
fttb.

[Author]

Posts