[aaronb]

To me the most important thing here, and something I think we should all be happy about, is that a big media company is finally recognizing all the great work going on in the media center community and trying to give users what they want.

Maybe you're suspicious about LG's intentions, maybe you're skeptical about how open it will be, maybe you wish XBMC was getting a little more credit for having formed the foundation of this particular development, but despite all of that let's not overlook how exciting it is that we could finally have a platform built right into major-brand home theater devices that lets us use our media the way we want to. I'll wait patiently to see how it develops, and I too have some skepticism about how well it will turn out, but this is an encouraging first step.

I've been using XBMC since 2005, and I've bounced back and forth between Plex/XBMC over the last couple years as the two have moved along at different speeds. I've always wondered why some device manufacturer wasn't taking advantage of all this great work, and someone finally is. Boxee of course is doing something similar, but that was from the ground up, and they've had their own struggles being outsiders from the mainstream home theater industry. I think this is great news and we should give it time to see how it works out before getting worked up about it.

[jayman978]

well since your showing your head here jayman and I would probably get banned or warned for asking this on the plex forum.
The LG news post says that now elan and a few others can work on plex full time as a job because you are getting money for it. It also says the reason LG decided to use you is your great content that you provide I wonder if you will be giving a slice of the pie (so too speak) to the previous plugin writers that have contributed to plex to make it a product that LG is interested in and thus bring in the cash for you

Well we pretty much ignore you when you come to our forums now so feel free to do the same to me here.

[elan]

I guess by that argument, some "open platforms" are more open than others, huh?

Yes, but that doesn't make them better.

[tropic10]

I may not get an answer to this but I'll ask anyway. Elan, are you planning on eventually rewriting the Mac front end so it doesn't use the XBMC codebase?

[superpea]

Tropic10, why in the world would someone endeavor to do such a thing? BLASPHEMY!

[jmarshall]

Tropic10, why in the world would someone endeavor to do such a thing? BLASPHEMY!

So that's a no? Nothing wrong with giving a simple answer to a simple question.

Cheers,
Jonathan

[elan]

I may not get an answer to this but I'll ask anyway. Elan, are you planning on eventually rewriting the Mac front end so it doesn't use the XBMC codebase?

We're focused on thin clients, so our primary interest in any client front-end is that it's as lightweight as possible. For the Plex/Nine release, most of the focus has been on removing/disabling as much as possible to leave just the player and skinning engine.

XBMC's skinning engine (even the older version we have) is the best one I know of, and I can say almost the same about the player. So we just want to use those components to build a fast, thin, fast client which talks to the Plex Media Server.

As an example of why we choose to operate like this, I've heard that hdhomerun support is broken in Plex. Now, I barely know what an hdhomerun is, and none of us on the team have one. And I suspect a very small (yet possibly vocal) fraction of our userbase owns one. So we just don't want to spend the time supporting it, wondering why it's not working, or leaking memory, or causing crashes.

Now I'm not saying this is the only best philosophy around, or even the best one. It's simply the one that suits us best.

[superpea]

So that's a no? Nothing wrong with giving a simple answer to a simple question.

Jonathan, you are absolutely correct and I apologize for my silly response. It was dimwitted of me.

I am not sure I understand the purpose of the question in relation to this thread (must be missing something?), but that has never stopped us from digressing before, so why now?

The reality is we have already written several Plex Media Server clients that do not use any XBMC code. That trend may continue as we expand to new platforms. We may also revisit the long term strategy for our Mac player, but I don't believe we have anything to share on that front currently. Ultimately, our goal is to continue to improve the user experience and further our vision...how that comes about is always a fluid and fun process. I don't think anybody on the Plex team is going to be religious about using any particular codebase to meet those goals--if we can further it via an XBMC-derived base or something new entirely is always open for debate from our perspective. Leveraging the opportunities each platform enables to provide the best performance and experience will always factor in, as I am sure you can appreciate! Making sure the Plex Media Server platform is open for other developers to write their own clients is another aspect of our approach that suggests folks will use whatever codebase upon which they choose to build the best possible experience.

Does that help?

[jmarshall]

@superpea - thanks for being so clear and open - I wish you all the best in furthering your vision through leveraging opportunities in your long term strategy.

@tropic10 - apologies for interrupting - hope you got your answer.

[RckStr]

We're focused on thin clients, so our primary interest in any client front-end is that it's as lightweight as possible. For the Plex/Nine release, most of the focus has been on removing/disabling as much as possible to leave just the player and skinning engine.

XBMC's skinning engine (even the older version we have) is the best one I know of, and I can say almost the same about the player. So we just want to use those components to build a fast, thin, fast client which talks to the Plex Media Server.

Will this part still be open source though? ie will others be able to make frontends for PMS? As much as i love the iOS apps and the server part of your software, I dont like the osx player so much. In a dream world, id much rather have PMS serving up XBMC clients around my house.

[elan]

Will this part still be open source though? ie will others be able to make frontends for PMS? As much as i love the iOS apps and the server part of your software, I dont like the osx player so much. In a dream world, id much rather have PMS serving up XBMC clients around my house.

Yes, of course! If anyone wants to get XBMC working with PMS, I'd be the first to pitch in to help.

[Razor_109]

Yes, of course! If anyone wants to get XBMC working with PMS, I'd be the first to pitch in to help.

First of all, based on what i've read and seen.. (not personally experienced) PMS looks promising. But your positive response in pitching in when someone would like to make XBMC work together as front-end makes me wonder. It would indeed be silly to let other coders write a similar application (hence the reason for Plex using XBMC's skinning- en playback-engine).
But at the moment PMS is written for OSX, and i heard rumors about porting PMS (or Plex only?) to Windows. Is there any long-term goal to port PMS to Unix as well?

The reason i'm asking this is because even though PMS looks promising, it would never be reason enough for me to buy a Mac Mini "Server" or something similar. When available i would hookup my XBMC-clients to the PMS running on Unix.

On the other hand i guess the XBMC developers will not think of this as very appealing since this would compromise the open-source character of XBMC by basing it on a closed-source server.

[davilla]

Humm, So I would need a API key to access transcoding functionality from what is touted as an Open Platform. What other features are controlled by API keys?

That does not sound very open to me. An Open Platform is more like OpenMax, where all the details of the API are documented and free to use by anyone.

[elan]

Humm, So I would need a API key to access transcoding functionality from what is touted as an Open Platform. What other features are controlled by API keys?

I'm really glad Frank saw the glass as being half full

http://www.ambertation.de/en/klexi

That's the only thing that requires an API key at the moment, and that might change. If we didn't have a key, then someone could write an iOS app and put it in the store for free, leveraging all our hard work on the server, and then our supply of beer money might dry up, and a lack of beer makes us sad. So you might think of it as evil and closed and secretive and scary and (did I mention evil?) but the handful of developers who are working with us on third party applications see it as an opportunity.

[elan]

But at the moment PMS is written for OSX, and i heard rumors about porting PMS (or Plex only?) to Windows. Is there any long-term goal to port PMS to Unix as well?

I'd be lying if I didn't say we had the server running on a variety of platforms in our "labs". Whether or not the ports make it out of the lab depends on a multitude of factors, but I expect the range of available platforms to only grow over time