New Webinterface (1 Viewer)

[STSC]

I already started developing a new "External Server Control Plugin". You can find the sources here. Be aware that is only a first try:

http://pvr-scheduler.de/Downloads/c=2.html

Because of compatiblity issues I would not rewrite the External Control Plugin II. You can still use it to control the MP client without the TVE2.

The External Server Control Plugin is currently written in VB .NET but if it would help I can rewrite it in C#.

 

[STSC]

Alright, just to keep the momentum going, I've just completed the client discovery code for the ECP2 plugin. This means that any program can send a standard UDP multicast and all MP clients with ECP2 loaded will respond. The program can then use this info and use ECP2 to connect to and control a particular client.

I'm not sure how an UDP multicast works, but I would do it like this.
Implement a small socket server in the MediaPortal TV service. Every client can now connect to this server. If one of the clients sends a request to the server, the server will tell the other clients that there's an update available (or whatever).

Now the ESCP (External Server Control Plugin or ECP2 for TVE3) is used (as you already wrote) to get the information.

 

[AdmiralUD]

I wonder if it would make sense to break this apart into 2 things. As I see it there are kind of 2 groups of functionality here:

1. Information display/manipulation: Show guide, add recording, view music, listen to music, etc...

2. Remote control: Control MP directly...change channel, next song, etc...

I am curious what the benefits are of combining them? With the new architecture I don't think 1 requires 2...I think all of this data would be available with db queries of some kind either straight SQL or using the built in TvBusinessLayer.

Just an idea.

 

[Maschine]

Hey guys,

wow, suddenly there is big action in this thread and it seems we will have multiple webinterfaces for MP soon

Actually I also work on a all new webinterface for the upcoming TV Server. Now that the TV Server works with SW encoding cards I could finally start. Here's what I've done so far:

I have a sample page up and running which gets "now on air" and "next on air" from the TV Server. That all is done in asp.net with the asp.net AJAX framework. Well I have to say that was really fun to work on as all those things are going real smooth in the vs.net ide

But other than the Admiral I began to care about a suitable server application for my just created sample page. I started to dive into the Cassini hell which caused me some really really bad hours - and I still haven't it working yet. Misterd, thanks for the "Hevea" hint, I'll look at that when finished this posting. You don't believe how happy I'd be if that's something for our needs

I also had a nice chat with Sam earlier this day - so the "old team" is also working on "new" things

I think we all here should join forces and develop a common webinterface instead of brewing our own things everybody. So I hope this discussion will stay active a little longer than it happened in the past...

for reading

Maschine

 

[misterd]

Hi,
I think this time we all have the same basic idea and it should be possible to create this new web interface. I must say that I haven't implemented anything at the moment. I just thought about the architecture and technologies, especially the server part. The result is that I think Hevea could be the easiest way.

For those who want more information about Hevea: http://hevea.sourceforge.net/

At the moment I'm working on my own plugin but after this I could help to implement an sample service with Hevea. Then we could combine this service with admirals and/or maschines test web application. I think it is easier to talk about the main architecture, if we have such a sample application. The exact feature list can be discussed after this. Other suggestions for the next steps are welcome.

Regards,
MisterD

 

[Bram]

I love the sparkling enthusiasm in this thread.
The only thing that will not help MP, is to make it even more platform dependent. misterd his suggestion to use GPL software for the application server sounds wise. It would also be a good idea to keep Mono (the Unix interpretation of .NET) in mind. Mono developers are really busy with devloping and cross-platform .NET is comming closer every day. The TVserver3 is supporting MySQL and might run on a Unix machine in a while (Mono). Then, only the client will have to run on a Windows machine because of DirectX. Storage of media, databases..... I'm already dreaming of a "MP server Linux distribution"...working right out of the box

Smart choises will make MP much more flexible, now end in the future.

I would love to help writing a webinterface. My only real experience is with php/AJAX (professionaly). I'm learning C#.

 

[AdmiralUD]

I love the sparkling enthusiasm in this thread.
The only thing that will not help MP, is to make it even more platform dependent. misterd his suggestion to use GPL software for the application server sounds wise. It would also be a good idea to keep Mono (the Unix interpretation of .NET) in mind. Mono developers are really busy with devloping and cross-platform .NET is comming closer every day. The TVserver3 is supporting MySQL and might run on a Unix machine in a while (Mono). Then, only the client will have to run on a Windows machine because of DirectX. Storage of media, databases..... I'm already dreaming of a "MP server Linux distribution"...working right out of the box

Smart choises will make MP much more flexible, now end in the future.

I would love to help writing a webinterface. My only real experience is with php/AJAX (professionaly). I'm learning C#.

I'm not sure I would go as far as to say it will not help MP, but it is something to consider. Also keep in mind, this is a plugin not modifications to the core of MP...if you are trying to run it on linux, dont install the plugin. I am not sure about the state of asp.net ajax on mono, but I suspect it is not up to date as it has just recently come out.

The one thing I am hesitant to do here is to overcomplicate the issue (thus my suggestion about dividing this into 2 pieces of functionality). I see lots of great ideas being expressed here but I think it could easily spin out of control if too many things try to happen at once. Just my .02

 

[samuel337]

Instead of cassini I would prefer: Hevea. Hevea is also an application server written in C# and licensed under GPL.

http://hevea.sourceforge.net/

Hmm, looks good. I'm for using this instead in principle; will have to see how it works in reality.

I would prefer to write an own windows service which uses Hevea or cassini and not to use IIS to avoid problems (XP Home, installation etc.). The web application can be developed with IIS of course, but the whole web interface should be released as one package.

I agree completely. The IIS option is there purely because some people already have web servers running and want it on that computer. It won't be the standard/recommend/supportedway of running it.

I have attached a small diagram of a possible architecture of such a windows service. I would like to help with the windows service, web service and my suggest abstraction layer.

There was going to be some sort of abstraction layer; I just hadn't gotten that far yet. But you're proposing an abstraction layer used by both the web service and web app right? Can I ask what sort of abstraction you're proposing?

I already started developing a new "External Server Control Plugin". You can find the sources here. Be aware that is only a first try:

http://pvr-scheduler.de/Downloads/c=2.html

Because of compatiblity issues I would not rewrite the External Control Plugin II. You can still use it to control the MP client without the TVE2.

I couldn't be bothered getting an account to get access, but I assume that your plugin is a plugin for the TV server right? How does it differ from TvControl.dll?

Just to clarify for everyone; ECP2 is for controlling MP clients, and only to be installed on MP clients.

I'm not sure how an UDP multicast works, but I would do it like this.
Implement a small socket server in the MediaPortal TV service. Every client can now connect to this server. If one of the clients sends a request to the server, the server will tell the other clients that there's an update available (or whatever).

What kind of requests are you talking about?

I created a general UDPMCHelper class to implement this, so if you want, go to the mp-webinterface sf SVN repo, and get the file in trunk\source\ECP2Assembly\clsUdpMCHelper.cs. It should be pretty straight forward to use.

This is different to the UdpHelper class in MP btw, which is a unicast Udp helper.

I wonder if it would make sense to break this apart into 2 things. As I see it there are kind of 2 groups of functionality here:

1. Information display/manipulation: Show guide, add recording, view music, listen to music, etc...

2. Remote control: Control MP directly...change channel, next song, etc...

I am curious what the benefits are of combining them? With the new architecture I don't think 1 requires 2...I think all of this data would be available with db queries of some kind either straight SQL or using the built in TvBusinessLayer.

Well, it doesn't really make sense to have two web interfaces, one for controlling it and another for the TV server. BTW, as the music databases are still client-based, it would be quite tedious to use straight SQL and connect to each SQLite database individually (e.g. you'd have to ensure that each MP client has the database folder shared first).

The remote control feature isn't just your typical remote control. Imagine you're watching a channel while you're browsing the web interface tv guide, discover something good on another channel, and all you'd have to do is click the program, select an MP client and it'll automatically switch that client to that channel.

----------

I think right now there's really two parts to this project: one is the main web interface, and the other is the web server and other communication components. I think the first target for the project is to get the TV functionality working first. We already have the TvBusinessLayer and TvControl, so apart from the web server and ECP2 (which will only play a minor role initially), the backend bits are mostly there already.

Most of you already have some sort of web server going on anyway, so I think work on the web interface should be able to go forward from ideas to actual implementations.

One question though - are we discontinuing any support for the old tv engine in this new web interface?

I might shift my attention over to working on the web server for the time being, seeing as its the most needed component at the moment.

I love this momentum

Sam

 

[Bram]

Please do not skip the 'old' TV engine. I've tried the TVserver3 many times now. I'm sticking with the old TVengine. I think it will take at least a year (maybe even two) before the new engine will be a standard component in MP. There is not yet a way to include all components needed in one installer (this is not possible for SQLexpress). It's been discussed and there seems to be no real interest to make it easier to implement the TVengine. Untill that happens the TVserver/client 3 will not be a standard. If you ask me, it could well be that MP is going to stick with the 'old' TVengine and upgrade it. The TVengine 3 could be optional forever.


Is it possible to make the webservice support php?

 

[MJGraf]

Hello everyone,

although, unfortunately, I can't help you very much with this very exciting project, I just wanted to drop my 2 cents:

samuel: I completely agree that it would be great to have one unique remote / web interface. The problem now is that we have the "old" web interface, a remote interface for pdas etc. If we had just one interface for everything that can be controlled remotely (be it changing channels "live" while watching with a Windows Mobile device or scheduling a recording over the internet) it would be much easier for all the plugin developers to just use this interface and write a client application in whatever environment they want: WM devices, browsers, mobiles etc.

Thanks to all of you and please keep this up,

Michael