Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - tschak909

Pages: 1 2 [3] 4 5 ... 12
Developers / LinuxMCE Game Player - Game Recording
« on: December 05, 2011, 06:43:42 am »
Hello everyone,

As part of the refactoring work that i've been doing to Game Player, some new features have become possible, you've seen mention of the Multi-Room Game Play, in an earlier thread in this forum, and now I've put the finishing touches on a first pass of Game Recording.

How does it work?

A new button has appeared on the Game Remotes, Record. Pressing the red Record button, pops up a message that recording has started, and you can then play the game as normal.

Each visual frame is stored with its associated audio frame in uncompressed format, so the resulting files get very large, very quickly, for example, for most NTSC arcade games (256x224), 10 minutes of gameplay equates to roughly 5 gigabytes of space. So be sure to have plenty of space.

Once you're done recording, press the red Record button again, and a screen will appear on the orbiter you pressed record from, asking you where to place the file, what to name the file, and whether it should be public or private. Once you select the appropriate options, and select a place to save, the system will inform you that it has to process the video (compress it), and that it will inform you when it is done. You can then proceed with other things while it works in the background. While it is compressing, you can see the progress in the Pending Tasks section under Advanced (the same place you see things like orbiter regenerations, and the like), and you can stop a transcode if you wish. (I do not show the pending tasks functionality in the video however, I just forgot to go there.)

The video then shows up in your video list, and you can do with it as you would any other video file. For the sake of simplicity, the file is stored as an XVID AVI file, with mp3 audio. You can then play this as often as you like from your videos list, or upload this to YouTube, whatever you wish.

A video showing the functionality is here:

Enjoy, more things coming soon :)

Developers / LinuxMCE Game Player - Multi-Room Game Playing
« on: December 01, 2011, 07:46:56 am »
As of now, a feature that I had wanted in the Game Player from day 0, has now started breathing its first breaths,

that is, multi-room game play.

What does this mean?

Simple, A game can be started in the Bedroom, and it can, via the floorplan, be stretched across, from the bedroom, to the living room, with one player at each TV, and be able to play the game. LinuxMCE contacts the emulator engine, and if it is supported, LinuxMCE will take care of setting up the emulators on the target media directors to accomplish multi room game play. At present, this is MAME, and more engines will be supported.

Any limitations of this particular procedure would be a direct result of limitations in the underlying engine (for example, MAME currently will not allow save states to be loaded while multi room play is in use, etc.)

As a demonstration, I have uploaded two new videos to youtube, one playing Street Fighter 2, another playing Kung-Fu Master: (1/2 - street fighter 2) (2/2 - kung fu master)

Enjoy, This feature needs lots of work, but it will be available in a future build.

Users / New Feature: USB Gamepad Support for on-screen control
« on: September 24, 2011, 05:04:58 am »
Hello everyone, I've finished the support for using USB Gamepads to control on-screen Orbiters on TVs within LinuxMCE. I have pasted the wiki content of the following article because I am too lazy to type it out again,


LinuxMCE as of 10.04 can allow any media director to control its on-screen [[Orbiter]] using a standard [ USB Game Pad].

== How to install ==

Simply plug in the USB Game Pad, at any time, and the system will automatically detect up to 4 USB Game pads, and allow them to control Orbiter.

== How to use ==

=== Navigating items ===

==== Direction Pad ====

Items can be navigated either by a gamepad's direction cross, or by using the analogue wheels. Pressing down and releasing will cause the cursor to move in the direction pressed on the game pad. Currently button presses are not repeated.

For MythTV, pressing up and down, will cause the channel browser to change to the previous and next channel.

==== Buttons ====

By default, the USB Game Pad Remote device installed is mapped for a SIXAXIS(tm) compatible gamepad with 12 buttons total.
* The four diamond buttons.
** Button 1 - '''OK/Select/Enter'''
** Button 2 - '''Back'''
** Button 3 - '''Pause'''
** Button 4 - '''Stop'''
* The Front buttons
** Button 5 (''aka L1 - aka the small one on the left'') - '''Volume Down'''
** Button 6 (''aka R1 - aka the small one on the right'') - '''Volume Up'''
** Button 7 (''aka L2 - aka the big one on the left'') - '''Page Down/Skip Back'''
** Button 8 (''aka R2 - aka the big one on the right'') - '''Page Up/Skip Forward'''
** Button 9 (''aka what most people think as Select'') - '''Back''' (''same as Button 2'')
** Button 10 (''aka what most people think as Start'') - '''Home'''

=== Plugging and Unplugging ===

Game Pads can be plugged and unplugged at any time. The router will not need to be reloaded.

=== Use Within Games ===

Because there is no Home Button on most USB game pads, When a game is started by the [[Game Player]], the system will automatically pass through the USB game pads directly to the Game Player engine; any subsequent usage of the gamepad will be ignored by Orbiter unless Orbiter displays another visible screen. This means that you will not be able to get to the home menu currently while playing a game (because the start button would be mapped to the game system.)

== Changing the controller mapping ==

(preliminary instructions follow)

The controller mapping can currently be changed by accessing the web admin, selecting [[Advanced Pages Devices|Advanced > Configuration > Devices]], selecting the USB Game Pad remote device closest to your media director, and scrolling down to see the Configuration device data entry.

By default, the controller mapping is:


The syntax is very simple:


The remotemapping entry corresponds to an entry in the [[Infrared Remote Buttons Understood by LinuxMCE|RemoteMapping]] table,

The second and third components right now correspond to the same thing (the third field is unused, but must be specified), that is, what USB button to press, either consisting of:

* A direction: UP, DOWN, LEFT, and RIGHT are currently understood. (do we need more?)
* A Button #, B1, B2, B3, ... B11, B12, for example.

Using this nomenclature, and the link to the [[Infrared Remote Buttons Understood by LinuxMCE|RemoteMapping]] table, it is possible to map any button on the gamepad to something useful in LinuxMCE. The Remote control template used will be the one closest to that media director (so yes, it is possible, although ill advised, for each media director to have a different button mapping.)

== Usage in AV Wizard ==

It is possible, to use the gamepad with the AV Wizard. Simply attach a game pad before powering up the unit. Holding down the 1 button while the system is booting will cause the [[AVWizard]] to launch.

Once the [[AVWizard]] has been started, it is possible to use the gamepad to navigate and select items within the wizard, and also to select explicit video modes, just as if number keys had been pressed on a real keyboard:

The following buttons are mapped for the AV Wizard:

* Button 2 - DVI
* Button 3 - DVI-2
* Button 4 - HDMI
* Button 5 - VGA
* Button 6 - VGA-2
* Button 7 - Component
* Button 8 - Composite
* Button 9 - S-Video

== Source Code ==

Source code for this module may be found here:
* []

== Trademarks ==

SIXAXIS(tm) is a trademark of Sony Corporation.

(and before anyone asks, yes, SixAxis controllers that are connected via a USB cable work. Bluetooth support will not work yet until we do some serious re-engineering of our BlueTooth stack!)

I have uploaded a new video:

I have added support for the Following game systems to the LinuxMCE Game Player:

* Super NES / Super Famicom
* Sega Genesis / MegaDrive
* TurboGrafx-16/PC Engine/SuperGrafx

as before, these game types are integrated within the system, and afford all of the functionality shown in previous videos, and come with box art.

Mega Drive/Genesis support will be added via the Game Player at some point. (along with Super Famicom/NES, and PCEngine/Turbografx16)


Hello, everyone.

After a bit of time away from the Game PlugIn and Player, I've decided to push it a bit closer to the 100% mark of completion by implementing the following:

* Bookmarks

LinuxMCE games can now be bookmarked, using the same facilities used for Audio and Video items. You can save as many bookmarks for a game as needed, and name them as appropriate. The system will take a snapshot with each bookmark, and place it in the bookmarks page. The bookmark will also show up in your currently playing playlist for a game.

See it here:

In addition, Automatic saving is also done, when you exit a game. The next time you play the game, Orbiter will ask if you wish to resume where you last left off, just like with audio and video. It is also possible to move a game from one media director, to another, and thus Follow Me also works.

See it here:

In addition, Box art has been uploaded for all the currently supported game systems:

* Atari 2600
* Atari 5200
* Atari 7800
* Intellivision
* Colecovision
* Sega SG-1000
* Sega Master System
* Nintendo Entertainment System (NES)
* Nintendo Family Computer (Famicom), Including Famicom Disk System support.

With more to come!

You can see an example of the NES game library here:

I also did a demo showing the Famicom Disk System support, as well as a little back story on Super Mario Bros. 2, and the REAL Super Mario Bros. 2 (Which ONLY showed up on the Famicom Disk System), here:

All of the above improvements have been rolled out in the build system, and will be in the next snapshot for 0810, and are already available for the 1004 build.

If you wish to update your existing system, please do an apt-get update before selecting the game player, so that you will be sure to get the latest version.


Developers / Changes to support Capture Card Audio Port.
« on: May 19, 2011, 03:22:57 pm »
If you wish to see all the appropriate changes, you can see Bug #1063 in trac.... But basically:

* The addition of a new DesignObj in Designer.

A new designobj (6063), has been added to support the new screen. It looks like all the rest of the Setup Wizard screens, except that this one has a new data grid, dgCaptureCardAudioPort, which gets its information from the Media Plugin.

The datagrid generator for this grid gathers all the devices of category Capture Card Audio Port, for a given PK_Device (specified in a previous screen), and puts them in this grid.

Selecting an entry from the datagrid on this designobj will fire a Set Capture Card Audio Port command in the Media Plugin, to assign a number to the FK_Capture_Card_Audio_P devicedata. This number is the device # of the corresponding Capture Card Audio Port device template.

As such, I have made a number of new templates in this category:

* Front Analog Port
* Rear Analog Port
* Default Port

more can be added as needed to best describe tuner card audio ports, and they are added in exactly the same way as the Capture Card Video Ports.

Right now, the Extra Parameters device data is used by the Media Plugin to specify what to pass to the script, as of now, we call this script as:

Code: [Select] /dev/video0 0 0

$1 is the block device (translated from <%BLOCK%>)
$2 is the desired video port as seen by v4l2-ctl
$3 is the desired audio port as seen by v4l2-ctl

This is called from Media_Plugin::StartCaptureCard(), by the App Server, before the call to start the stream by Xine Player.

Hopefully this will help some people who are making device templates for tuner cards.


Users / New Setup Wizard Screen: Set Capture Card Audio Port
« on: May 19, 2011, 03:14:37 pm »
Good morning.

A new screen has been added to the Setup Wizard.

Some devices like the Hauppauge HD-PVR tuner device, have more than one set of audio plugs which are selectable for input. Until now, these were ignored. I have added all the necessary device templates, design objects, and other bits to the system to allow tuners with more than one audio input to be selected right from the Setup Wizard..

This screen sets between the A/V Destination for a Video Capture Port, and the Rooms you wish to use this A/V device screen in the Setup wizard.

A Video showing the new screen is here:

If you want to see the screens clearly, I suggest selecting the 720p or 480p resolution appropriately.
Let me know what you think,

p.s. There is a corresponding developer thread here: talking about the internals.

Developers / Solicitation for Development: Desktop / Workstation Agent
« on: April 09, 2011, 07:20:44 pm »
Hello, Everyone.

I had heard quite a few times over the years, the wish for greater integration with Desktop / Workstation computers within the home. Things like:

* Being able to start a piece of media on a workstation, or move a piece of media between a TV and Workstation, on eitheHar an orbiter, or the file manager
* Having a convienient orbiter available on a workstation to do the above, or control other house functions
* Having a way to turn the monitor on/off automatically, in response to changes in house mode (when going Away for example, or waking up, or presence detection)


I have put together a quick prototype of this, and it is in SVN in a few pieces, for those interested in finishing development of such a component.

Wiki Page is here:

A demo video is here:

No, I am not putting up instructions on the wiki of how to install the components, why? Because I want to foster development within here, and discussion, to force the issue towards making it easily installable, rather than letting setup instructions languish on a wiki that people just muddy through.


Users / PadOrbiter 2.0
« on: March 10, 2011, 06:18:45 pm »
After working on it off and on for the last year, I have prepared the first version of PadOrbiter 2.

What's different this time?

Primarily, PadOrbiter was a distribution that was hand crafted specifically for a single device, with no allowance for different hardware. It was designed to run on a specific run of WebDT 366 tablets that found their way onto the market in the latter half of 2008. They had very limited amounts of memory, and very constrained resources, so I had to be extremely creative with what I put on the devices.

Times have changed.

Now, we are amidst ever more capable portable devices, which contain much faster processors, more RAM, and more storage space than ever before. These devices also contain video accelleration cores as part of their system design to aid in the playback of high-definition content. These devices take on many forms, but we are starting to see a mass commoditisation across some common axes:

* Intel Based
- Atom Z or N series CPU
- GMA3150, GMA500, GMA600 GPU

* ARM Based
- Cortex A8/A9 based CPU, such as OMAP3/OMAP4 or NVIDIA Tegra
- SGX5535 GPU and TI Video accelleration (found in the N900), or NVIDIA Tegra

More designs are on the way, so the question becomes how do we handle these devices effectively?

While the Proxy Orbiter based designs have allowed developers to quickly get existing orbiter designs onto existing iOS and Android platforms, I see this as a stop-gap. This goes against one of the primary goals of LinuxMCE, to unify virtually every single piece of technology in the home.

To do this properly, will take a two pronged approach:

* For native systems, such as Android and IOS, Native DCE implementations need to be ported (in the case of Android), and/or built (in the case of iOS)
* For devices that will just run Orbiter, a version of the Orbiter based on MeeGo technologies can be used, This thread addresses this particular instance.

Why? Isn't Orbiter just a glorified touch menu?

Yes, but since these devices have far more advanced video playback and GPU processing features, we can actually make every portable device not only a control point, but also a media end point.

Also, consider PlutoStorageDevices. Once this is running on PadOrbiter v2, the host device will suddenly be able to share USB storage devices with the rest of the house, transparently. Imagine being able to convieniently be able to plug in a friend's portable USB disk, onto a nearby Joggler. It is not only certainly possible, but it will be done.

PadOrbiter v2 also contains in addition to the existing Orbiter code, libraries for Qt Quick/QML and Clutter, which I have been investigating to build a new Orbiter on top of. So the entire stack is FORWARD COMPATIBLE with not only the newer, less expensive hardware coming out, but it also provides the software platform bits needed to carry the Orbiter idea forward to bring in new ideas. Add to this the additional capabilities of media playback and control, and advanced features like pluto storage device points, and you have a solution you can't get anywhere else.

For now, I am placing kickstart files in the following place

These can be built using meego-image-creator, which can be found by your friendly google.

Joggler images must be built with -f raw

and for everything else I typically use -f livecd

I will release images later, as I still am refining some bits.

p.s. Oh, there's a video of it running on the Joggler, here:


Developers / ONGOING: WiiMote support
« on: September 11, 2010, 09:03:21 pm »
Hello everyone.

After a 5 month hiatus from the project so I could collect my thoughts and recover from the intense burnout, I am back in the saddle again.

We are all squashing bugs as best we can, and I am also trying to finish up some things I had started over two years ago. One of them being Nintendo Wii Remote support.

After much deliberation and study of the existing solutions out there, none of them were adequate enough for what LinuxMCE really needed. They were all nasty hacks on top of nasty hacks, which manifested side effects in various ways, such as not being able to use but in one room of the house, not being able to use more than one WiiMote properly, insanely inconvenient button mappings, etc.

With my initial work, I tried to use the existing Bluetooth infrastructure to detect the Wiimotes. While this did work, and the Wiimotes were detected by the orbiter, they were incorrectly detected as mobile phones, and an orbiter would attempt to be generated for them. This causes undue waste in time and resources generating an orbiter which will never be used. In addition, the bluetooth device detection loop currently in place to detect mobile phones clogs up the bluetooth dongle so that other programs can't detect things. This presents itself most commonly as not being able to pair the remotes "on the first..second...fifth...thirty-seventh try." but just fine on the "thirty-eighth." Very inconvienient!

The initial try used the wminput program from the CWiiD project to map buttons, direction pads, the IR pointer and Accelerometers, to kernel input events, so that to the rest of the system, the wireless WiiMote looks just like a wired joystick and/or mouse. While this did allow it to work for more than 60% of the use cases, this is not sufficient for daily use.

The reason, is quite simple, the WiiMote is a hybrid device. It presents itself as both a game pad and a remote control device with a very zen-like button layout.

You may think the solution is to force all of our connected programs to use the same "button" layout universally, but this would only work if one WiiMote were to ever be used with a single media director in the house. There have only historically been single keyboards and mice connected to computer workstations, and this bears itself out with various programs that re-map keys.

Why do we need to do this in the first place, when we only have one UI to deal with?

Wrong, we have multiple UIs to deal with.

We need to deal with:

* Standard orbiter displays
* Media playback displays
* On-screen navigation displays such as when MythTV displays menus
* File Browser displays
* Game Player displays


And with each of these, they need their own button mappings..

For example, the trigger and A buttons in standard orbiter displays should map to "OK" and Left Mouse button simultaneously. (The reason for this, is historical, and it's quite silly, but yes, it needs to be this way.)

and in the File browser, the vertical 1 and 2 buttons should map to Page up and Page Down.

While playing media, the 1 and 2 buttons should map to the skip buttons (which change channels or change tracks, depending on the media being played)

The Game Player, presents an additional challenge. There aren't multiple keyboards or mice, so distinguishing between concepts like Player 1 and Player 2 are more difficult, ESPECIALLY since wiimotes can connect and disconnect at any given time.  I can't simply hard-code button mappings across multiple applications cleanly. It's too brittle.

To solve this problem, we need to literally present a "Joystick" and a "trackball" to the Game Player, and to  the mame and mess program it is controlling. When the game player is playing, change the button and d-pad and IR mappings to present a joystick like device and trackball.

So how do we do this, while providing a mechanism to detect WiiMotes?

The solution is to provide a DCE device, which will emit device detected/removed events in response to WiiMotes being paired/unpaired, while also providing a thread which utilizes the excellent WiiUse library, to talk to the WiiMote. This thread will utilize the uinput kernel driver which allows regular user space programs access to the kernel input subsystem, and depending on which screen is visible, will change the events that get sent along uinput appropriately.

How do we determine if a screen is changed, and what type it needs to be?

The answer here has already been solved by Pluto, for their infra-red remote controls, as they do the same exact thing. See the Set Screen Type command. This is emitted by Orbiter to devices so that they can change their internal state appropriately. Normally, this is handled by IRBase, but since we're a bit outside that scope, we'll handle all this stuff internally ourselves, especially since the button combinations that we need are already known, and won't need to be changed. So modifying Orbiter to find devices in the Wii Remote category, and to send the Set Screen Type message here, is enough.

With this, now we can maintain a map of "buttons" that we need to map, and when to change them, and when we recieve the Set Screen Type command, we simply make the change. :D

This leaves Follow Me, and Using the WiiMote during the AV Wizard.

The former, is possible because each Wii Remote has its own distinct address. We can utilize the existing infrastructure in place for the Fiire Remote, coupled with this, and create a device for each family member's Wii Remote, coupled with a Wii Remote Dongle device on each media director, so that when we press the vertical 1+2 buttons together, the system will do a Follow Me media event. :)

The latter, is solved by implementing Local Mode in the DCE device driver. In Local mode, a DCE socket isn't opened, but rather, a standard UNIX socket is opened that the AV Wizard can read, so that the AV Wizard can use the wiimote, even though the entire system isn't completely powered up.

All this, just to make it all appear nice and consistent and "just work"

I will be posting more in this thread, as this develops.


Users / ANN: Podcast on FLOSS Weekly - 1 Sep - LinuxMCE
« on: August 25, 2010, 04:05:41 pm »
LinuxMCE will be featured on Twit.TV's "FLOSS Weekly" podcast on Wednesday, September 1st at 8:30 AM Pacific time. I will be interviewed by Randal Schwartz, an additional host may also be present (not quite sure, as guest hosts tend to change at the last minute.)

Hope you all enjoy. I am asking for a temporary pin on this article.


edited: wrong date in body. I am an ID10T.
edited again: they pushed me up an hour :)

Developers / Programming Task: Detect VDPAU
« on: July 02, 2010, 10:21:02 pm »
We need some way to detect VDPAU.

My thought, is to build a small C program that links to libvdpau, and does some basic initialization, if it is successful, then exit with an errorcode of 0,
otherwise, exit with another error code that we can decode, at the very least, that it wasn't successful.

Any volunteers?



Take this, put in your /usr/pluto/bin

let the router reload itself.

This fix will be in the repository on the next pass.


Developers / Work in Progress: Pandora Player
« on: June 05, 2010, 06:12:47 am »
I am drawing screens for a Pandora Player, which will play Pandora content.

Since Pandora is a purely internet feed, that dynamically changes, the standard remote simply isn't appropriate here, so a new set of screens is being designed from scratch.

Here is the first one, the playlist remote (as seen from UI1 and/or touchscreen orbiters.)

Hopefully the different buttons are intuitive. I had to go through a few passes to lay things out well.


Pages: 1 2 [3] 4 5 ... 12