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 ... 11
Users / Starting a new series of demo videos.
« on: May 28, 2013, 08:42:33 pm »
Hello everyone,

After years of doing cell phone shaky cam videos, and getting constantly ribbed about them; coinciding with the purchase of a Nikon D5200 camera, I am now putting together a series of demonstration videos, titled "Why LinuxMCE?"

The aim of these videos is to show concepts present in the system, without going into a lot of detail.

The first one is here:, I will be re-editing it in the next week, to deal with some of the cuts, but I decided to keep the preliminary one up for review.



Once again, going to try to see if anyone will take this up, before I do.

It is not only possible, but trivial to write a media player for Youtube, that utilizes .

An embedded WebKit window with HTML5 video playback will more than do the job. Since this web site has very well defined contexts and input modes, at the very least, orbiter screens for Hulu can be re-used verbatim.

In addition, any events that trigger a page change can be monitored for specific URLs (e.g. /watch), so that LinuxMCE can be notified when a phone or a tablet pairs with the TV and starts sending searches and requests.

What you will need:

* Development tree in SVN:
* Read "Developing a DCE Device" on the LinuxMCE wiki
* Read the source code for Hulu Plugin and Hulu Player, as a reference guide.
* make changes to the database tables: MediaType, DeviceTemplate_MediaType, Screen, Screen_DesignObj, MediaType_DesignObj.
* make orbiter screens if you want, look at my HADesigner Screencasts for a reference, but the existing Hulu screens should work as a bootstrap at least.

This would take a weekend's worth of work to get something visible. If nobody attempts it, I will start on it, after the AirPlay Streamer is done.

Come on guys, let's get some more developer participation, for once!


Hello everybody,

I'm progressing on the new AirPlay/AirTunes implementation, and AirTunes is working well. AirPlay is coming next.

But I need some help in parallel. I need a simple radar that can consistently scan the network, and return if any Apple Mac/iPhones/iPads are present. This will be used to trigger a Device Detected event on each media director to install the AirPlay Streamer device.

This can be accomplished as a two step process:

* for each IP address in the network:
* match its MAC address against the known Apple Computer MAC address ranges:

there are a LOT of MAC address ranges, and they all need to be matched against, but this way, we can effectively match. Don't worry about sending the Device Detected event, I just need something that can give me a 0 or a 1 if an apple device of any kind is on the network.


Users / Anyone Testing the Game Player?
« on: January 15, 2013, 05:40:15 am »
Is anyone testing the Game Player in the recent builds? The entire engine has been refactored over the last 6 months, and lots of things have been improved. I need to know if all the features work.


Hello everyone,

The next generation qOrbiter is coming along nicely, and I am doing much work trying to push my current skin project for it, Data, to a more complete state.

In the mean time, until workable qOrbiter skins become available, I have taken los93sol's Touch Orbiter for android, and fixed a few issues with it, and have built it, and posde has placed it on so that it can easily be downloaded from the Orbiter Download page on the Web Admin.

If you do not have the latest snapshot, you can get the orbiter from:

Please test, and let me know how it works,


Developers / qOrbiter Skin Development: Data
« on: November 04, 2012, 05:33:09 pm »
Hello everyone, Now that I have some small bits of time, and an ASUS Transformer TF700T tablet, I am developing a skin that follows Android Human Interface Guidelines, for qOrbiter.

This skin is tentatively called "Data", and I am in the process of establishing the aesthetic. My goal is to make something that belongs on an Android tablet, as if it were a system installed application, and to utilize the tablet's huge display area and touch screen only interface as efficiently as possible, while trying to balance the GPU power of modern tablets to produce as smooth and pleasing of an experience as possible, without sacrificing day to day usability.

To help kickstart some of the development, I am using the Qt Components that golgoj4 has slipped into qOrbiter, but for certain things (such as the sliders, which do not look right in Android), I am fashioning new components to fit the bill.

For now, as I develop the skin, virtually all of the elements are fixed in place, and are not dynamic to resolution or orientation changes, and it will stay that way, until I develop a consistent enough UI to break out into components.

My current development tablet is specced as:

* Asus Transformer TF700T Infinity
* 10.1 inch
* 1.6ghz Tegra 3
* 32GB storage
* 1920x1200 display resolution.

Of note is the display resolution, as I am designing the UI to this exactly. Again, as soon as I have something more consistent and more or less completed, I will have to tear the whole thing apart and make it reusable and dynamic, but doing so at this point would be a case of premature optimization.

I have one screen in progress at the moment, a Now Playing remote. Note, that there are much fewer buttons. They aren't needed. For any other buttons, the icons on the top right (which will include a standard android menu icon) will be available to select lesser used functions. For transport control, a slider is provided, as is play/pause, and skip buttons. Gesture control will be present on the currently playing cover art to also skip playlist items, as well as a visible playlist on the right side (not there yet).

A picture here:

It's only the start, but it will come together more quickly over the next few months. qOrbiter is proving itself to be a much more flexible user interface engine than Orbiter EVER was. And that's how it should be :)


Sorry fellas, due to repeated hacking attacks, locale is being shut down. I have fought with this problem for the last two years, with repeated entries compromising my box, even after steps to harden the box, and limit its services. I'm done. It will be shut down in November. currently plays home to the HA Designer screencasts. If someone else can offer to host them, that would be great.


Users / Save States in Games
« on: September 08, 2012, 06:32:15 am »
Hey guys,

After much testing of the save game functionality in the Game Player, it has become very apparent that many of the game and computer systems emulated by MESS do not properly save their system state. If a game is played on one of these emulated systems, and a bookmark is saved, or if the automatic "pick back up where you left off" is used on these systems, the game emulation will not work correctly.

I have added a flag that is set at compile time for each supported game system, if the game system does not support save, then no bookmarks will be saved, and you will receive a message on the orbiter stating that a bookmark can not be saved.

I am sorry about this. My goal is to systematically work on each of the supported game systems, to resolve this issue, either by patching the emulation engine appropriately, or by choosing another appropriate emulation engine.

I am currently testing each game emulation engine, and will be posting a list of game systems that will support save states properly, as well as note this on each system's wiki page. But I do make a promise that this will change, and it is a goal that eventually all supported systems will be able to save their states correctly.

Again, sorry,

Users / Update on the Game Player
« on: September 03, 2012, 06:17:30 am »
Hello Everyone,

It has been quite a long time since I have really said anything on the Game Plugin. I thought I would give an update, and some of the thoughts I've been having.

The Game Player work started almost 5 years ago (my god, it _has_ been that long!) as a way of diving straight into the deep end of LinuxMCE, and into the part that few dare to traverse, the Media Plugin and its various cousins. It has been a fruitful journey which has produced an integrated way to play games within a LinuxMCE home in the same way as audio and video. There are a few more places to go, but overall, the objectives I've set out to do (even multi room game play for some systems!) have been met, the infrastructure is in place, and what is left, boils down to (MASSIVE!) polishing, adding new game systems, and maintenance of the code going forward.

As it would be while on this journey, I had decided that the first attempt at the Game Player, was just that, a first attempt, and that it needed to be significantly refactored to allow for easier maintenance going forward. I have undertaken the refactoring effort, which took the free time of roughly 9 months, and checked in the results of this work into LinuxMCE 1004 shortly before the beta freeze. This refactoring centered around the need to consolidate as much common functionality across the various emulation engines as possible, while allowing for the tweaks and customizations needed for each emulation engine, and to make it possible for other control mechanisms besides just flinging X keypresses at the emulator's window. While this work can of course be improved, it is already a significant improvement over the original code.

You can see the differences yourself by looking at code in these two trees:

Adding new systems consists of adding a new model, a new controller (hopefully based on one of the existing classes), and adding the resulting class to the EmulatorFactory. This is enough for the Game Player to be able to handle your new emulation. What is left after this involves making Orbiter controls, and is the subject of my previous Designer screencasts. As soon as I do this work on qOrbiter, I will document that as well, but that is an entirely different subject.

The Game Player can be installed from the Software Modules menu, under Media Directors in the Web Admin. The requisite modules will be installed, as well as a lot of data (there is at this moment, approximately 2 GB of data that comes with the Game Player, so that games can have nice metadata and imagery.) will install itself. After which, you place the requisite ROMs into your media filesystem (we have provided a place under the LinuxMCE file structure, called games, but game roms can be placed anywhere on a media disk that LinuxMCE knows about, UpdateMedia will find them and try to tag them as best it can.) and you can then play the games.

I have provided a way to access the options menus of the target emulator, for now, so that you can do things like set up game controllers and the like. This is not ideal, but it is a start, and will get better as the integration between the emulation engines improve.

Right now, some of the emulations require BIOS ROMs. I can not avoid this. The BIOS ROMs can not be packaged with the system (there ARE some exceptions, but ultimately, a lot of the BIOS rome are still technically under copyright), and these ROMs must be placed currently in the folder of the target system. I will explain this in the documentation which systems require BIOS roms, and which ones do not, and which ones you will need. I can not however, point you to where to get them. Do not ask.

This leaves me with some of the rougher parts of the emulation that I have yet to really deal with:

* Many ROM formats do not have well known identifying characteristics. This makes identification for a target system nothing short of a living hell. So I literally stick with file extensions. You must make sure these file extensions match, or I will not be able to tell what systems these are with. This will change when I finish work on the ROM database.

* There are different variations of given systems, not only NTSC, but PAL variants as well. Currently these are dealt with on a folder basis, a2600 is NTSC, a2600p is PAL. This forces a constraint that a ROM needs to be in a folder labeled this so that I can tell what system to pair with it. This will change with the ROM database, and the System media attribute.

* Many ROM formats are merely dumps of the address space, and have no identifying characteristics of how the address space should be configured. Many cartridges had more ROM than could fit into the address space of their target machines, and thus needed custom bank switching (often called mappers) hardware overcome these limitations. These have to be specified to the target emulation engines, if they aren't, the game can crash, or simply appear to not load.

These points can often produce an undesired effect when loading a random ROM off the street. While some ROM formats (such as the .nes format) provide the necessary information to tell the emulator what to do, many do not. Again, the ROM database  will help alleviate these issues.

What is the ROM database?

Some of you who have installed the Game Player in the past, may have noticed the addition of a database, the lmce_game database. This database was traditionally used to hold the information about games in MAME (the Arcade emulation engine we use), so that we can map names like to "Bubble Bobble". We have a variety of attributes that are attached to this information, but I have been making subtle changes to this database, to allow the addition of md5 hashes to ROM files. This information will be used to look up a ROM and its relevant metadata, including any system configuration information that may be needed.

In short, it's a step in the direction of making dropping in a ROM "just work"

This ROM database will be used alongside the existing heuristics, to try and figure out ROM names, any additional information, and if available a cover art for the game.

What are these fallback heuristics?

Well, simply, given an example ROM:

 Activision Decathlon, The (1984) (Activision).a52

we can gather:

A title: Activision Decathlon, The
A year: 1984
A Manufacturer: Activision.
.a52 tells us it is an Atari 5200 ROM.

And we look for cover art in /home/snap/Activision Decathlon, The.jpg

Which, it does exist, so we use it.

Going forward, instead of using names for the snapshots, the md5 hash will be used for the base of the filename instead, so that we can account for differences in title spelling, in punctuation, or capitalization. If such a file isn't found, the technique just described will be used.


* Test the Game Player, PLEASE! We need to test this thing, and make sure it works. Please tell me the issues you run into, file tickets, assign them to me, so that I can deal with them, but please take what I have said above into account. The goal is to make all this stuff just work, but it will take time for this to happen.

* If you don't see a box art for a game, please, try to find or make one!

I hope those interested do enjoy the game player. This isn't the end, I still have much more work to do on the game player, again as stated above, and a lot of things need to be polished, but we have a level of integration never before seen on any other platform here, and I want to keep making it better.


Hey guys,

I am sorry fellas, it seems a cracker has taken my server and turned it into his personal bot net trebuchet. In the process of doing this, he deleted my entire filesystem and replaced it with his own.

I have since rebuilt the entire server from scratch, and have hardened the system. But now I need copies of the HADesigner screencasts from anyone who has them. If you do, I would love to have them to put them back into the same place.

Thank you,

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)


Pages: 1 [2] 3 4 ... 11