One more example of an area the TRemote client can't control - Drives and Devices. Clicking on this item on the TRemote client shows the local Drives and Devices, not those of the server. So it's not possible to trigger DVD playback using TRemote.
I guess all my examples point to the same thing - the current TRemote implementation, working via the Library Server, presents quite a few limitations to remote control. Things that aren't part of the library, like a DVD drive or a randomly opened URL, cannot be triggered from the client.
What I would love to see is a remote mode whereby using the MC client is like using MC on the server in all regards (with possible exception of Open File and similar given the complexities of that.) So basically whenever something is done on the client, it would transmit that command to the server and have it perform the same operation. There would be no concept of anything local to the client, it would just be an interface to the server. It could even be a separate MC Client binary, with any features and interface items that relate only to local control removed.
I mentioned Open File as a complexity, and there are some others - for example, ideally the communication should be bi-directional, meaning that if the server MC wanted to pop up a dialogue, it would be triggered on the client as well. DVD playback is again an example here - when I put a DVD into my HTPC, MC will pop up a dialogue asking if I should play it or take no action. Ideally this dialogue would be triggered on the client so that the client can be used to make the decision.
So really what I'm describing is a facility which is just like controlling the server MC via remote desktop sharing like VNC or RDP, except implemented with a thick local client.
I think this would also answer the issues raised by others earlier in this thread - by decoupling client control from the library server, that would allow one to run a library server at the same time without interference.
Although the above may be complex or difficult, I do feel that it will be necessary in order to realise the vision of controlling MC from a tablet PC/netbook/etc. In order for those to be effective, the client needs to be able to trigger a complete range of server functions, and any concept of 'local' would be irrelevant and distracting, because the device exists only to control the server. If this can be achieved, then I think those devices will be a superb way of controlling a complex home theater without ever needing to access the server with a keyboard or mouse (or very rarely.)
(Final point - if the above were to be implemented, then this would also be an excellent chance for developers; J River could release the API that is used by the client to control the server. That would allow development of alternative, customised client interfaces by the community. This opens up all sorts of possibilities.- for example if I could trigger TV recording with a remote API call, then I could develop a simple email interface allowing me to email home if I forgot to record a program
I could maybe do this today by triggering MCC.exe, but I'd need to find my own way of executing that remotely on my MC server; a remote API that provides access to all MC features would be much more powerful. )