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

[MJGraf]

This all sounds like a damn good plan
Now we just need to found New-SAP, make an IPO, have some billions on our accounts and as a result plenty of time to get all this done
But hey, there's a German saying, that can be translated like "When you build castles in the air you shouldn't skimp on stones" (hope that is understandable). So let's get the party started!

I'm sitting here in front of my Tv (MP1 of course) a Becks on my table, my laptop in front of me and I have plenty of ideas... The idea I had after the second beer was: When we have MPE in MP2, why shouldn't we use MPE as a "bridge" to import MediaItems from other apps such as MP1 (Moving Pictures, etc.), XBMC and whatever else MPE supports into the MP2 MediaLibrary? Build some MetadataExtractors that access MPE's WCF services and just import all that stuff. Then we build some ResourceProviders making use of MPE's streaming capabilities to play all that stuff in MP2 client. Maybe this would finally attract some more users to MP2 because they CAN have immediate access to all their beloved Media in MP1 / XBMC directly from MP2.
The more I think about it, the more I like the idea... Need some more beer

Michael

 

[MJGraf]

But before we forget about it, here is the WebApi wired up to the MediaLibrary.
This is really extremely interesting - I think I already found two bugs somewhere deep in the MediaLibrary. Will investigate further and post to Jira when I have identified them. This is just by being able to "see" your MediaItem objects in your browser - amazing
The Plugin is still called "EditMediaItems" (still need to rename it). Binaries and Source of this plugin attached. Just leave the other two from the first thread installed and replace MPAnywhere.EditMediaItems with the one attached to this thread.
I have only imported exactly one music file into my library for testing purposes. I have no idea how many MediaItems the service can handle before it gives up, so let's try and see (in particular the fact that also the album covers are transferred, I suppose as base64-encoded binaries, makes the responses quite big) so be careful when you list all your MediaItems
I have to mention that this was really soooooo easy, i can't believe it. I have three controllers and every controller consists of 5 or 6 lines of code. And probably 3 lines would be enough, if we don't have to debug anymore and set breakpoints, etc. The rest is all done in the WebAPI.

So here are my results with just one music library:
http://MP2ServerName:81/api/MediaItems
gives me:

[edit:] Sorry, guys, I haven't found a way to export xml, which is displayed beautifully in Firefox, in a way so that it keeps the line breaks, so if you really want to see the beauty, install it and use firefox...

<ArrayOfMediaItem><MediaItem Id="2c3f7296-6496-4522-b749-06d7a516c65e"><Aspect Id="17af940c-66ce-4d23-9d06-bf7f21c04201"><Attr Name="Title"><Val>Music</Val></Attr><Attr Name="MimeType"><Val i:null="true"/></Attr><Attr Name="RecordingTime"><Val>1900-01-01T00:00:00</Val></Attr><Attr Name="Rating"><Val>0</Val></Attr><Attr Name="Comment"><Val i:null="true"/></Attr><Attr Name="PlayCount"><Val i:null="true"/></Attr><Attr Name="LastPlayed"><Val>1900-01-01T00:00:00</Val></Attr></Aspect><Aspect Id="0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed"><Attr Name="System-Id"><Val>14969200-a7b6-470e-9bfb-e66bef6fd100</Val></Attr><Attr Name="Path"><Val>{e88e64a8-0233-4fdf-ba27-0b44c6a39ae9}:///C:/_MP/Media/Music/</Val></Attr><Attr Name="ParentDirectory"><Val>00000000-0000-0000-0000-000000000000</Val></Attr></Aspect><Aspect Id="cc0163fe-55a5-426c-a29c-f1d64af7e683"><Attr Name="LastImportDate"><Val>2013-07-29T23:13:27.71</Val></Attr><Attr Name="Dirty"><Val>false</Val></Attr><Attr Name="DateAdded"><Val>2013-07-29T23:13:27.71</Val></Attr></Aspect><Aspect Id="1eeef2d0-d52f-40f7-a12a-9908c2daed1a"/></MediaItem><MediaItem Id="99355325-d729-4e18-aca2-bf09d18a9714"><Aspect Id="17af940c-66ce-4d23-9d06-bf7f21c04201"><Attr Name="Title"><Val>Future Proof</Val></Attr><Attr Name="MimeType"><Val i:null="true"/></Attr><Attr Name="RecordingTime"><Val>2003-01-01T00:00:00</Val></Attr><Attr Name="Rating"><Val i:null="true"/></Attr><Attr Name="Comment"><Val i:null="true"/></Attr><Attr Name="PlayCount"><Val i:null="true"/></Attr><Attr Name="LastPlayed"><Val i:null="true"/></Attr></Aspect><Aspect Id="0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed"><Attr Name="System-Id"><Val>14969200-a7b6-470e-9bfb-e66bef6fd100</Val></Attr><Attr Name="Path"><Val>{e88e64a8-0233-4fdf-ba27-0b44c6a39ae9}:///C:/_MP/Media/Music/01 - Future Proof.mp3</Val></Attr><Attr Name="ParentDirectory"><Val>2c3f7296-6496-4522-b749-06d7a516c65e</Val></Attr></Aspect><Aspect Id="cc0163fe-55a5-426c-a29c-f1d64af7e683"><Attr Name="LastImportDate"><Val>2013-07-29T23:13:29.167</Val></Attr><Attr Name="Dirty"><Val>false</Val></Attr><Attr Name="DateAdded"><Val>2013-07-29T23:13:29.167</Val></Attr></Aspect><Aspect Id="493f2b3b-8025-4db1-80dc-c3cd39683c9f"><Attr Name="Artists"><Val>Massive Attack</Val></Attr><Attr Name="Album"><Val>100th Window</Val></Attr><Attr Name="Genres"><Val>Electronica</Val><Val>Trip-Hop</Val><Val>Downtempo</Val><Val>Ambient</Val><Val>Alternative</Val></Attr><Attr Name="Duration"><Val>341</Val></Attr><Attr Name="Track"><Val>1</Val></Attr><Attr Name="NumTracks"><Val>10</Val></Attr><Attr Name="AlbumArtists"><Val>Massive Attack</Val></Attr><Attr Name="Composers"><Val>Robert Del Naja</Val><Val>Neil Davidge</Val></Attr><Attr Name="Encoding"><Val i:null="true"/></Attr><Attr Name="BitRate"><Val>192</Val></Attr><Attr Name="DiscId"><Val i:null="true"/></Attr><Attr Name="NumDiscs"><Val i:null="true"/></Attr></Aspect><Aspect Id="a61846e9-0910-499d-9868-a1fabce7ccfd"><Attr Name="Thumbnail"><Val i:null="true"/></Attr></Aspect><Aspect Id="1fda5774-9ac5-4873-926c-e84e3c36a966"><Attr Name="Thumbnail"><Val>/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4[...taking this out because it's too long...]/BQORFqI+l41FFHM+4ER+Cvgd3LtDqRY9T9tenr8GPBIAHk6gcet41FFHM+4CP8ABfwQ4w0Ookf9fjUH4L+BypBh1Eg9f9NeiinzPuB13hHw7pvhjRl0rSlmW2WR3AklLtljk8miiiudvUs//9k=</Val></Attr></Aspect></MediaItem></ArrayOfMediaItem>

I warned you, covers in base64 are really long

http://MP2ServerName:81/api/MediaItems/99355325-d729-4e18-aca2-bf09d18a9714
gives me

<MediaItem Id="99355325-d729-4e18-aca2-bf09d18a9714"><Aspect Id="17af940c-66ce-4d23-9d06-bf7f21c04201"><Attr Name="Title"><Val>Future Proof</Val></Attr><Attr Name="MimeType"><Val p4:null="true"/></Attr><Attr Name="RecordingTime"><Val>2003-01-01T00:00:00</Val></Attr><Attr Name="Rating"><Val p4:null="true"/></Attr><Attr Name="Comment"><Val p4:null="true"/></Attr><Attr Name="PlayCount"><Val p4:null="true"/></Attr><Attr Name="LastPlayed"><Val p4:null="true"/></Attr></Aspect><Aspect Id="0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed"><Attr Name="System-Id"><Val>14969200-a7b6-470e-9bfb-e66bef6fd100</Val></Attr><Attr Name="Path"><Val>{e88e64a8-0233-4fdf-ba27-0b44c6a39ae9}:///C:/_MP/Media/Music/01 - Future Proof.mp3</Val></Attr><Attr Name="ParentDirectory"><Val>2c3f7296-6496-4522-b749-06d7a516c65e</Val></Attr></Aspect><Aspect Id="cc0163fe-55a5-426c-a29c-f1d64af7e683"><Attr Name="LastImportDate"><Val>2013-07-29T23:13:29.167</Val></Attr><Attr Name="Dirty"><Val>false</Val></Attr><Attr Name="DateAdded"><Val>2013-07-29T23:13:29.167</Val></Attr></Aspect><Aspect Id="493f2b3b-8025-4db1-80dc-c3cd39683c9f"><Attr Name="Artists"><Val>Massive Attack</Val></Attr><Attr Name="Album"><Val>100th Window</Val></Attr><Attr Name="Genres"><Val>Electronica</Val><Val>Trip-Hop</Val><Val>Downtempo</Val><Val>Ambient</Val><Val>Alternative</Val></Attr><Attr Name="Duration"><Val>341</Val></Attr><Attr Name="Track"><Val>1</Val></Attr><Attr Name="NumTracks"><Val>10</Val></Attr><Attr Name="AlbumArtists"><Val>Massive Attack</Val></Attr><Attr Name="Composers"><Val>Robert Del Naja</Val><Val>Neil Davidge</Val></Attr><Attr Name="Encoding"><Val p4:null="true"/></Attr><Attr Name="BitRate"><Val>192</Val></Attr><Attr Name="DiscId"><Val p4:null="true"/></Attr><Attr Name="NumDiscs"><Val p4:null="true"/></Attr></Aspect><Aspect Id="a61846e9-0910-499d-9868-a1fabce7ccfd"><Attr Name="Thumbnail"><Val p4:null="true"/></Attr></Aspect><Aspect Id="1fda5774-9ac5-4873-926c-e84e3c36a966"><Attr Name="Thumbnail"><Val>/9j/4AAQSkZJRgABAQAAAQABAAD[...taking this out because it's too long...]/BQORFqI+l41FFHM+4ER+Cvgd3LtDqRY9T9tenr8GPBIAHk6gcet41FFHM+4CP8ABfwQ4w0Ookf9fjUH4L+BypBh1Eg9f9NeiinzPuB13hHw7pvhjRl0rSlmW2WR3AklLtljk8miiiudvUs//9k=</Val></Attr></Aspect></MediaItem>

and finally
http://MP2ServerName:81/api/MediaItems?searchString=future
gives me:

<ArrayOfMediaItem><MediaItem Id="99355325-d729-4e18-aca2-bf09d18a9714"><Aspect Id="17af940c-66ce-4d23-9d06-bf7f21c04201"><Attr Name="Title"><Val>Future Proof</Val></Attr><Attr Name="MimeType"><Val i:null="true"/></Attr><Attr Name="RecordingTime"><Val>2003-01-01T00:00:00</Val></Attr><Attr Name="Rating"><Val i:null="true"/></Attr><Attr Name="Comment"><Val i:null="true"/></Attr><Attr Name="PlayCount"><Val i:null="true"/></Attr><Attr Name="LastPlayed"><Val i:null="true"/></Attr></Aspect><Aspect Id="0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed"><Attr Name="System-Id"><Val>14969200-a7b6-470e-9bfb-e66bef6fd100</Val></Attr><Attr Name="Path"><Val>{e88e64a8-0233-4fdf-ba27-0b44c6a39ae9}:///C:/_MP/Media/Music/01 - Future Proof.mp3</Val></Attr><Attr Name="ParentDirectory"><Val>2c3f7296-6496-4522-b749-06d7a516c65e</Val></Attr></Aspect><Aspect Id="cc0163fe-55a5-426c-a29c-f1d64af7e683"><Attr Name="LastImportDate"><Val>2013-07-29T23:13:29.167</Val></Attr><Attr Name="Dirty"><Val>false</Val></Attr><Attr Name="DateAdded"><Val>2013-07-29T23:13:29.167</Val></Attr></Aspect><Aspect Id="493f2b3b-8025-4db1-80dc-c3cd39683c9f"><Attr Name="Artists"><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val></Attr><Attr Name="Album"><Val>100th Window</Val></Attr><Attr Name="Genres"><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Electronica</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Trip-Hop</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Downtempo</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Ambient</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val><Val>Alternative</Val></Attr><Attr Name="Duration"><Val>341</Val></Attr><Attr Name="Track"><Val>1</Val></Attr><Attr Name="NumTracks"><Val>10</Val></Attr><Attr Name="AlbumArtists"><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val><Val>Massive Attack</Val></Attr><Attr Name="Composers"><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Robert Del Naja</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val><Val>Neil Davidge</Val></Attr><Attr Name="Encoding"><Val i:null="true"/></Attr><Attr Name="BitRate"><Val>192</Val></Attr><Attr Name="DiscId"><Val i:null="true"/></Attr><Attr Name="NumDiscs"><Val i:null="true"/></Attr></Aspect><Aspect Id="a61846e9-0910-499d-9868-a1fabce7ccfd"><Attr Name="Thumbnail"><Val i:null="true"/></Attr></Aspect><Aspect Id="1fda5774-9ac5-4873-926c-e84e3c36a966"><Attr Name="Thumbnail"><Val>/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQ[... taking this out because it's too long...]/BQORFqI+l41FFHM+4ER+Cvgd3LtDqRY9T9tenr8GPBIAHk6gcet41FFHM+4CP8ABfwQ4w0Ookf9fjUH4L+BypBh1Eg9f9NeiinzPuB13hHw7pvhjRl0rSlmW2WR3AklLtljk8miiiudvUs//9k=</Val></Attr></Aspect></MediaItem></ArrayOfMediaItem>

And those of you, who really read that stuff, may already see one of the possible bugs. Hint: compare the genres in the second and the third query. They should be the same...

And to give you an impression how easy the code is - this is the whole implementation of the third query controller (it searches the string in all text fields of all MediaItemAspects btw.:

	public IEnumerable<MediaItem> GetMediaItemsBySearchString(string searchString)
	{
	  List<Guid> necessaryMIAs = new List<Guid>();
	  necessaryMIAs.Add(MediaAspect.ASPECT_ID);
	  List<Guid> optionalMIAs = new List<Guid>(ServiceRegistration.Get<IMediaItemAspectTypeRegistration>().LocallyKnownMediaItemAspectTypes.Keys);
	  MediaItemQuery miq = ServiceRegistration.Get<IMediaLibrary>().BuildSimpleTextSearchQuery(searchString, necessaryMIAs, optionalMIAs, null, false, true);
	  var result = ServiceRegistration.Get<IMediaLibrary>().Search(miq, false);
	  return result;
	}

I'm not even sure whether we need the "necessaryMIAs" or whether we can just provide the "optionalMIAs". Then take out the var result and return directly and we just have 3 lines of code...

That's it for today.
Have a good night everyone and talk to you soon (oh and those of you on the other side of the planet - please continue the discussion )
Michael

[Edit: Files removed. Included in v0.02 in first post]

 

[Valk]

small hint: use IList instead of IEnumerable for future data virtualization

I'm pretty sure optionalMIAs can be null with no consequences (there's a reason it's optional) but necessaryMIAs are used.

 

[morpheus_xx]

I'm pretty sure optionalMIAs can be null with no consequences (there's a reason it's optional) but necessaryMIAs are used.

In principle you are right: you can use "null" after my fix https://github.com/MediaPortal/MediaPortal-2/commit/e31d7a40d3d0091df17c92f26c1f8ea8a1dbb067
in branch https://github.com/MediaPortal/MediaPortal-2/commits/FEAT_AlbumCovers_MP2-358

 

[morpheus_xx]

Regarding the integration process:

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.

This is in principle what I've done when I "extracted" the TVE35 core into a plugin and hosted inside MP2. For interaction with the "host", I created following interfaces: https://github.com/MediaPortal/Medi...rver/TvLibrary.IntegrationProvider.Interfaces
The main integration interface is:
https://github.com/MediaPortal/Medi...onProvider.Interfaces/IIntegrationProvider.cs, which in principle only exposes IPathManager for accessing folders and ILogger.

I would prefer to use this interface also for MPExtended and extend it if needed. This way we could use same architecture for TVE35 and also MPExtended "plugins" in future. The common interface itself should then moved into a more common place (currently defined inside TVE35), I think it should be simply an own library.

What do you think about this proposal?

 

[FreakyJ]

Sounds good to me

 

[MJGraf]

Hi everybody and thank you all for your comments!

I've read a bit deeper into MPExtended and WebMP and thought about all the comments above. Let me summarize my thoughts as follows:

• For the integration I think we have to differentiate between MPE and WebMP:
• MPE:
  • MPE really has a well structured code base. Easy to read and easy to understand. Congratulations to the MPE team
  • I think MPE should be integrated into MP2. But instead of having one MPE plugin, it would certainly good to make the cut one level deeper and have one plugin for every main service exposed by MPE: One plugin for the MediaAccessService (MAS), one plugin for the StreamingService and maybe one plugin for the TVAccessService (I think this one only makes sense as soon as we have TVE35 native in MP2 Server).
  • Does MPAnywhere need a separate WebAPI when MAS is integrated? I think yes for the following reasons:
    • The biggest downside of MAS from an MP2 perspective (which is probably a pro from a client app perspective) are the hard coded attributes of all the MediaItems. In MP2 every plugin can register new MediaItemAspects with new attributes and so we can of course map the MPE attributes to the ones which are as standard included in MP2. But we can never make sure that you can access all the metadata contained in the MediaLibrary by using MAS (although I have to admit that I never saw such a comprehensive list of attributes...)
    • As already mentioned above, we will need write access to the MediaItemAspects, which is not possible with MAS.
    • That means for me that I will continue to develop the WebAPI for our MediaItem objects.
    • But it also means that it makes perfectly sense to additionally integrate MAS in MP2. The MediaItem objects are so tailor made for MP2 that it is quite complex to understand and to handle these objects on the client side. So having an additional, separate, clean WCF API for (read)access to the MP2 MediaLibrary through a very defined and easy to understand interface is IMO a good idea - and furthermore makes it possible to use aMPDroid and maybe Eve out of the box.
  • What about the StreamingService (WSS)?
    • Whenever MPAnywhere will support streaming, I will definitely not make a separate StreamingPlugin. WSS is perfect for that purpose - we just have to make it aware of MP2's way of accessing Media files (i.e. MediaAccessors, etc.).
• WebMP:
  • Well, in this respect I think we need a dedicated app for MP2. The reason is in particular that we need a way to edit our MP2 settings and to view and edit the MediaLibrary. Both are not included in WebMP and (please Oxan correct me if you have a different view) they should not be included in WebMP, since WebMP is a standalone app without requiring MP1 or MP2 at all.
  • This means that we either need a standalone app or a web app and since I like the idea of a web app, I will still go the route of the single page sencha touch / extjs Web frontend.
  • How about a potential streaming frontend of MPAnywhere?
    • First of all, this is still far down the route.
    • When we get there we will make use of the WSS, so this part is not duplicated.
    • Maybe as a first step we could also just show WebMP in the main panel of the MPAnywhere App. The second step may be to have a skin for WebMP, which cleanly integrates into that main panel of MPAnywhere. That way we definitely don't do double work. We use MPAnywhere for things for which MPE and WebMP are not meant for and we integrate MPE and WebMP into MPAnywhere whenever it makes sense because it is already there. Furthermore, if someone still wants to use WebMP separately, it's possible just by using a different URI - then you don't have MPAnywhere "wrapped" arount WebMP but pure WebMP

Any thoughts on this? Still not a master plan, but I'm just trying to combine the best of two worlds (and making it one world...)

As to the progress:
Since accessing MediaItems was not possible when using the JSonFormatter, I implemented an ITraceWriter, which traces to our MP2-Logger. That way I found out that the problem was the following: MediaItem objects are designed to be serialized as XML. They implement the IXMLSerializable interface. This is why WebAPI using an XML Serializer worked out of the box and resulted in beautiful XML.
Unfortunately this is not the case for Json serialization. There the inbuilt json serializer (which is Newtonsoft.Json) tries to serialize the MediaItems and just doesn't get along with these objects. Since every MIA has a parentMIA, it detected a circular reference and stopped with an error. I could get around this by setting the serializer to ignore circular references, but the json result is still ugly and doesn't contain the necessary information (I think this is because the only way to access MIA values is via the [] operator and an operator doesn't get serialized of course. The fields themselves are private so they don't get serialized either.
There are two options to solve this: Either we make the MediaItem objects aware that they may be serialized to json. I personally don't like the idea, because this means changes to MP2 core and I want to avoid that. The second possibility would be to write our own JsonFormatter for type(MediaItem). I think I will just try the latter. The aim of this should be that the JSon output results in exactly the same objects as the xml output - just formatted as json.
Let's see how I get along...

And still: any help is appreciated on the sencha side. And of course any comments are welcome!!

Michael

 

[Oxan]

Sorry for the delayed answer, didn't have any time to spend on MP last week.

When we have MPE in MP2, why shouldn't we use MPE as a "bridge" to import MediaItems from other apps such as MP1 (Moving Pictures, etc.), XBMC and whatever else MPE supports into the MP2 MediaLibrary?

Sure, shouldn't be a problem to support from the MPExt side.

I would prefer to use this interface also for MPExtended and extend it if needed. This way we could use same architecture for TVE35 and also MPExtended "plugins" in future. The common interface itself should then moved into a more common place (currently defined inside TVE35), I think it should be simply an own library.

That's fine. Shouldn't be a problem for MPExt either.

MPE really has a well structured code base. Easy to read and easy to understand. Congratulations to the MPE team

Thanks!

I think MPE should be integrated into MP2. But instead of having one MPE plugin, it would certainly good to make the cut one level deeper and have one plugin for every main service exposed by MPE: One plugin for the MediaAccessService (MAS), one plugin for the StreamingService and maybe one plugin for the TVAccessService (I think this one only makes sense as soon as we have TVE35 native in MP2 Server).

Yes, I agree. As I said earlier, integrating the service as a whole is a first step, but definitely shouldn't be the last step.

Does MPAnywhere need a separate WebAPI when MAS is integrated? I think yes for the following reasons:

I completely agree with all your points here. MAS is a nice API (made) for read-only clients such as aMPdroid and Eve, but adding edit functionality is really stretching its limits (it was never meant to happen, anyway). It's quite hard to implement anyway, since we support multiple backends. (Yes, if MAS is implemented for MP2 you'll get aMPdroid and Eve support out-of-the-box).

Making WSS aware of MP2's way of accessing media files shouldn't be a problem. In theory WSS already supports accessing all files through a service running on another server, so we'll just need to write a little bridge with that API that uses MP2's MediaAccessors etc instead of a network service. (In practice this support is probably broken since it's not officially supported, can't be configured and hasn't been tested in a year or so, but shouldn't be too hard to fix).

Well, in this respect I think we need a dedicated app for MP2. The reason is in particular that we need a way to edit our MP2 settings and to view and edit the MediaLibrary. Both are not included in WebMP and (please Oxan correct me if you have a different view) they should not be included in WebMP, since WebMP is a standalone app without requiring MP1 or MP2 at all.

That's correct. However, WebMP supports plugins nowadays, so you can write a plugin on the WebMP foundation that allows you to do all MP2-specific stuff without merging MP2-specific stuff into WebMediaPortal itself. Even the interface can be completely changed by a plugin now, so you can rewrite the interface based upon Sencha touch / extjs / <insert Web2.0 technology> (I don't know much about client-side development) without any problems.

Regarding streaming, there's still a good 600 lines of complex streaming code in WebMP. Some of that stuff should be moved to WSS and some of it might not be needed for MPAnywhere (e.g. having WSS on a different machine), but writing the high-level user interface for WSS isn't that easy (mainly due to WCF limitations and stupid HTTP stuff).

However, I think the main benefit of writing MPAnywhere based on WebMP instead of integrating WebMP with MPAnywhere is that it'll save you quite some unnecessary work, so it's entirely up to you. If you think building MPAnywhere "standalone" is easier or better, that's fine.

 

[MJGraf]

However, I think the main benefit of writing MPAnywhere based on WebMP instead of integrating WebMP with MPAnywhere is that it'll save you quite some unnecessary work, so it's entirely up to you. If you think building MPAnywhere "standalone" is easier or better, that's fine.

If I only knew To be honest, I have got no idea, what benefit I could have from using WebMP as a basis for MPAnywhere. The reason for not knowing this is just that I am no web developer. What I want is a single page web application. Can anyone explain what advantages I may have from using an ASP.Net MVC application as a base for that? My (simple) thinking is that for a single page webapp, I only need files to be served to the client, which are static - since these files only contain js-code. No html at all (besides index.html) - everything generated dynamically on the client side. What are the benefits of ASP.Net MVC in this situation?

In the meantime I have also written

• a MediaItemJsonConverter and
• a MediaItemAspectJsonConverter.

As a result, a MediaItem in Json form looks like this:

 {
	"Id": "99355325-d729-4e18-aca2-bf09d18a9714",
	"MediaItemAspects": [
	  {
		"Id": "17af940c-66ce-4d23-9d06-bf7f21c04201",
		"Name": "MediaItem",
		"Attributes": {
		  "Title": "Future Proof",
		  "MimeType": null,
		  "RecordingTime": "2003-01-01T00:00:00",
		  "Rating": null,
		  "Comment": null,
		  "PlayCount": null,
		  "LastPlayed": null
		}
	  },
	  {
		"Id": "0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed",
		"Name": "ProviderResource",
		"Attributes": {
		  "System-Id": "14969200-a7b6-470e-9bfb-e66bef6fd100",
		  "Path": "{e88e64a8-0233-4fdf-ba27-0b44c6a39ae9}:///C:/_MP/Media/Music/01 - Future Proof.mp3",
		  "ParentDirectory": "2c3f7296-6496-4522-b749-06d7a516c65e"
		}
	  },
	  {
		"Id": "cc0163fe-55a5-426c-a29c-f1d64af7e683",
		"Name": "ImportedItem",
		"Attributes": {
		  "LastImportDate": "2013-08-03T02:00:15.843",
		  "Dirty": false,
		  "DateAdded": "2013-07-29T23:13:29.167"
		}
	  },
	  {
		"Id": "493f2b3b-8025-4db1-80dc-c3cd39683c9f",
		"Name": "AudioItem",
		"Attributes": {
		  "Artists": [
			"Massive Attack"
		  ],
		  "Album": "100th Window",
		  "Genres": [
			"Electronica",
			"Trip-Hop",
			"Downtempo",
			"Ambient",
			"Alternative"
		  ],
		  "Duration": 341,
		  "Track": 1,
		  "NumTracks": 10,
		  "AlbumArtists": [
			"Massive Attack"
		  ],
		  "Composers": [
			"Robert Del Naja",
			"Neil Davidge"
		  ],
		  "Encoding": null,
		  "BitRate": 192,
		  "DiscId": null,
		  "NumDiscs": null
		}
	  },
	  {
		"Id": "a61846e9-0910-499d-9868-a1fabce7ccfd",
		"Name": "ThumbnailSmall",
		"Attributes": {
		  "Thumbnail": null
		}
	  },
	  {
		"Id": "1fda5774-9ac5-4873-926c-e84e3c36a966",
		"Name": "ThumbnailLarge",
		"Attributes": {
		  "Thumbnail": "/9j/4AAQSkZJRgABAQAAAQABAAD [...too long...]jk8miiiudvUs//9k="
		}
	  }
	]
  }

Is there anyone out there who already used a json object with javascript? Does this json object make sense? Should we change anything?

Thanks,
Michael

 

[Oxan]

If I only knew To be honest, I have got no idea, what benefit I could have from using WebMP as a basis for MPAnywhere. The reason for not knowing this is just that I am no web developer. What I want is a single page web application. Can anyone explain what advantages I may have from using an ASP.Net MVC application as a base for that? My (simple) thinking is that for a single page webapp, I only need files to be served to the client, which are static - since these files only contain js-code. No html at all (besides index.html) - everything generated dynamically on the client side. What are the benefits of ASP.Net MVC in this situation?

Some of the things that WebMP implements itself currently, but which is just boring stuff that ideally should be handled by a framework:

• Determining the external URL under which WebMP/MPAnywhere is accessible. iOS is stupid and refuses to open streams with a relative URL.
• Authentication and authorization.
• Skinning support (though this is probably easier to implement for a single page webapp than for a multipage one like WebMP).
• Localization (though you probably can use the MP2 framework instead).
• Stream authentication (some mobile browsers drop all cookies when they request a stream, so you can't use the normal authentication mechanisms)
• Configuration handling (lots of code needed to write a decent UI with translation and dynamic dropdowns)

Not everything from that list will apply to MPAnywhere and you can probably get most of these things from another framework too, but it's just something to consider