LinuxMCE Forums

General => Developers => Topic started by: chrisbirkinshaw on June 08, 2010, 04:08:25 am

Title: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 04:08:25 am
In the daytime I work as a presales solutions architect for a software company. I've had chance recently to sit back from linuxMCE and have a think about things in a broader sense, as if I were approaching a project at work, and try to think objectively. Here are my thoughts.

LinuxMCE is a media center. Cool.

What is great about it? Well it can turn on my lights when the film has finished, I have easy touch screen access to lighting scenarios around the home, when I'm watching TV I can see who is calling when the phone rings, etc etc.

What makes LMCE indispensible and unique is the cool integration between security, HA, media, etc. What everyone complains about? Media playback.

I have heard some of the core devs getting very dispondent at the mountain of work to do on LMCE to do things like remove non open source code, bring it up to the current standards for media center UIs such as XBMC, write new plugins for things like Hulu, Mame, Pandora, etc. I feel sorry for the small handful of devs who are literally recoding a mammoth system, so complex and interconnected that probably not even one person alive knows every inch of it and never will. Maybe it's time to stand back and ask if the task is really too big, and also if it is justifiable (read on!)?

I also did a bit of playing around with Boxee and XBMC and suddenly thought - if the only thing stopping me using these packages full time was the lack of cool HA/security/climate integration, then wouldn't it be better to take the media playback from XBMC into LinuxMCE all get all those Hulu, Netflix, iPlayer, Pandora plugins for free, and not have to maintain this huge beast anymore? There is even now a mythtv plugin for XBMC which allows liveTV and recorded program watching, and of course it's very much under active development by a large community.

XBMC is all easily controllable via a HTTP API, which is even better.

I would propose to strip frontend duties away from the orbiter (except for non MD devices) and have XBMC launched by the DCERouter on startup. The HA, security, and telephone menus would all then be XBMC plugins. It should be possible to get devs in the XBMC community to write these plugins if we get them excited enough, which would be great news obviously.

- Leverage existing iphone/smartphone apps for XBMC control
- UI3 for things like webDT goes into XBMC dev pool and you get their dev support and involvement
- No more coding new plugins for media playback as new web portals launch (there will be a lot over the next few years you can bet! - how many do you want to code?!!)
- Development on things like the mame plugin becomes an XBMC plugin, and again gets a wider audience and contribution from XBMC devs
- DCERouter stays in there and modularity is preserved

Seems like a win/win situation.

Does linux need separate teams writing competing media centre applications? Is this for the best? It kind of defeats the whole open source philosophy of contributing code to make the pool better so that it benefits everyone involved. Lots of separate pools reduces the chance of benefits being shared.

Regards,

Chris






Title: Re: Reinventing the wheel
Post by: golgoj4 on June 08, 2010, 05:10:02 am
In the daytime I work as a presales solutions architect for a software company. I've had chance recently to sit back from linuxMCE and have a think about things in a broader sense, as if I were approaching a project at work, and try to think objectively. Here are my thoughts.

LinuxMCE is a media center. Cool.

What is great about it? Well it can turn on my lights when the film has finished, I have easy touch screen access to lighting scenarios around the home, when I'm watching TV I can see who is calling when the phone rings, etc etc.

What makes LinuxMCE indispensible and unique is the cool integration between security, HA, media, etc. What everyone complains about? Media playback.

I have heard some of the core devs getting very dispondent at the mountain of work to do on LinuxMCE to do things like remove non open source code, bring it up to the current standards for media center UIs such as XBMC, write new plugins for things like Hulu, Mame, Pandora, etc. I feel sorry for the small handful of devs who are literally recoding a mammoth system, so complex and interconnected that probably not even one person alive knows every inch of it and never will. Maybe it's time to stand back and ask if the task is really too big, and also if it is justifiable (read on!)?

I also did a bit of playing around with Boxee and XBMC and suddenly thought - if the only thing stopping me using these packages full time was the lack of cool HA/security/climate integration, then wouldn't it be better to take the media playback from XBMC into LinuxMCE all get all those Hulu, Netflix, iPlayer, Pandora plugins for free, and not have to maintain this huge beast anymore? There is even now a mythtv plugin for XBMC which allows liveTV and recorded program watching, and of course it's very much under active development by a large community.

XBMC is all easily controllable via a HTTP API, which is even better.

I would propose to strip frontend duties away from the orbiter (except for non MD devices) and have XBMC launched by the DCERouter on startup. The HA, security, and telephone menus would all then be XBMC plugins. It should be possible to get devs in the XBMC community to write these plugins if we get them excited enough, which would be great news obviously.

- Leverage existing iphone/smartphone apps for XBMC control
- UI3 for things like webDT goes into XBMC dev pool and you get their dev support and involvement
- No more coding new plugins for media playback as new web portals launch (there will be a lot over the next few years you can bet! - how many do you want to code?!!)
- Development on things like the mame plugin becomes an XBMC plugin, and again gets a wider audience and contribution from XBMC devs
- DCERouter stays in there and modularity is preserved

Seems like a win/win situation.

Does linux need separate teams writing competing media centre applications? Is this for the best? It kind of defeats the whole open source philosophy of contributing code to make the pool better so that it benefits everyone involved. Lots of separate pools reduces the chance of benefits being shared.

Regards,

Chris








so i guess all of the discussions about this precise issue are somehow going unheard? Im no dev, but even these little details have trickled down to me.

1. Write it
2. Pay someone to write it

On a seperate thread...new ui/orbiter design is something thats been talked about and is currently be researched. So why derail that in favor of said main dev's spending their time integrating XBMC?

Also, and i really need to understand this, what so hard about playing media in linuxMCE? Maybe ive gotten accustomed to the way it works and therefore cant see outside my own box, but seriously? What exactly is it? The media controls and interfaces have only gotten smoother since I started using linuxMCE with 0704 so im at a loss for why XBMC is so impressive. I wont go into my personal feelings on it except to say having given it a go, i chose linuxMCE.

Lastly, it seems like this is an effort to get other people to code things people want, but somehow dont have the time for it themselves except to suggest how its the best option and things should lean in that direction. Which is whatever, its a public forum. But it seems damned self centered imo.

As far as your point about competing media center applications, is it really a competition? Its what people prefer, not a popularity contest. Im not saying your points on sharing of code to the greater 'pool', but does it have to come at the loss of individuality. We do things different than XBMC. And for some reason, there are people that want us to be XBMC. Why not just install XBMC? Are there things i want to change? yes, make no mistake. But i guess my philosophy is fix/make it as opposed to being tied to something else which isnt so great imo.

Im sure i left something out, but hey im not perfect (like xbmc apparently)  ::)

-green coding guy, golgoj4.
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 05:45:09 am
No, my post is not self centered. I do not care a rat's arse for what is powering the media experience. It's quite the opposite of self centered - I am suggesting a way to save time for the developers.

Yes, there would be some development to move to an architecture closely aligned to XBMC (for example), but my argument is that in long run maintenance would be reduced and sharing a codebase with more developers from another larger community would be helpful for all.

You haven't answered my point at all or taken notice of any of the benefits I have suggested, you simply have something against my post because I have not written any C++ code. I thought we were passed that... (BTW I have contributed perl and ruby code to the best of my abilities, and debugged some scripts, if that matters to you).

In the company in which I work products would go off the rails if there weren't some non-coders looking on from a high level and making architectural suggestions. We had a few products where "silo development" became a problem due to a few keen developers and now have a big job on our hands removing redundancy from overlapping products. Sometimes you need the birds eye view and different people have different skills. Software companies with products which are successful are not architected, coded, and graphic designed by one of even a handful of people.

So, please do not flame my post for no apparent reason.

I have suggested many areas of overlap with other open source linux media centres, ways time could be saved, and posed a question "why reinvent the wheel?". A useful response to my post would be to answer that fundamental question. I don't think you can argue that asking it or answering is not valid, no matter what the answer is. It is an open question, and not a predetermined conclusion as you suggested.

So please, discuss... Nobody should be attacked for promoting architectural discussions. If you don't have time because you are so busy doing coding and contributing to the project then simply ignore this thread.

Regards,

Chris
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 05:50:17 am
As far as your point about competing media center applications, is it really a competition? Its what people prefer, not a popularity contest. Im not saying your points on sharing of code to the greater 'pool', but does it have to come at the loss of individuality. We do things different than XBMC. And for some reason, there are people that want us to be XBMC. Why not just install XBMC? Are there things i want to change? yes, make no mistake. But i guess my philosophy is fix/make it as opposed to being tied to something else which isnt so great imo.

What I'm saying is that we don't do things that differently to (for example) XBMC. I think there are very significant areas of overlap. I am open to discussion on these points and ready to stand corrected if you can give me some examples of how a combined solution would not meet the use cases of the current solution. I have already described why "just installing XBMC" is not sufficient - the products do not 100% overlap.

BTW doesn't the KDE vs Gnome thing annoy you? Doesn't it seem like a bit of a waste? Doesn't it make linux seem more complex to Joe Bloggs?
Title: Re: Reinventing the wheel
Post by: tschak909 on June 08, 2010, 06:24:16 am
*hmm*

Chris,

If you want xbmc, write a DCE media player wrapper to use it. Simple. Done. This goes for any program that you can get bi-directional communication from.

If you want it...Just write it. This system is modular enough to swap pieces in and out.

So just shut up, and do it.

Thom.
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 07:00:22 am
Yes, that is a different discussion, and I probably will as it looks like a simple API. But can you tell me - did you ever think of this, and are there reasons you decided LinuxMCE must have it's own completely separate path (and commit yourself to a potentially never ending project maintaining that path)? I presume that this kind of thing already crossed your mind but perhaps you have arguments against it? Just adding a new plugin to a massive pile doesn't exactly address my point, which was about reducing the amount of plugins to maintain :-D

EDIT: I don't "want XBMC"! I'm just asking a valid question nobody will answer! If I write a plugin this doesn't help - what I proposed was much bigger
Title: Re: Reinventing the wheel
Post by: tschak909 on June 08, 2010, 07:03:19 am
Why don't you actually dig in and study the architecture in detail? Then we can have an intelligent discussion about this. You need to dump your preconceptions.

While I did not design this architecture, Pluto weren't dummies by any stretch, and what they came up with, is light years ahead of anything XBMC or any other media center can even remotely touch.

-Thom
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 08:46:44 am
Well I think I have a pretty good idea of the basics - I've made simple ruby devices, interfaced perl scripts using the telnet interface. I made the ruby on rails database mapping and basic web GUI so I know how things fit together in the DB. But it still wasn't obvious why this approach would not work. The <other_media_center> based plugin could still be a DCE device.

I already spent a lot of my time on LMCE, even just getting things running probably adds in total to weeks. My ex girlfriend hated it, and I realised I was being generally antisocial because of it, etc etc. In the end I ripped everything out, replaced with dedicated hardware devices, and only have LMCE running in a Virtual Machine these days for testing and a bit of fun. Sometimes I just wonder (partially in awe - don't get me wrong) how much of your life you are prepared to devote to this project. It's impressive that you do so much, but seriously that would get to me after a while - even doing 1/10th of what you do was too much. Don't you want to set something off which just sustains itself and you can dip in and out of it? It must frustrate you to see the lack of interest in the programming tasks, the constant "when is the next release?" posts. I'm not trying to spread doom and gloom - just suggesting that there may be a way to leverage support from existing linux communities in other ways than just hoping they will see the light and jump ship to the architecture which is "light years ahead" of any other media centre. I don't doubt that pluto were very clever. Even looking at the database I thought "WOW!" the first time. But perhaps they were a little too clever.... Who knows...

I did say I was happy to be wrong ;-)

Title: Re: Reinventing the wheel
Post by: golgoj4 on June 08, 2010, 09:09:18 am
No, my post is not self centered. I do not care a rat's arse for what is powering the media experience. It's quite the opposite of self centered - I am suggesting a way to save time for the developers.

Yes, there would be some development to move to an architecture closely aligned to XBMC (for example), but my argument is that in long run maintenance would be reduced and sharing a codebase with more developers from another larger community would be helpful for all.

You haven't answered my point at all or taken notice of any of the benefits I have suggested, you simply have something against my post because I have not written any C++ code. I thought we were passed that... (BTW I have contributed perl and ruby code to the best of my abilities, and debugged some scripts, if that matters to you).

In the company in which I work products would go off the rails if there weren't some non-coders looking on from a high level and making architectural suggestions. We had a few products where "silo development" became a problem due to a few keen developers and now have a big job on our hands removing redundancy from overlapping products. Sometimes you need the birds eye view and different people have different skills. Software companies with products which are successful are not architected, coded, and graphic designed by one of even a handful of people.

So, please do not flame my post for no apparent reason.

I have suggested many areas of overlap with other open source linux media centres, ways time could be saved, and posed a question "why reinvent the wheel?". A useful response to my post would be to answer that fundamental question. I don't think you can argue that asking it or answering is not valid, no matter what the answer is. It is an open question, and not a predetermined conclusion as you suggested.

So please, discuss... Nobody should be attacked for promoting architectural discussions. If you don't have time because you are so busy doing coding and contributing to the project then simply ignore this thread.

Regards,

Chris

1st, there was no flame. you would know if there was, believe that. Maybe i just miscommunicated what i was asking.

2nd, i could care less if you contribute code or not. Hell, i have not even contributed anything of significance, so im not sure where that defensive bit came from.

3rd I am not in a position to evaluate the benefits you stated. And that is why I did not choose to address it. Please try to not assume. I could direct you to posts i DO have something against, but its not very useful for the discussion at hand. I asked you to define what you thought was wrong with media playback, a question that was also unanswered. Im not going to imply some dumb-ass reason why you didn't. See how that works?

4. I agree about the organization aspect, tunnel vision can be a bad thing. My point was that linuxMCE is at the point where a UI makeover is in its baby stages. So to say that it needs people to look at and make architectural suggestions, well i thought that discussion was on-going?

5. My whole point was why not invest this time about what the ui should look and act like into an actual discussion about the UI. It seems you feel xbmc will fill that role quite well. I think that linuxMCE should maintain its own ui and just improve the elements there.

6. Sorry if my post got under your skin, wasn't my intention. It just seems there is a bit of suggesting going on without any real investment of time into what would be possible. And file me under that category too. There are tons of things i'd like to add/change/fix whatever. Im not saying its a bad idea to try and remove strain on the lead dev's as you mentioned, that clearly isn't a bad thing.

The premise of your question is solid though...but there are far more factors involved it seems than just 'i has http api'. Also, i dont see it as re-inventing the wheel so much as adding a Cadillac chassis and 3 other wheels. LinuxMCE does so much more and it may be more work just to integrate something and bring it up to speed if you will as opposed to developing something linuxMCE specific that isn't shoe-horned into someone else's UI. The last 2 paragraphs were more editorial...guess i could have put a cap on that bit...but what can I say, i felt it needed to be said, even if it wasn't you specifically it was directed at.

Did i answer it yet?
-golgoj4
salty for effect ;)
Title: Re: Reinventing the wheel
Post by: bulek on June 08, 2010, 09:59:35 am
Well I think I have a pretty good idea of the basics - I've made simple ruby devices, interfaced perl scripts using the telnet interface. I made the ruby on rails database mapping and basic web GUI so I know how things fit together in the DB. But it still wasn't obvious why this approach would not work. The <other_media_center> based plugin could still be a DCE device.

I already spent a lot of my time on LinuxMCE, even just getting things running probably adds in total to weeks. My ex girlfriend hated it, and I realised I was being generally antisocial because of it, etc etc. In the end I ripped everything out, replaced with dedicated hardware devices, and only have LinuxMCE running in a Virtual Machine these days for testing and a bit of fun. Sometimes I just wonder (partially in awe - don't get me wrong) how much of your life you are prepared to devote to this project. It's impressive that you do so much, but seriously that would get to me after a while - even doing 1/10th of what you do was too much. Don't you want to set something off which just sustains itself and you can dip in and out of it? It must frustrate you to see the lack of interest in the programming tasks, the constant "when is the next release?" posts. I'm not trying to spread doom and gloom - just suggesting that there may be a way to leverage support from existing linux communities in other ways than just hoping they will see the light and jump ship to the architecture which is "light years ahead" of any other media centre. I don't doubt that pluto were very clever. Even looking at the database I thought "WOW!" the first time. But perhaps they were a little too clever.... Who knows...

I did say I was happy to be wrong ;-)


Hi,

can you share your experiences with us - I guess you use XBMC now ?
It's always good to know how other media systems feel like, their strengths, weaknesses....

Regards,

Bulek.
Title: Re: Reinventing the wheel
Post by: totallymaxed on June 08, 2010, 01:57:56 pm
In the daytime I work as a presales solutions architect for a software company. I've had chance recently to sit back from linuxMCE and have a think about things in a broader sense, as if I were approaching a project at work, and try to think objectively. Here are my thoughts.

LinuxMCE is a media center. Cool.

What is great about it? Well it can turn on my lights when the film has finished, I have easy touch screen access to lighting scenarios around the home, when I'm watching TV I can see who is calling when the phone rings, etc etc.

What makes LinuxMCE indispensible and unique is the cool integration between security, HA, media, etc. What everyone complains about? Media playback.

I have heard some of the core devs getting very dispondent at the mountain of work to do on LinuxMCE to do things like remove non open source code, bring it up to the current standards for media center UIs such as XBMC, write new plugins for things like Hulu, Mame, Pandora, etc. I feel sorry for the small handful of devs who are literally recoding a mammoth system, so complex and interconnected that probably not even one person alive knows every inch of it and never will. Maybe it's time to stand back and ask if the task is really too big, and also if it is justifiable (read on!)?

I also did a bit of playing around with Boxee and XBMC and suddenly thought - if the only thing stopping me using these packages full time was the lack of cool HA/security/climate integration, then wouldn't it be better to take the media playback from XBMC into LinuxMCE all get all those Hulu, Netflix, iPlayer, Pandora plugins for free, and not have to maintain this huge beast anymore? There is even now a mythtv plugin for XBMC which allows liveTV and recorded program watching, and of course it's very much under active development by a large community.

XBMC is all easily controllable via a HTTP API, which is even better.

I would propose to strip frontend duties away from the orbiter (except for non MD devices) and have XBMC launched by the DCERouter on startup. The HA, security, and telephone menus would all then be XBMC plugins. It should be possible to get devs in the XBMC community to write these plugins if we get them excited enough, which would be great news obviously.

- Leverage existing iphone/smartphone apps for XBMC control
- UI3 for things like webDT goes into XBMC dev pool and you get their dev support and involvement
- No more coding new plugins for media playback as new web portals launch (there will be a lot over the next few years you can bet! - how many do you want to code?!!)
- Development on things like the mame plugin becomes an XBMC plugin, and again gets a wider audience and contribution from XBMC devs
- DCERouter stays in there and modularity is preserved

Seems like a win/win situation.

Does linux need separate teams writing competing media centre applications? Is this for the best? It kind of defeats the whole open source philosophy of contributing code to make the pool better so that it benefits everyone involved. Lots of separate pools reduces the chance of benefits being shared.

Regards,

Chris

Chris,

I could stand on either side of this debate (and have many times here in the past). Put simply LinuxMCE is not merely a media centre. Media is just one facet of its feature-set...however even in that one area LinuxMCE does a bunch of things that XBMC (and all other media centres) dont do...the Orbiter UI is network aware and can be used to manage/control/interact with pretty much any other part of the system ie it doesn't just run on one machine and it doesn't just use IP based API to remotely control another machine turning itself into a big IR remote (which is what all other media centres do in reality). This is because they were never designed as part of a House wide system - its not a criticism in anyway of them.

Clearly XBMC (and MythTV) have increasingly sophisticated skinning engines that can build richer & richer UI's...but none of those UI's or the underlying skinning technology are designed to work in a house wide networked sense at all. So although they are visually rich they are sadly lacking in many areas where ironically the current orbiter is really very powerful indeed. They other problem is that although XMBC etc have a rich set of internal plug-in's none of these have any concept of house wide multi-device capabilities at all - they represent  functionality that is essentially locked inside XBMC and exposing these outside of XBMC would need considerable work. I am glossing over massive amounts of detail here but I can honestly say you would not be simplifying anything at all with this approach - you'd be gaining some 'eye-candy' capabilities but would end up with a massive amount of re-engineering to replace what is already in plaice in the Orbiter.

The alternate approach is to use XBMC much like we do MythTV or VDR today - ie put a DCE wrapper around them and drop into XBMC whenever you needed to play media. However you would end up with just what we have now with MythTV and to a lesser extent with VDR ie two graphically different worlds and all of XBMC's internal plug-ins would be trapped in the XBMC 'world'.

Search the forum here and you will see this is a well trodden, much had conversation that springs up here from time to time. As far as I am aware to-date no one has actually gone ahead and put their 'money where their mouth is' and tried to implement what they proposed. I have to say that unless you are prepared to do that personally or can gather some other like minded people around your proposal who can, then I can't see that you will get any traction from the community.

All the best


Andrew
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 08, 2010, 05:40:36 pm
Hi guys,

Actually I'm not using XBMC, I use a Xtreamer which has a crappy GUI but is reliable and I can invite the girlfriend round to watch a film without ending up getting my balls cut off. Ho hum! :-(

I guess I'm just trying to see if there is a way that time and effort can be saved - I'm not making a feature request. My particular worry is continuing maintenance effort for what is essentially a huge branch of multiple linux software products all maintained by 4 or 5 overworked guys. you can see the tension as sparks fly in the forums! I don't think that adding a new plugin to control XBMC to LinuxMCE really adds anything. Who knows though - maybe it would entice some of the XBMC crowd over? We'd be stuck in the situation we were with Myth a few months ago though, where things weren't that tightly integrated. And if we look at Mplayer, Xine, Myth, VDR, Asterix etc, do we have any evidence that their developers came over to LMCE? I'm guessing not.

What do you think? I don't want to set off trying to achieve something which is unhelpful and quite frankly a waste of my and anyone else who care's to be involved's time. This is why I don't agree with the "if you want it, make it" line that I keep hearing. That kind of behaviour will lead to an increasingly fractured product which confuses the user no end (Mplayer/Xine choice and VDR/Mythtv is probably bad enough as it is!). Although too much talk and no action might annoy a few people it's better than just setting off at full speed towards an unknown target.

@golgoj4 - no offence taken, just heard your line so many times on these forums and it got to me I guess. Regarding your question, if you are not sure about issues with the interface for watching media then I can assure you that after a couple of years of lurking around these forums it's something which is heavily discussed/criticised by new, existing, and departing(!) users. I don't have any particular problem with it personally, but that's not always the full picture with software of course.

General point: Did anyone try to drum up support on the forums of the integrated products (asterisk, xine, myth etc)? Have they been shown videos etc? This could be an interesting area to explore maybe?
Title: Re: Reinventing the wheel
Post by: tschak909 on June 08, 2010, 05:43:09 pm
Really, honestly, the whole point of the system is to make module choices transparently. We've chosen what media engines to use by default. But they can be changed. Anything else said about this is opinion.

-Thom
Title: Re: Reinventing the wheel
Post by: totallymaxed on June 08, 2010, 10:55:57 pm
Actually I'm not using XBMC, I use a Xtreamer which has a crappy GUI but is reliable and I can invite the girlfriend round to watch a film without ending up getting my balls cut off. Ho hum! :-(

Sounds like you are suffering from letting your GF loose on 'beta' software...its beta...that why its not shipped ;-)

That why we stuck with our 0710 based current build of Cascade & Dianemo...the most important feature we need is reliability...it is the single most important feature...no buts thats the truth. We would be out of business in a few weeks if all of our customers experienced the reliability levels that a beta release inevitably brings. So we have stuck with what is now a very stable and reliable build. Thats not to say its perfect...it is not...no software ever is...but its stable & reliable to the extent that we do not hear from the majority of our customers for many months at a time.

The current 0810-Beta is still in 'beta' so it will hqave rough edges and stability issues...thats why the Dev's want the community to use it... ;-)

All the best


Andrew
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 09, 2010, 04:31:25 pm
Yeah but you know I *had* to have the Beta! Don't get me wrong - I'm not complaining about stability here. You won't see a "this is why I left LMCE post from me!". This post was about making a suggestion which I hoped would save someone time and improve ease of maintenance and promote involvement by devs from other projects. I've seen a lot of frustration on the forum and started thinking - is this the right path? Is there a way to solve this? The answer was no, not right now, but it was worth asking I think. Thanks for the info all.

Chris
Title: Re: Reinventing the wheel
Post by: tschak909 on June 09, 2010, 04:42:01 pm
Really, my frustration stems from the fact that people aren't exploring the codebase, and asking questions of those of us who have been here a while.

We have an amazing architecture here, that is unparalleled in so many areas, and while there are some weak areas in the area of Orbiter, the architecture is such that all these pieces can be replaced.

At this point, myself, along with anyone else interested, are trying to build a series of "toys" in a set of UI toolkits, trying to find something to standardize on for the next generation of Orbiter. I have gone over this in the Clutter thread, so I won't recap it all here. But right now, it's all about trying to spur a curiosity in the codebase. This system can do ANYTHING, it's _DESIGNED_ this way, it's not a side effect, or a consequence, but it is the result of applying enterprise design patterns to the problems of home automation. While there are obvious warts in the code (yes, they are everywhere, for various reasons), these can be and are being fixed, we just need more hands.

Chris, I know you're looking at this from the standpoint of a salesman, that's not what we need at this point. We need a few more people who are willing to understand the architecture, and not dismiss it as "crap" because they do not understand it yet.

-Thom
Title: Re: Reinventing the wheel
Post by: totallymaxed on June 09, 2010, 05:35:20 pm
Yeah but you know I *had* to have the Beta! Don't get me wrong - I'm not complaining about stability here. You won't see a "this is why I left LinuxMCE post from me!". This post was about making a suggestion which I hoped would save someone time and improve ease of maintenance and promote involvement by devs from other projects. I've seen a lot of frustration on the forum and started thinking - is this the right path? Is there a way to solve this? The answer was no, not right now, but it was worth asking I think. Thanks for the info all.

Chris

Well I think in retrospect keeping 0710 as the 'stable' version so that community members who were not interested in 081-alpha/beta testing could stick with it would have been sensible. But thats 'water under the bridge' now.

However as you were backed into a corner on the usage of 0810... you did not really need to expose your GF to it...buying a cheap DVD player comes to mind or booting into some other media player software when she comes over is another option ;-)

All the best


Andrew
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 09, 2010, 08:15:30 pm
@Andrew Exactly :-) I have LMCE 810 running in a VM for fun/testing. It has some zwave stuff and a USB-UIRT attached. However I can control all the zwave stuff without LMCE and can play the GF a video from the Xtreamer (albeit with a much worse UI than LMCE). Even when 810 is stable I think I'll keep the Xtreamer as a backup - a core hardware failure is never out of the question. As I said I am not complaining - I understand the risks of running beta software.

@Thom Yes this must be extremely frustrating. I'm just not sure what the answer is. Have the LMCE senior developers made some presentation to the dev communities of Xine, Mplayer, Myth etc? Perhaps we could make a slideshow describing all the cool architecture features and fire it over? I am up for doing this with a little guidance. If the system really is amazing under the hood (I believe you from what I've seen) then those guys should get fired up.


Title: Re: Reinventing the wheel
Post by: valent on June 14, 2010, 04:21:36 pm
I see what you are getting at Chris, and I completely agree, but I thing that lmce devels know that they shouldn't keep their own patches and fork upstream core, that is road to disaster.

I'm a involved with Fedora project and they have a really strong "upstream only" [1] policy and if there isn't such a policy in LinuxMCE project I strongly suggest you thing about it. You can borrow ideas from Fedora wiki and make a similar wiki page on LMCE wiki, I can do it but I need to know do you agree with all ideas on Fedora wiki or some should be changed or even add some new ones?

[1] https://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
Title: Re: Reinventing the wheel
Post by: valent on June 29, 2010, 12:30:25 pm
I have just found out this video: http://www.youtube.com/watch?v=a6Colv6_pH0

showing that even a much bigger and commercial project like Control4 just go the easier and smarter way of using an existing media player like XBMC. Guys I urge you to please include XBMC in LinuxMCE ASAP becuse current media player is just years behind XBMC, it has no support for multiple audio streams, multiple subtitles, heck subtitles aren't even enabled by default and when they are enabled each update disables them, and each subtitle needs to be renamed from standard name scheme movie.srt to movie.avi.srt. Each appliance I tested ranging from cheap DVD/DivX players, multiple media centers (Moovida, XBMC, Boxee, GeeXBox and others), any small hdd based divx/mkv player., etc... and yes there is also support for built in multiple audio streams and multiple subtitles in mkv files.

Just to implement all this you will need lots of work, and when you implement all of them LinuxMCE media player will still be 2nd rate player missing lots of fancy features that others have.

I'm not trying to dump on your work, just to say again what is said in this thread so many times - why reinvent the wheel? Use some other proven media player like XBMC to play media from DCE wrapped plugin. Just look how Control4 guys did it.

If you say - if you want ot then go and do it, I can't because I don't know how to code, but if you say to us if you wan't this feature it will cost you $$$, that split amongst a few people who would really like to see this feature wouldn't be too expensive and I'll be the first to donate for this feature.

Of if you have some tedious tasks that we can trade - maybe some of us can write WIKI documentation (within our level of knowledge), send xy press releases, paint your toe nails, wash your feet, you name it ;)
/me flame on ;)
Title: Re: Reinventing the wheel
Post by: totallymaxed on June 29, 2010, 12:58:23 pm
I have just found out this video: http://www.youtube.com/watch?v=a6Colv6_pH0

showing that even a much bigger and commercial project like Control4 just go the easier and smarter way of using an existing media player like XBMC. Guys I urge you to please include XBMC in LinuxMCE ASAP becuse current media player is just years behind XBMC, it has no support for multiple audio streams, multiple subtitles, heck subtitles aren't even enabled by default and when they are enabled each update disables them, and each subtitle needs to be renamed from standard name scheme movie.srt to movie.avi.srt. Each appliance I tested ranging from cheap DVD/DivX players, multiple media centers (Moovida, XBMC, Boxee, GeeXBox and others), any small hdd based divx/mkv player., etc... and yes there is also support for built in multiple audio streams and multiple subtitles in mkv files.
The internal media player in LinuxMCE supports multiple audio streams, multiple subtitles and all DVD options in ripped DVD's. Our customer use these options heavily. If you using a remote Orbiter to control the MD that is playing the DVD stream then you also get access to the DVD main menu & setup menus on the Orbiter you are controlling playback from. This remote Orbiter might be an iPad, and in-wall touch panel, a ASUS EeeTouch, a DT366 or DT362, iPhone, iPad Touch, Android Phone or tablet or pretty much anything else you can run a modern Web browser on.

The Orbiter UI is lacking in a number areas and support for some aspects of mkv's etc are also an area that needs some development and we all know what those are...there are many threads that discuss these here in the forum. The problem with Moovida, XBMC, Boxee, GeeXBox and others however is that their UI does not scale well (or in some case at all) when you try to move them to other devices like touch panels or handheld devices. So you end up with a compromise which is probably why no one has really put any effort into this.

Instead of moaning about it to the Dev's you should create a new thread here and try to gather some like-minded people around your proposal and get your proposal implemented. Everyone on the development team is fully engaged in what they are already working on so you need to look outside the Dev team to get this new capability added. If your proposal is something others also want then making it a reality should be doable.

All the best


Andrew
Quote

Just to implement all this you will need lots of work, and when you implement all of them LinuxMCE media player will still be 2nd rate player missing lots of fancy features that others have.

I'm not trying to dump on your work, just to say again what is said in this thread so many times - why reinvent the wheel? Use some other proven media player like XBMC to play media from DCE wrapped plugin. Just look how Control4 guys did it.

If you say - if you want ot then go and do it, I can't because I don't know how to code, but if you say to us if you wan't this feature it will cost you $$$, that split amongst a few people who would really like to see this feature wouldn't be too expensive and I'll be the first to donate for this feature.

Of if you have some tedious tasks that we can trade - maybe some of us can write WIKI documentation (within our level of knowledge), send xy press releases, paint your toe nails, lick you balls, you name it ;)
/me flame on ;)
Title: Re: Reinventing the wheel
Post by: tschak909 on June 29, 2010, 02:20:08 pm
and once again, valent talks out of his arse... You simply do not understand the code base we have, or what we have left to do.

-Thom
Title: Re: Reinventing the wheel
Post by: chrisbirkinshaw on June 30, 2010, 09:33:19 pm
Valent if you are keen then you should be able to knock up a GSD device to control the XBMC as if it were a STB. I am guessing that then you just need to make a device template for it which includes the launching of the app itself. I really don't know about that last bit though. You'll need to ask around. It may be possible to do it all without coding anything more than ruby but I'm not certain.
Title: Re: Reinventing the wheel
Post by: tschak909 on June 30, 2010, 09:59:54 pm
chrisberkinshaw, that would not work. You need to study the media system more...

You would hit brick walls very quickly, with that approach.

The reason being, is that because there would be no plugin to handle the media stream (Media stream in this case is an object containing media metadata properties that the Media PlugIn uses to route things to their correct devices. see src/MediaStream.cpp), the device would be treated as a non-pluto media type. This means it would attempt to try and find a tuner card to send the output to, and  failing that, it would try to switch media inputs for connected pipes to the device. Since it would be an embedded media player, there would be no pipes to switch to, and you would in essence have a window that would not be properly mapped into Orbiter.

You need a media plugin, to create a new media stream type, which defines, whether it is audio, video, etc. And to find the media player for a given entertainment area, and send the appropriate play commands to it.

While the Player could possibly be implemented as a GSD, the PlugIn must be done in C++, as it needs to run in the DCE Router's memory space, and grab pointers into the Media Plugin to call functions such as RegisterMediaPlugin, etc.

-Thom
Title: Re: Reinventing the wheel
Post by: totallymaxed on July 01, 2010, 07:35:38 pm
chrisberkinshaw, that would not work. You need to study the media system more...

You would hit brick walls very quickly, with that approach.

The reason being, is that because there would be no plugin to handle the media stream (Media stream in this case is an object containing media metadata properties that the Media PlugIn uses to route things to their correct devices. see src/MediaStream.cpp), the device would be treated as a non-pluto media type. This means it would attempt to try and find a tuner card to send the output to, and  failing that, it would try to switch media inputs for connected pipes to the device. Since it would be an embedded media player, there would be no pipes to switch to, and you would in essence have a window that would not be properly mapped into Orbiter.

You need a media plugin, to create a new media stream type, which defines, whether it is audio, video, etc. And to find the media player for a given entertainment area, and send the appropriate play commands to it.

While the Player could possibly be implemented as a GSD, the PlugIn must be done in C++, as it needs to run in the DCE Router's memory space, and grab pointers into the Media Plugin to call functions such as RegisterMediaPlugin, etc.

-Thom

Thom - I think Chris was suggesting running xbmc on a external machine and treating that whole machine like an STB.... at least that was my take. Now doing that would be pretty crazy I agree!...but I cant see why that would not work as its what we already do with hardware STB's etc.

Andrew