Author Topic: Observations and Reasons Why Not  (Read 1653 times)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Observations and Reasons Why Not
« on: December 29, 2005, 05:29:37 pm »
Let me first say, I'm thoroughly impressed with the initiative shown in the simple fact that this project exists.  Your work is appreciated.

I'm not the brightest bulb in the box when it comes to difficult and/or complex linux applications; but I'm no dummy either, and this application is not billed as difficult or overly complex - in fact, it installs itself, right?

That said, here are a few reasons why, after a week of consistent attempts to build a lab system to evaluate this application, I have come to the conclusion that the challenges without apparent solutions outweigh my motivation to make this system work:

1. Hardware configuration and support:
 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.
 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.
 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.

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.

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.

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?

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.

So that was quite the ramble.  I could continue listing things, but I'm sure that my feeling has been expressed appropriately.  These problems aren't small, and likely don't even need to be pointed out for you to be aware of them.  I understand your team is busy, and you just lost your Mythtv guy, and CES is coming up, and etc. etc.  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.

Thanks!

Robert

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Observations and Reasons Why Not
« Reply #1 on: January 06, 2006, 07:18:58 pm »
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.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Observations and Reasons Why Not
« Reply #2 on: January 06, 2006, 09:12:12 pm »
Quote

>> 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.

More on this here: newbielink:http://plutohome.com/support/phpbb2/viewtopic.php?t=540 [nonactive]
Quote

>> 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?

Separate the types of templates better, and along with the configuration page for each, provide easy access to the bare configuration entry so that changes may be made at a low level, or duplicated/backed up more easily.  There are many other ways as well, but difficult to explain.  AMP in asterisk does it a little with it's config files.
Quote

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.

Wewt!
Quote

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

It may be good here to layout a "do not change this or it will break" kind of guideline for the changes to asterisk.
Quote

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?
Quote

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?

Consolidation, my friend.  Wiki may not be the best route in this case, as information is too spread out.  Get rid of the "what can I do with pluto" part and put all of that good information into the install guide, along with any other information that's scattered into other areas of the wiki.  All areas of the Wiki *look* the same, so it's difficult even to remember where you were when you saw the thing you saw that fixed the whosiwhatsit.  Don't let users write documentation for this system without moderation and approval.  It's too complicated, and you have many paid experts that can do it much much better.  Also add clear revision dates to each page, so that upon new releases or other changes, users can tell what's been updated.

Once you have clear, concise documentation and your ideas begin to be implemented more effectively in the product, I think there will be more effort from the community to improve it.  In my experience, the community is much more apt to modify, improve and port - not so much to fix.  There's also not much clear communication about what is being worked on specifically.  A lot of problems are laid out, but nobody knows what needs fixing or what's being fixed.
Quote

>> 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.

Good to hear, and I'll stick around with my finger on the download button.  Any timeline on the new release?

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Observations and Reasons Why Not
« Reply #3 on: January 09, 2006, 08:58:32 am »
hopefully tomorrow we'll have a release build available

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Observations and Reasons Why Not
« Reply #4 on: January 26, 2006, 11:49:41 am »
Quote from: "aaron.b"
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.


We have been around this issue several times now and I can't see that this will ever go away completely. The pace of hardware development is not going to slow up. So the solution as Aaron says is to settle on some known configs and target those.

Quote from: "aaron.b"
Regarding your issues:

>> 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.


We are using the Windows XP MC Remote with the Microsoft IR transceiver very successfully now that mce_usb is working. This combo supports most if not all the remote buttons and works very well.

Andrew