Another media browsing thread..

[los93sol]

This is more of a question/feature request I guess than anything.  What currently handles media?  Is it MythTV or is it some LMCE code that is handling it?  If it is LMCE code doing the work...or even MythTV for that matter, has the idea of using XBMC to handle media been tossed around?  It would seem like a very logical choice given how good their playback quality, support, skinnability, and reliability is.  Also, while on the topic of another application, has anyone worked directly with the dev teams of asterisk, mythtv, ha, etc. to see about creating a common trunk and bringing devs from all respective teams together?

[colinjones]

Don't really understand your question, what do you mean by "handle" the media? Do you mean display/play it?

Don't know what Myth uses for live TV, but VDR and all other media (except HDDVD and BD which use MPlayer) in LMCE uses xine libraries wrapped up into a LMCE device that can send and receive DCERouter messages/events to/from any other DCE device. It needs to be a a DCE device to participate in LMCE properly. So it isn't as simple as substituting one player for another.... but there is nothing stopping someone writing a DCE device wrapper (and template) to convert another player into an option.

[tschak909]

Basically, Media Players need to be able to understand DCE commands....

This is accomplished either by:

(1) wrapping a DCE layer around an existing media library, as in the case of libXine and the Xine_Player, or
(2) creating a thin DCE wrapper that sends commands to a running media player, as in the case of MythTV_Player and MPlayer_Player.

The second option is typically done with a patched version of the software that exposes some sort of network control socket that commands can be sent to, failing that, you can use my WindowUtils library which sends raw X events (using XSendEvent), to a matching window once it's been found (again, also in the lib, you just need a partial window name match.) This is how my MAME_Player works.

The Media Plugin, has a handler, which when it recieves a MH Play Media command, finds an appropriate router Plugin on the core. The router plugin on the core is responsible for creating 'streams', which are really just handles to what's actually playing throughout the house. Once the 'stream' has been created, the media handler keeps track of it... and then it asks the Plugin to find the appropriate Player for an entertainment area. Typically, this has to be handled by the plugin itself, but the end result is, once the appropriate players are found, a Start_Media command is sent to them, with the appropriate information required by the media player (typically a filename or a URL required by the media player, and a time stamp). In addition, each media player has associated device data containing a window class and name tuple. This is the same nomenclature used when identifying windows to X.

There is an interesting catch to this. Currently, Media Plugins are registered for a given media type, and if you need to redirect to another media player for a given media type, this currently has to be hacked into the Plugin itself (look for bRedirectToMPlayer in the Xine_Plugin source), and basically you have to change the plugin's internal states for the window to latch onto, and changing the destination device to be the new player.

So, that's..basically in a nutshell, how media playing works under LMCE.

-Thom

[los93sol]

I spoke with JMarshall (xbmc skinning engine developer) and he'd be willing to at the very least consult with some of the developers from LMCE to see about how to implement and use XBMC's skinning engine and possibly other parts of XBMC in LMCE.  I've seen the HADesigner screencasts and they are nice, and I will agree that the current system is powerful, but the learning curve is incredibly steep.  I'm a major advocate of the XBMC skinning engine because it is capable of "flash-like effects", yet simple, easy to use, well documented, no special environment required, already built to handle multiple displays, etc.  It really is pretty much a perfect fit, would any developer for LMCE at the very least be interested in speaking to JM and discussing possible implemenetations, issues, etc.

[tschak909]

There is a reason for the complexity...

While YOU might not have all the devices we support? some of us do, and have customers who do.

XBMC's skinning system, while simpler to implement,  can't handle dealing with all these disparate devices.

This is an open source project, so anyone can do the work if they wish, but I do not see the merit in working on this angle.

-Thom

[los93sol]

That doesn't make sense, I'm not an expert on the intricate workings of XBMC's skinning engine or the skinning system used in LMCE, but I've used XBMC's for huge projects so have a good idea what happens behind the scenes.  Their is an event handler that passes things to the skinning engine as a common event.  That means basically when x happens do this, their are several ways to expose conditionals to the skinning engine as well.  So my understanding is that since the engine probably doesn't understand the DCE commands out of the box, an event handler should take care of the interaction there.  I really don't understand why you are so keen to the HADesigner, the guy who wrote it even said it was a hack never intended to be used more than a few months and that the original issues with it have remained untouched and have not been corrected.  That said, obviously the current solution is broken so shouldn't people start looking for and seeking out alternative solutions?

[tschak909]

I'm not keen on HADesigner. I'm keen on making sure that the concept of inherited UI development is kept. This is critical to making sure that we can develop a button once, and be able to deploy it across multiple devices, and keep the necessary semantics for each device, while taking into account a second dimension of skin compatibility.

The HADesigner tool is very buggy, but the CONCEPTS it espouses are precisely what this system needs, which is not what other UI layout systems I have used try to do. One Size Fits All _WILL NOT WORK HERE._

Again, the system goes beyond the TV.

-Thom

[los93sol]

XBMC's skinning engine is capable of doing just that.  It was not designed to work that way, but could be adapted without a major re-write.  They handle multiple resolutions through an inheritance system in a tree folder structure like:

4x3
|---all skin xml files here
16x9
|---modified xml files that don't display properly on 4x3 here
720p
|---modified xml files for 720p here

I realize exactly what you are saying about multiple devices like creating the skin once and re-using it for your devices like webpads, orbiters, and whatnot and this system was designed for TV.  However, the inheritance concept is in fact employed here, you have your base skin files in your 4x3 folder, and those will be scaled by the skinning engine appropriately for the other resolutions.  Some things will not scale properly so for those times you can load only those specific xml files that are special case, the rest of the skin will load from the 4x3 folder.  This concept could probably be expanded without a major rewrite by adding a conditional to detect the device type and resolution then load the inheritance files for that device.

JM is very good at special application techniques and has done an excellent job streamlining things so that you don't have to do redundant work to make a nice UI.  I honestly think it would be worthwhile for someone who really understands the intricate working of LMCE's engine to talk to him and see what ideas he has to help LMCE.

[tschak909]

Okay. If he wishes to talk, he can talk either on the forums, or on the chat channel. I am available on both.

-Thom