MPAnywhere - a proof of concept for an MP2 webservice and webinterface (2 Viewers)

[FreakyJ]

yeah MPExtended could use the api provided by the plugin to access MP2 so an integration of MP2 in MPExtended would be possible But I think that won't happen in the near future because oxan said he doesn't want to spend so much time on MPE anymore...

I love MPExtended, so I don't want a fight

 

[Oxan]

I'm going to read the whole thread later tonight and see where we can work together. Just wanted to do a quick comment on these items right now, expect a longer, more informed and better comment tonight.

MP2 brings an entirely new architecture to the table.
- MP2 Server that already always runs as service (no need to install an additional Service as for MP1)

Great, so we can load MPExtended as a plugin into that process. There's about 20 service-specific lines of code in MPExtended, the rest can just as easily be loaded into another process.

- MP2 abstracts it's database - it is not a good idea to directly access it - rather use the provides core code classes

Yes, we should do that. It's supported by MPExtended. (I actually want to do that for some MP1 plugins too, but didn't get to it yet).

- There are not x plugins of which to read the DB from - only a single DB with MediaItems of different
types

Great, that makes it a lot easier to implement support for the MP2 database in MPExtended.

This are all points with which MPExtended can integrate really well. MPExtended isn't that much integrated with MP1 at all, in fact, only the plugins which read from the database are MP1-specific. The rest has a very clean design and can integrate with MP2 just as easy (implementing that is high on my todo list, actually).

 

[offbyone]

Great! Looking forward to use MP2 Server with my ampdroid

 

[FreakyJ]

but we would still need MPanywhere to get rid of IIS right? Could WebMediaportal be hosted on MPAnywhere?

Do we have two options to choose from in the end? Should we somehow join forces?

 

[Lyfesaver74]

Thats just it. You dont even need MP1 or MP2 for MPE/WebMP to work (you do if you need live TV). MPE is pretty much a stand-alone project that reads DB files and uses that info. It does not tie in directly with any version of MP. Was not trying to make this a MP1 vs MP2, was trying to make sure it did not end up that way.

2ndly, I like MjGraf and his skills. Oxan, DieBagger @ myself have been BEGGING for people to help out with MPE (development wise). Oxan has pretty much (with some help from DieBagger) wrote the whole thing by himself. And after long time asking, it is almost a slap in the face to have someone write something new (I know the goal was for MP2, but MPE can be for MP2) when MPE needs help. Sorry, if my point came across wrong.

 

[Oxan]

(For those of you who don't know yet, I'm the lead MPExtended developer).

Let's try to keep it constructive. I can understand that people feel that MPExtended is overlooked, and I can't really blame them because proposals like this tend to get more enthusiasm than MPExtended, even though MPExtended can almost do what is propsed. However, that's probably partly caused by our severly lacking documentation and PR-efforts inside the team. In any case, let's try to keep it constructive here and see if we can build something great together.

I'll start by clearing up some technical details about MPExtended, since I think it can do more than most of you know (for which I really can't blame you, cause this stuff is only documented in the source). Then, I'll detail where I think we can work together and what's the best way forward, and finally I'll offer some technical comments on the proposed MPAnywhere design.

About MPExtended
MPExtended isn't tied to or integrated with MP1 in any way. There's just a tiny amount of code that's MP1-specific: the plugins that load the data from the databases. The rest is all generic and can support MP2 just as easily. The only thing that's needed to get MPExtended to use the MP2 database is to implement a plugin that reads data from the MP2 database (the interface is quite simple actually). Everything else is already covered.

The MPExtended service is currently distributed as a separate Windows service, but that's not really a design requirement. Everything can be loaded from any other process as well. (In fact, the whole service executable contains just 20 lines of code). We should create an MP2 plugin that hosts the MPExtended service from the MP2 server. There'll be some rewiring required to unify logging and maybe configuration, but you probably can get it running in an hour or two.

WebMediaPortal currently requires IIS or IIS Express, that's correct. However, it's not really a hard dependency, we just need something to host our ASP.NET MVC application. Last time I tried to make it usable without IIS that wasn't possible yet due to some limitations in the ASP.NET stack. It seems Microsoft has made some progress on this, so it might be possible now (using the same HTTP server proposed for MPAnywhere). I'll look into doing that, it would certainly be a step forward for WebMediaPortal.

MPExtended and MPAnywhere
I think the biggest advantage of MPExtended is that it's already implemented. We already have a fully-implemented API for retrieving media data (which supports both SOAP and REST). The backend behind it is actually even more powerful (and a bit cleaner), so an alternative OData API shouldn't be too hard to implement.

We also offer an out-of-the-box streaming API (see here and here), including transcoding support, picture resizing and more stuff like that. It's very easy to underestimate the effort required to implement streaming and especially transcoding. We've spend countless hours on bugs in transcoding obscure combinations of video codecs, audio codecs and containers. Getting it working is easy, getting it working well is very hard. (You proposed to let the client specify bitrate and video resolution. I'm afraid that really won't work, since a lot of these combinations will either be refused by libavcodec (the codec library used in ffmpeg, ffdshow and VLC), crash libavcodec or produce a stream that can't be played back on the device that requested it. You really want to have tested settings).

We don't have any support for editing data though. I expect that'd be quite hard to implement in the current MPExtended design actually, since we map the underlying types from the backend (which an be MP2, MovingPictures, MyFilms, etc.) to generic types that don't contain any implementation-specific data. I think it's still necessary for MP2 to have its own API for changing data, since I don't expect MPExtended will be offering this soon.

I think the best way forward is to go ahead with the ASPNETWebStack plugin and a plugin to implement an API for changing data. The ASPNETWebStack plugin will likely be used by WebMP as well (once it's embeddable). Then, I'd suggest to implement the web interface itself as a skin or plugin for WebMediaPortal, along with a data provider plugin for MPExtended. That way you get streaming support, a media browser, a TV interface and skinning support for free. WebMP is quite flexible, you can implement and override controllers in a plugin, and override all default view files as well. You could even build a completely new interface upon WebMP, reusing only what you like. It requires you to use ASP.NET MVC on the server-side though, but I think that's not really a downside.

WebMP will probably require some minor changes for that to happen though. For example, we don't really have a way to register menu items from plugins currently (hardcoded in the skin at the moment). I really like your menu idea, so I'm going to implement something like it in WebMP. If you decide to go down this route, we can discuss and make other changes to WebMP as well.

The other advantage of integrating with the MPExtended API is that you get client support for free: native apps for Windows Phone 8, Android and iOS will be fully functional (except the remote section). Implementing the full spectrum of native apps again for MP2 will probably take years and be a waste of effort (in my opinion).

What I'll do

• Try to get WebMP working using the ASP.NET self-hosting API as well, so that we can get rid of the IIS dependency
• Implement a MP2 plugin that hosts the MPExtended service in the MP2 server, so that we can get rid of the separate process
• Implement a plugin for MPExtended that uses the MP2 database to load its data

(Of course, if others beat me to doing these things, that'd be great. All help is welcome.)

Comments on the MPAnywhere proposal itself, if you don't go the MPExtended-integrated route
I think the ClientType enum you propose is a bad idea to have hardcoded. When we started working on MPExtended, tablets didn't even exist yet. These things change quickly nowadays, and there will probably be a new common formfactor in a couple of years (think about Google Glass, smartwatches, etc. In fact, I bet we'll get the first request to support streaming to Google Glass in less than a year). It's better to make this flexible in a way that doesn't require changes to all plugins to add a new interfaces.

Distinguishing phones and tablets is also a lot harder than you'd think: server-side you only have access to the User-Agent, which is an evolving mess (that includes less information every year). It doesn't give any guarantee about correctness either: a lot of cheap Android tablets from China actually ship with the User-Agent that's supposed to be used only on phones. You also have the problem that there's no clear line between phones and tablets: what about the Galaxy Mega? It has a 6.3" screen, you can't use it with one hand and it looks more like a tablet than a phone, but it's sold as a phone. People use it as both.

Something else: have you thought about skinning for MPAnywhere? I didn't implement it in the initial WebMP version, and it quickly became one of the most common feature requests. One of the reasons users choose MP is that it is easily customizable, and they'll want that from the web interface as well. It's a lot easier to integrate skinning into the design at this stage, so you should take advantage of that.

Some specific comments

BTW: I wouldn't use Flash since this doesn't work on any IDevice. I would much more prefer transcoding to mp4 for Videos and mp3 for Music. That way we can use html5 to Display it.

Transcoding to MP4 isn't possible. The MP4 container requires some metadata that can only be calculated once the encoding is done to be present at the start of the file.

Correcting myself:
For Creating: http-Post
For Reading: http-Get
For Updating: http-Put
For Deleting: http-Delete
Source for this is here. And it also states that for Post requests, it expects the data of complex types in the body of the request.

Yes, this. Using POST for updating and deleting is also generally accepted, but you really shouldn't be using GET for that (browsers *will* screw up if you do that).

 

[Lyfesaver74]

awesome, thank you for such detailed comments, oxan =)

 

[MJGraf]

Well, back from work and maybe I should clarify a few points:

• The original idea of MPAnywhere was to be able to edit MediaItemAspects of MP2 (i.e. the metadata that is collected by MP2 about your MediaItems). This could be done by a standalone application or a webinterface. I personally liked the idea of a webinterface because
  • it is platform independent and
  • you don't have to install another application.
• The next question was: How does the webinterface access the data from MP2.
  • UPnP was discussed, but accessing UPnP from a webclient (in particular since we don't use DLNA standard) is not easy.
  • WCF was also discussed, but from what I read it is more bound to Micrsoft than the other technologies, it's more "heavy-weight" and not as easy to access as Web API.
  • Therefore I landed at ASP.Net Web API (maybe using its OData extension).
• This brought us to the question on how to host that. Well, MP2 is not only an MP2 Server and an MP2 client application, it is in general a framework for developing such applications. That means, it has everything inbuilt that you need in connection with media. Therefore, IIS was out of the question. When we need a server service, we have to build it into MP2. That's the reason why ASP.Net Webstack came into play.
• Now I wrote the ASPNetWebstack plugin - built in the MP2 spirit as "Service" in the application, which can be used by any other plugin.
• Then we needed a http file server to host the webinterface files. I could have used the already inbuilt http server of MP2, but since we now had ASPNetWebstack, I used this one (thinking about maybe exchanging the inbuilt http server later with ASPNetWebStack).
• Now it was time for an interface. I thought about a menu structure and now for the first time I thought that we could use the webinterface for other things as well. The first thing that came to my mind was MP2 settings. We need some kind of a settings application because we don't have all our settings in the UI (keeping things simple... Nevertheless, there may be people who want to fiddle with more detailed settings and therefore we need an app). So the idea was born use the webinterface for settings as well.
• This again made me rethink some of the ideas I already implemented. I realized that the webinterface may be used for many more things than just edit MediaItemAspects and Settings. But I would certainly not be able to provide all this functionality. I therefore redesigned all I already had in a way that made it extendable.
• Now that this was done it was time to think about the design of the webinterface. I, personally, don't like the - just wanted to write "look and feel" but that's wrong, I just don't like the "feel" of server driven webinterfaces such as ASP.Net MVC applications (sorry, Oxan, no pun intended - I loooooove WebMP ). I have no problem with waiting 5 seconds until the web application has loaded but then it has to be "snappy"! And this can be achieved easily by a single page application making heavily use of js. I looked around (and I think someone even mentioned Sencha Touch in the other thread) and so I came to Sencha Touch. I was heavily impressed, tried it and realized that it is breathtaking on touch devices but ok'ish on browsers on a computer. So I found extjs, which is breathtaking on computers, but ok'ish on touch devices.
• That was finally the reason for again rewriting a lot of what I already had to make the whole thing aware of the device by which it is used and use both, extjs and sencha touch

Now that's where we are. And as you might have noticed, nothing of the above is in any way related to WebMP or MPExtended. So this is in the first place not a "competitor" of MPExtended or WebMP. It's something completely different.

Finally we have realized that we may also use this in a way that provides services, which are also provided by WebMP - such as streaming media. Well, ok, I have to think about this...

My preliminary opinion about this is that yes, there may be an overlap between the two, but it's not that big as it might seem. As stated above, MPE/WebMP are completely separate from MP1 and MP2 and can be used with other applications as well. MPAnywhere is just for MP2 and this is the only thing I - personally - am interested in. So everything in MPE/WebMP which covers other applications than MP2 is not an overlap. On the other hand, MPAnywhere can (and should) be used for many more things than streaming media. So anything but streaming media (and maybe scheduling recordings) is not an overlap either (using MPAnywhere as a remote for MP2, Setting of MP2 Server / Clients, Editing MediaItemAspects, etc.).
Having said that, for the part that overlap, we should definitely combine forces. I WILL have a deep look into the MPE codebase and I'm sure there is a lot that can be used (such as transcoding, etc.).
But I fear it is not done by just hooking MPE into the MP2 service. MP2 follows a certain concept - and even if the codebase of MPE is perfect (and I'm convinced it is when I head Oxan talking about the MP1 codebase ) that does not mean it completely fits the MP2 concept. Let me explain that by way of an example:
At some point in time we will need something like a transcoding service in MP2. MPE can already transcode. But in MP2 I see the transcoding service as a separate plugin just for the purpose of transcoding. The reason behind that is that transcoding may not only be used by this webinterface. There are so many possibilities in which you may need transcoding, that it definitiely would make sense to have a service registered in our MP2 ServiceRegistration so that other plugins can use it. This in turn means that we certainly can use 90% of the transcoding part of MPE's codebase. But these 90% have to be separated from MPE and wrapped into an MP2 plugin. This is at least my personal opinion about this and it may take longer than just to hook MPE into MP2. But on the other hand, new developers interested in MP2 (such as me 3 years ago) can much more easily understand the concept of how MP2 can be extended.

Well, that's where we stand - and now I'll dive into the code again and see what we can get out of our MediaLibrary into the Web API...

Michael

 

[MJGraf]

ok, no coding, yet, first of all thank you very much for your detailed comments, Oxan. That helps a lot...
I think I will need some more time to get an overview over the MPE codebase. It seems like I start to talk about things I don't really know and I don't like that
First thoughts as follows:

• We need a way to edit metadata in MP2 so we need a separate API for that.
• If we implement a separate API for Create, Update and Delete, it doesn't really make sense to use the MPE API for Read....

Really have to think about the rest...
What bugs me a bit (but this is really only a first gut feeling) is that I don't like the idea that MP2 provides a service which gives you access to media that are not in the MP2 database and, hence, cannot be accessed by MP2 Client. I like more the idea of having metadata from other sources (such as XBMC, etc.) imported into the MP2 library and having RecourceAccessors that enable MP2 to play these resources in MP2 client. Maybe I should paint a sketch about what I mean....

Again, let me think about all this and please continue the discussion. It's great...

And finally: It was never my intention to overlook MPE. As mentioned, I really like it and I use it. But this whole thing started from a completely different direction....

Michael

 

[Oxan]

And finally: It was never my intention to overlook MPE. As mentioned, I really like it and I use it. But this whole thing started from a completely different direction....

Don't worry about it. I never thought your intention towards MPExtended was negative, and overlooking was probably a too big word. Let's forget it and just build something great together

Now that this was done it was time to think about the design of the webinterface. I, personally, don't like the - just wanted to write "look and feel" but that's wrong, I just don't like the "feel" of server driven webinterfaces such as ASP.Net MVC applications (sorry, Oxan, no pun intended - I loooooove WebMP ). I have no problem with waiting 5 seconds until the web application has loaded but then it has to be "snappy"! And this can be achieved easily by a single page application making heavily use of js. I looked around (and I think someone even mentioned Sencha Touch in the other thread) and so I came to Sencha Touch. I was heavily impressed, tried it and realized that it is breathtaking on touch devices but ok'ish on browsers on a computer. So I found extjs, which is breathtaking on computers, but ok'ish on touch devices.

Ah, but even that's possible with WebMP nowadays. I'm almost finished with supporting return of JSON data in all controllers in WebMP (already possible from the service), so that you can load everything from JavaScript and don't need to reload the page at all. Just the client-side implementation is still needed to get a single-page WebMP.

Now that's where we are. And as you might have noticed, nothing of the above is in any way related to WebMP or MPExtended. So this is in the first place not a "competitor" of MPExtended or WebMP. It's something completely different.

Sure, you're right here. MPAnywhere is coming from a completely different direction (hence my my reply wasn't simply "why are you reimplementing MPExtended?" ) The thing is, we're both heading in more or less the same direction. Things like remote support will eventually get implemented in WebMP. While writing WebMP I've also discovered that you need to do quite some infrastructural work that's not really interesting to do and can probably be shared as well. Having a common infrastructure also makes it more easy to write a web plugin that's used by both MP1 and MP2 users.

Regarding your transcoding example, I think you're right but you underestimate the flexibility of MPExtended. The only coupling of services happens at the service layer, the rest is all generic. The 10% that has to be changed for MP2 can be quite easily separated and implemented in MP2-style, and we should do that. I think integrating the full MPExtended solution as an MP2 plugin is a good first step, but shouldn't be the last step. We can and should definitely continue forward from that point.

I think the best outcome is to end up with a series of plugins like this (using streaming as an example, but we can do the same for our other services where it's useful):

• MPExtended.PlugIns.MP2.TranscodingEngine -> contains the transcoding engine with a low-level API
• MPExtended.PlugIns.MP2.Transcoding -> offers an MP2-style API for the transcoding engine to other MP2 plugins
• MPExtended.PlugIns.MP2.NativeApi -> offers the native MPExtended API for the transcoding engine to users outside MP2 (i.e. the mobile applications and WebMP)

First thoughts as follows:

We need a way to edit metadata in MP2 so we need a separate API for that.
If we implement a separate API for Create, Update and Delete, it doesn't really make sense to use the MPE API for Read....

Yeah, that's a good point. For the "MediaItemAspectsEditor" it's probably better to don't have any connection to MPExtended at all. However, I expect that once you have that implemented, you (or others) will want to extend the interface and implement media browsers and other stuff which can easily be implemented reusing the MPExtended API and WebMP code. We'd have a duplicate API then though, and I can see the downside of that.

(In reality, I'm afraid we're going to end up with a duplicate API anyway. The native MP2 API (probably used by MPAnywhere) and the more generic MPExtended API, which will support the MP2 database and be used by existing mobile clients and maybe some MPAnywhere plugins).

What bugs me a bit (but this is really only a first gut feeling) is that I don't like the idea that MP2 provides a service which gives you access to media that are not in the MP2 database and, hence, cannot be accessed by MP2 Client.

We can limit the MPExtended hosted by MP2 to only load the MP2 plugin (and thus only use the MP2 database). I think that's quite sensible actually, since I doubt anyone is running both an active MP1 and MP2 setup.