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 ... 12
Developers / Calling experienced Asterisk architects
« on: July 20, 2013, 03:55:41 am »
We are getting ready to completely nuke the Asterisk configuration we've been using (based on an ANCIENT AMP, which was never fixed for FreePBX), and to do a completely brand new configuration specially tailored for LinuxMCE, from scratch, and I need EXPERIENCED Asterisk architects to help design the new dialplan.

There is a flow being started here on the wiki: ... It is not finished, we know, we are all still adding to it, but there is enough here to start implementing a dialplan for inbound call routing.

Currently I'm doing the initial research, and scribbling down the necessary functionality and working on the flow described above, while testing out some ideas on my system here, Foxi352 is also helping out, as is posde.


If there are any of you in here, please private message me, and I will continue talking with you on email.


Developers / Developing a Weather Plugin, videos
« on: July 18, 2013, 07:33:38 am »
Hello everybody.

I am doing a series of videos detailing the creation of a Weather Plugin, as an example of how to use Plugins to add whole house functionality to Orbiter.

The first video can be viewed here:


Developers / Workshop Video: How are devices made plug and play?
« on: July 15, 2013, 03:53:13 pm »
Hey Guys,

I decided to make a video after doing a number of patches to the system so that the built in media director SimplePhone, could not only use a specific sound card, for making calls and playing rings, but that the Plug and Play detection for the Phoenix Solo USB could be debugged and made to work correctly in all cases, leveraging the knowledge I've gained over the last 4 years, since I initially added the device.

The video goes through the following points:

* What device data I added to the SimplePhone device template
* The code I needed to add to SimplePhone to use this device data, and tell SimplePhone to use the sound card.
* How the plug and play section works, with regards to matching specific devices, utilizing the right device data, bringing along with it the needed device data for the Configuration script.
* How to pass this to a Configuration script, so that additional functionality can be done when a device is added to the system, in this case, inserting device data into SimplePhone to explicitly set the sound card to the new Phoenix Solo mic that was just added.

This is intended to be an introduction into the Plug and Play section, and hopefully spur questions and give me direction as to what more videos to make.

Hopefully this is educational, until next time.

Hello guys,

I am between contracts, and looking for little things that might be very useful to the LinuxMCE community to do, to make sure I can take care of the recent hospital bill.

I have mapped out what needs to happen to add AFP support to LinuxMCE's file server detection and file share adding code, so that shared folders on the mac can be seen by LinuxMCE and subsequently scanned by media, coupled with the recently added AirPlay support, this helps close the integration loop significantly for Apple Macintosh households.

The following needs to happen:

* Add Package definition for afpfs_ng, and add afpfs_ng to pluto storage devices dependencies, (1 hour)
* Add Device Template for AFP share, (1 hour)
* Add support for mounting afp shares to auto.plutoStorageDevices using mount_afp provided by afpfs_ng (2 hours)
* Create Avahi PnP plugin for detecting mDNS-SD devices (such as AFP file servers) (8 hours)

Total time, 12 hours worth of work to produce a working implementation of AFP shares under LinuxMCE for 1204.

I'm asking to possibly raise $500 to get this feature done.

If so, cool, if not, that's okay too.


Users / TSCHAK has a TSCHAKlet now.
« on: June 19, 2013, 11:46:48 pm »
Hi guys,

Just writing to tell you, that as of Tuesday, June 18th, 1:37pm, my family now has a new addition, my first child, Nina Sofia Cherryhomes, at 8 pounds 2 ounces (3.7 kilograms).

Can't talk much now, so busy,

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,

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