Messages

If you only have one md device it will be "/dev/md0", not "/dev/md1", by the way.  Look at the output from "mdadm --detail" - read the mdadm man page to figure out how to get additional information about the state of the array.

Getting skype audio integration into Asterisk doesn't seem to be a problem and probably worth the cost of the commercial solution if that's all you want.  In my case, I want video-enabled skype-to-skype calling from a media center.  Looking at the skype API for linux, it still seems that GET / SET VIDEO_IN interface is still missing.  Looks like this needs to wait until the API is more complete which is inevitable when the open-source the client.

In the time spent waiting for the video interface, you could get the audio and contacts interfaces working for you...  I'm guessing there is probably quite a bit of work in those areas to begin with...

I have a programming task for you guys,

Somebody add some events for alarms in the database, and create some DCE devices to query the lm sensors, and emit events, so that we can respond to them.

-Thom

This would be a great project.  Might attract more attention as a programming task on the developer board.

...because no one has written that feature into the code...

That doesn't work because the Player device wasn't turned off.  It's still there waiting for something to do.  The player device is not the same thing as mythtv's front end - it's a LinuxMCE device that runs all the time, waiting for you to call on it.  Then it activates mythtv as needed and sends the proper mythtv commands.

Have you looked at the graphics configuration options for the MD?  Go to web admin --> Wizard --> Devices --> Media Directors.  I believe these settings affect the MythTV configuration in 0710 - that is probably why you see the setting being changed automatically.  I think more MythTV configuration is happening automatically in 0810, by the way.

Whenever you see something changing automatically - you can be pretty sure that LinuxMCE is forcing some configuration on your behalf.  You should avoid scripting, and instead try to find the setting causing the behavior.  That way all the different components that use that setting will be properly configured for you.

I'm fine with that statement.  I think you will have more people interested in helping if you document your goals and your planned approach, as stated earlier.  Even if it's all "subject to change" - people need direction, and they need something to get excited about.

I'm talking about a level of flexibility that will have effects on how the system is designed as a whole.  The specific features are beyond what is going on here, yes.  Think of the specific features as examples or use cases for how these new "building blocks" would be used.  For instance, replacing a screen based on some settings or generating screens programatically - these are interior features that will expose themselves to UI designers, but the root of their implementation is under-the-hood stuff.

I think I may have focused on the design features more than the underlying support for them, which made my statements misleading and long-winded.

I thought the point of this thread was for clutter discussion specifically, not orbiter design discussion... but ok.

Thom, it might even be easier that way, since the "old Orbiter" could still exist as the "new Orbiter" is developed.  People could choose which to use - stability or new functionality - on a per-device basis if it were set up that way.

The key points I'm interested in (no design stuff in the database, re-design-ability without any code changes, and platform portability) have been addressed, and I'm very happy with that direction so far.

There are a few other items I'm interested in - the ability to create your own custom screen(s) on a per-installation or per-device basis, better media sorting, and user management.

For example - having the "climate" and "security" rows are useless to me.  I would rather make a screen with a clock, some media shortcuts, and controls to set lighting levels as the home screen.  The design I would want to do would be selecting what I want, and where to put it on the screen - the complex stuff like picking icons and colors should be handled by the orbiter.  This way if you change the "theme", or whatever you want to call it, my custom screen will still match everything else.  Maybe this complete customization is only available for 1 or 2 screens, where the rest are dictated by the design that is shared by all users.

For another example - say I have a device that doesn't quite fit the mold of any other - maybe it's a cable box that has arrows and select buttons and stuff, maybe it's a PS3 which has 51 (I think) buttons on the remote (many of which have nothing to do with media and will exist on no other device), or maybe it's some completely different device that has nothing to do with anything.  It would be great if part of the device template could describe what buttons should be on the remote and have the orbiter pull the proper things together automatically.  Think of a generic remote template - where buttons or groups of buttons appear, disappear, or reorganize themselves based on the device's capabilities.  Of course, part of the UI design will describe how to lay out the buttons and what icons to associate with them - the template only knows what buttons are important.  Maybe there is a priority scale for selecting which buttons to leave out if the screen is too small.

For media sorting, this should be completely customizable.  The user should be able to make up hierarchies - like Author, Album, Title or Title, Season, Episode - and attach those to buttons on the orbiter.  The same should be true of any sort of search - for instance "TV Shows", "Action Movies", "James Bond Movies", "TV Shows recorded in the last week", "Unwatched Videos", "Recently watched videos", "Videos partially watched", etc.  Maybe even shortcuts to specific playlists.  The user can select which ones are important or make up their own, and they appear on the orbiter.  I know exactly what I usually search for - there are only 3-4 searches that I do - so I should be able to make shortcuts to those searches so I don't have to wait for the datagrid, select the search buttons, run the search, browse through the results because the search is only close to what I wanted, and finally make a selection.

Media sorting should also be configurable for any search.  For instance, it's easier to look a James Bond movies by release date, videos should be sorted alphabetically (leaving out the "The", as I've stated before...), and recorded TV should be sorted newest-first with new episodes (this week's new stuff) highlighted.  These are my preferences - other people will want other sorting, I'm sure.

The thought behind these ideas is that no one likes the same things, and no one has the same technology implemented, so why should everyone use the same exact interface?  Slight customization in some key places can bring the UI to a whole new level very quickly.

I've also been wondering for a while if there is a better way to handle the current user of an orbiter in the case where no one is using it.  Currently, someone is always the user of an orbiter, but as new technology comes about where we can figure out who is in a room and react to it - that assumption stops making sense.  This brings up the case where no one is in a room, and the case where more than one person is in the room.  Orbiter can't handle either of those, currently.

These are probably much further down the road, but something to think about, if you haven't already.

Perhaps a separate "new orbiter design discussion" thread should be spun off so the work that has to happen to learn the UI library is not covered up with higher-level design talk.

It would be great if the people who have thought this through already could document their thoughts in a sort of "proposal" for the community to see.  Such a document would contain:
- a list of recognized problems with the current system that are being addressed with the new system
- broad goals for the new system
- a description of the scope of the work
- and any major design decisions made or yet-to-be-made.

The idea would be to:
- provide structure and concrete goals to the development timeline
- allow others insight into why things are being developed the way they are
- allow others to provide suggestions on alternate directions
- create interest in the orbiter redesign project to attract developers with the proper skill set
- and avoid wasting time re-explaining the design to each person who asks about it.

I'm fairly certain that you've thought of things that others have not, and I'm sure you have thought of things that you haven't mentioned in this thread or to anyone else.  It would be great to get some insight into where things are headed, and what sorts of people will be needed to help the effort.

http://forum.linuxmce.org/index.php?topic=9786.0

What is the end-goal of this setup?  What does the script do, and why do you need it?

There is no doubt that there is not an argument, and I know you've thought of all of this before, Thom.  The goal of my comment was to make these points clear to others who have maybe not thought it all the way through and perhaps gain some interest from others who could pitch in.

Your plan is sound, I look forward to the results.

http://wiki.linuxmce.org/index.php/FAQ

Look in the device tree.  You may have accidentally added an MD entry for that system which would cause it to wake up if the router is reloaded.  Why the router would reload overnight is a separate issue...

Assumptions are not the same as coupling.  I'm talking about decoupling your UI elements from your UI design/layout, and your UI design/layout from the underlying logic code.  We already know that DCE has taken care of a lot of the abstraction already - but I'm not talking about that layer; I'm talking about the actual program that is running on the devices - the one that talks to that DCE layer.  That code needs to be highly retargetable so it can run on all these cool new devices, as you know.

For instance - as you tinker, think of ways to make the results of the tinkering useful in other places immediately.  If you make a neat slider or button, take the extra 10% and make it reusable.  If you make a neat screen, take the extra 10% and make it flexible for other tasks.  As the design becomes more defined, think of ways to abstract it from the UI while still handling all the usual Orbiter logic.

I'm not saying that I think you have chosen any incorrect path, nor am I saying that you haven't thought of this on your own already - I think it's quite the opposite, actually.  But there are some key limitations that can be avoided by designing the application part of the Orbiter effectively, and everyone involved in the implementation should be aware of that so they can look out for issues on their own.