You should look at the Yamaha RX-Vx00 (RS232) template. It has a set of Zones implemented as child devices, and the GSD code looks at these, and alters the commands sent out, depending on where the AV messages are coming from.

-Thom

Read Developing a DCE Device, in the wiki.

-Thom

if we can avoid having to keep mac address ranges, that would be great. The thought has crossed my mind to scan for Bonjour (Zeroconf) services, but I am having difficulty finding a consistent service I can BROWSE for, to find a mac.

-Thom

You lazy bastard, IN MY DAY, WE HAD TO ILLUMINATE OUR SHELL SCRIPT MANUSCRIPTS! ONE STROKE AT A TIME! ON HAND MADE PAPER!!!

-Thom

hmm.

*thwap-you-really-hard*

Don't mess with the basic filesystems, you will break the storage layer epically. (Why is it that power Linux users have the hardest time with this system? you guys just want to break things because you assume how things work without actually studying how they work!)

Keep /home on the boot system, and simply let the system detect the RAID 5 disk, and tell it to use the disk with LMCE file structure. You'll need to move /home off of that disk, and then let the storage layer correct itself. This should also show you NOT to fuck with fstab.

-Thom

I am replying, after a few days of mulling over an appropriate response.

Those of you who have been a part of this community, since the beginning, remember all the discussions that have been had, over and over again, over a next generation user interface, to replace Orbiter. We spent from 2007, until 2011, just _TALKING_ about it.

and _everybody_ had an opinion.

Lots of people just talked about it...over and over, with nothing getting done...

until...

golgoj4 finally sat down and _DID_ something. He has thus far built a functional orbiter engine, but it needs qml.

Yes, I understand what and why you guys are doing this, but by doing this, you're fragmenting developer resources even more than what we already have!

So basically, you're keeping this under wraps, until you're "ready" to show it off. Throwing it over the wall.

This didn't happen with qOrbiter. Langston put qOrbiter in the source repository from day one, and those of us who could, checked it out, built it, and tried to build things with it, and we did this from day one. golgoj4 built his basic skin, and I was building my skins for Harmattan, and more recently, for Android. And boy, did we discover all these little bugs, and things that needed to be refined. But only because the whole development process was open from the beginning.

So, fine. If you want to fragment developer resources, that's your perogative. But, trying to keep all this behind the wall, without any contribution from anyone else, is setting yourselves up for some nasty surprises when people start trying to build stuff with it.

-Thom

*nod* It's an odd spot to be in, it's either:

(1) run on the media directors, and follow the usual flow of device detection, or
(2) have the core do all the mdns device handling itself, and write logic specific for it.

-Thom

There is already infrastructure to detect devices on each computer. I am leveraging that.

It would be this:

1. mdns device loads.
2. mdns device scans, finds an apple via mdns...
3. mdns device sends a device detected on this computer of say, CAT:zeroconf_apple_device
4. plug and play plugin catches, matches to Airplay player template.
5. Airplay player installs. since there is a sister router plugin device in the related plugin section, the plugin is installed if needed.

This would take care of devices as media directors are installed, and would not need to have logic to crawl the database looking for new media directors, and keeping track of which ones have been installed, which ones haven't.

-Thom

Because the player is on each MD.

-Thom

In the end, it does not matter, so long as it works most of the time. The plan here is to have the radars running on the md's, and if they detect anything, apple like, to fire a Device Detected event, which will cause the AirPlay Streamer to be installed on the target MD.

-Thom

Pluto had packaged a copy of SCCP 7.0.3 with LinuxMCE until 7.10. We no longer have these firmware ZIPs.

-Thom

mine however, do not show that.

-Thom

You can stop by the channel using one of a few methods:

* Windows: mIRC http://www.mirc.com/
* Mac: Colloquy http://www.colloquy.info/
* Linux: install x-chat using your favorite distro method.

set the network to FreeNode, and once connected, connect to #linuxmce-devel

or use the web interface @ http://webirc.freenode.net/

again, you can go to the #linuxmce-devel and meet us there.

-Thom

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: http://standards.ieee.org/develop/regauth/oui/oui.txt

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.

-Thom

Why don't you stop by the IRC channel (#linuxmce-devel, on irc.freenode.net), we can help you there.

-Thom