Regarding your issues:
>> 1. Hardware configuration and support:
This is our biggest challenge. If you have a set of hardware that we have tested and added support for it does work out of the box. However, we can only test .001% of the hardware combinations possible. On most motherboards the Debian Kickstart CD/Linux Kernel fail to recognize SATA drives and it can take days of tweaking BIOS settings to get it to work. Also, with each sound card it can take a lot of experimenting in alsa to get both ac3 and pcm to work, and to get spdif+toslink on. Since Pluto's eventual target audience is non-techies and it has to work out of the box, we made an architecture where the user assigns within Pluto's framework what hardware he has, and we then have scripts that knows how to do all the particulars for that hardware. We then want to release 'reference platforms' that are fully supported and tested. This still won't be 100% perfect. For example, we wrote scripts for the Sound Blaster Audigy 2 that knew how to do all the settings to get ac3/pcm to work. But they just recently changed the chip and now the script doesn't work anymore, and we've had 2 Linux guys fighting for days to find all the patches and tweaks needed to get alsa to work with the new chipset. We have contacted some system integrators who have agreed to build pre-configured boxes so a user can get a system that he knows is 100% compatible. But that's not in place yet.
>> a. A thing as simple as a remote control should be easy to install, but of the two relatively common remote controls that I have on hand, I can get a total of 0 to be implemented correctly.
This is the same issue. We found so many problems getting LIRC to work, so we wrote our own drivers for 2 popular i/r transmit/receivers: IRTrans and Tira. And wrote our own remote definition for 2 remote control templates: Windows XP MC and B&O. If you have either of those, it works 100% of the time out of the box and every button on the remote does exactly what it should based on the current context, for example the B&O remote's up/down/left/right navigates chapters while media is playing, and switches to navigating the on-screen menu while the Orbiter. The problem is only a small portion of users will happen to use those combinations. The hope is that as an open source project, other users will add support for other remotes. But that hasn't happened yet, so for now you need either IRTrans or Tira, and either a Windows XP MC or B&O to have an i/r remote that works without issue.
>> b. Display drivers and configuration do not seem to be cooperating. At times, it seems editing the configuration in the MD screen doesn't apply correctly to the XF86Config-4 file, and vice-versa. I've had MD's apparently replace the hybrid's driver with another in it's XF86Config-4 file, and the MD config page didn't reflect this, nor did it affect it when attempts were made to do so. In this case, only reverting the XF86Config-4 file back to an old version righted the situation.
I've never heard of that issue, we'd need to inspect it to see what's happening. Again, there's the same hardware issue: we only have built-in support for ATI & NVidia, but if you have those 2 it should work. The only problems we're aware of are: 1) nVidia's drivers don't support xvmc on any of their newer cards; only on the really old agp cards. 2) ATI & nVidia's drivers both have lots of bugs in the negotiation of resolutions and even when we tell the card to ignore the resolutions the monitor can handle and output the one we tell them to use, the drivers still get messed up sometimes and refuse to output the right resolution. Those 2 are the only issues we know of.
>> c. Device & Template configuration is archaic. I know it's supposed to be easy and intuitive, but it's not. The fact that it's not easy is worsened by the unavailability of an obvious mechanism to implement device configuration files manually.
Do you have suggestions for how to make it more intuitive?
2. Integration and Useability
>> a. There's a typo in the Mythtv frontend that reverts itself upon MD restart, on EVERY MD. To me this means that it's a broken application.
>> b. Speaking of Mythtv, it doesn't seem very integrated at all. When you hit the tv button from the main pluto screen, you get the main menu for Mythtv. Navigating that menu from an orbiter is just silly, if not impossible. It doesn't even seem to be implemented in such a way to be used by an orbiter. Additonally, every time ot enter live tv, the MD's volume (not mythtv's) is reverted to a very low setting, and thereby has to be adjusted every single time. Where's the default setting, or at least a memory implementation?
>>c. Out of the box, without modification to encoding/decoding settings, Mythtv is problematic on a hybrid box. The hybrid box I'm testing should be more than capable, with a high-end athlon, a gig of ram, and a hardware encoder (pvr250). Instead of a plug-and-play solution, I have to fight and jump through hoops just to get the pvr card recognized, only to have the tv display consistently skipping and jerking. Note that it doesn't jerk when displayed on other MD's.
>>d. Who designed the orbiter interface and context-sensitive controls? Half of the buttons in the orbiter interface just don't work, and it makes things extremely confusing.
We neglected Myth for a long time because Myth had no mechanism of being controlled by an external app, except by simulating keystrokes like LIRC did which wasn't reliable. So last month we posted a $1,000 offer to the Myth developers to add such a mechanism. Chris, a core Myth developer, took us up on the offer, and in the .35 release Pluto will include a seamlessly integrated Myth that solves all those issues and all Orbiter functions work with Myth.
3. Asterisk Integration and Interoperability
>>a. Does documentation exist that describes how asterisk has been configured/modified to work with pluto? For some of us that have had Asterisk labs, implenting our regular asterisk settings alongside the mass of modifications is risky. The version used in pluto isn't the latest version, and there doesn't seem to be any default ivr system configured. I can't entrust my phone system to this box, and I hesitate to try if problems cause me to start over every few days to refine the approach. Pluto's interaction with Asterisk should be documented, and the option to have Asterisk on an external device should be available and easy to implement.
We have worked on this a lot lately and will continue to work with Asterisk closely. In fact we even contracted a while ago with Digium to get Mark Spencer to work with us in our office in Florida. The .35 release includes a much improved asterisk integration. We didn't change Asterisk, though. All our stuff does is feed the configuration to AMP. So if you know Asterisk/AMP it should work just like a vanilla Asterisk app. However since our goal is to make it easy for end users, we have in the .36 release a video wizard where during setup
4. The Pretty Website That I Can't Find Anything In
>> a. Seriously guys, this website is difficult to navigate, and many things are not placed in an intuitive manner.
>> b. There are a rather lot of things missing/not implemented/broken. Where's the PlutoVIP site?
Agreed. We've received lots of complaints about this, but no suggestions for how to make it better. Since there are so many functions, it is quite difficult to organize it all intuitively. Do you have any ideas or recommendations here?
5. Documentation!
>>a. This melds with #4 up there a bit. There is far too little clear configuration documentation, and the documentation that does exist is not thorough and too detailed at the same time. There's too many dead links in the documentation as well, and not pointing to trivial resources.
Agreed. It is wiki-style in that users can add to it and improve upon it. That hasn't happened yet. We have about 1,000 pags of documentation, but we wrote it all. Do you have any recommendations for getting this to work better?
>> I only hope that this project will move from an experiment in linux media application integration to a fully documented and supported application that will make the expensive home automation providers cry in their tea after they pee themselves. I was awe-struck upon discovery of this product, and I'll be keeping an eye on it to see if it can fulfill it's potential. For now though, I can't continue torturing myself with attempts to make it work correctly.
We've got almost 30 guys paid staff working on this full-time, so we are progressing rapidly. I think if you check back in 2 months you'll see a lot of these issues are being addressed right now. And when we get system integrators to offer systems with the software pre-installed and bundled with all certified-compatible accessories, I think your experience will be quite different.
