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.

Messages - phenigma

Pages: 1 ... 61 62 [63] 64 65 ... 87
Marketplace / Re: WebDT 366s - Brand new still in the box. ** $75.00**
« on: October 22, 2010, 10:41:24 pm »
I ran the bad unit through a bunch of tests and it ended up failing a MemTest86+.  It has been put in the mail to be returned and he says he'll ship me a new one.  I will admit that he hasn't been the most prompt of individuals to respond but he has been dealing with me and my problem.

I'm incredibly happy with these LX units vs my old GX.  They are MUCH faster.  With the increased processing capability and the 802.11g they easily run Orbiter and stream from .flac or .mp3 files to squeezeslave wonderfully.

It was not a simple 'plug n play' to get this up and running with the padorbiter distro.  The drive size was the biggest issue to overcome.  I tried resizing the image multiple times and never got the partition defined quite right.  Had to do a fresh debian install to get a proper partition defined and imaged.  Then the video was a bit of a pain as the vesa framebuffer causes white pulsing on the LX's screen.  The framebuffer driver has to be set at boot and it works great in the console.  Once booted the LX framebuffer doesn't wake-up from suspend properly under X, not sure why but it's not pretty, so I switched to the geode driver in X and it resumes just fine.  The IPW2200 firmware had to be copied onto the webdt before the wireless would operate.  The wireless card doesn't seem to wake up as quickly as the cisco card in the GX (at least that's the best I've come up with) and consequently Orbiter takes a bit before timing out and restarting.  As a simple solution I kill Orbiter on resume, which restarts Orbiter in a couple seconds rather than 10 or 15.  USB2.0 on the LX vs USB1.1 on the GX makes installing an image 5x faster.  Took me a little over a week to figure out what to do and learn what I needed to do to make it happen.

If there is enough interest I will post an image of what I have, but that should be reserved for another thread.


Users / Re: Problems with Denon 2310 - Video source drops
« on: October 22, 2010, 09:53:09 pm »
phenigma,  thanks for the reply.... I am using a zotac ion n330 board.

Welcome to the Forum and thanks back.

@phenigma My core uses the AN-M2HD with optical out (for surround sound) to the Denon and HDMI out to the TV. Don't think HDMI sound supports surround sound. I have also used the Acer Revo with the same setup (optical plus hdmi).

HDMI does support surround sound, it's part of the appeal of HDMI, only 1 cable is required for all video and audio.  The newer HDMI standard (1.4 if I remember correctly) actually incorporates a tcp/ip communication mechanism so that each device can share a network connection as well.  I have yet to acquire an HDMI receiver to confirm that LMCE supports surround sound over HDMI... but I would assume that it would.  Thanks for the info on the motherboard.


Users / Re: Screen blanking during playback
« on: October 22, 2010, 09:43:11 pm »
Your welcome. :)


Which installation media did you use?  The Beta2 DVD is quite old and you should use a recent snapshot from or do a net install following as a guide.


Users / Re: Problems with Denon 2310 - Video source drops
« on: October 17, 2010, 10:12:49 am »
What MB/video card are you guys using?  I was looking at a denon 3311 but I may reconsider.


Marketplace / Re: WebDT 366s - Brand new still in the box. ** $75.00**
« on: October 17, 2010, 09:46:33 am »
A couple of notes to anyone looking at these right now:

The WebDT 366DT LX systems have a smaller internal drive than the WebDT 366GX (the device the current padorbiter installs onto).  This means that padorbiter will not install onto these units.  

I purchased 4 of these units and after a couple of weeks they arrived.  3 of the 4 units are working perfectly and I have shoe-horned padorbiter onto them with the wireless firmware and squeezeslaves on them as well.  My squeezeslaves address themselves with leading zeros followed by the 2nd half of the webpads mac address to allow me to easily configure them on the core.  There is decent battery life in the 3 working units.  I can confirm the intel wireless g ipw2200 card is present.  I have not tested wpa yet.  They come with european 240v plugs on the cords, the power supplies are universal though so it's trivial to cut the ends and replace them.

Unfortunately one of my units arrived defective.  My attempts have been completely unsuccessful installing any operating systems on this one unit.  The install attempts have all failed part way through (they are successful on each of the other 3 webdts).  I have sent an e-mail to tbowland and I am waiting to hear if he will replace this defective unit.

I'll post the resolution when I receive a response from tbowland.


Users / Re: Altering volume increase/decrease increment - App_Server.cpp
« on: October 17, 2010, 09:18:02 am »
This would be great functionality!  All current a/v dSomeone who knows more specifics could comment though.evices rely on a device template to assign the number of 'repeats' for volume commands.  It seems to me that the app_server must (or should) have a device template (it must have somewhere) and that it should follow the same rules as any other device that has volume commands and respond to the configured repeat amount set in the template.

I'm not certain the exact method to implement this but there should be a setting in the template, or it must be added, and then the app_server would have to honour those volume repeat numbers, in a loop.  My understanding is the app_server only handles volume commands when no other device is available (ie no receiver or tv which handles volume setup in the connection manager) so any changes to app_server should only affect systems without another device handling volume control. 

Can someone confirm or correct my assumption of how this should be implemented?


Which install method did you use?  (beta2 dvd, snapshot dvd, net install)

Current snapshot DVDs from or the internet install detailed at: are the recommended install methods currently.


Users / Re: Screen blanking during playback
« on: October 17, 2010, 08:44:42 am » is executed every time you select Start KDE from the onscreen orbiter.  

Is this your core/hybrid or an MD?  The screensaver fix for the core is reported and a fix provided in  This defect patch has not yet been applied to the current builds.


A little un-related but did you know that Thom's Padorbiter for webdt's implements the Start KDE button and you can use it to invoke all kinds of things on a webdt, then use a messagesend to bring orbiter focus back.


I'm glad it was successful for you!  My intent was to enhance the ability for testing device templates from install to install without having yet submitted them to sqlcvs.  I'd love to know what the devices were that you exported and what your experiences were using the script, it's not the easiest to use. 

Did you have any problems?
Did you have to alter anything in the script?
Were the devices IR or GSD? or neither?
Did all the IR/GSD code transfer properly? 

I hope to clean it up a bunch and create a better interface some day.  I had used the script as an exercise to learn a some php and sql so my additions to the original code were not the prettiest in implementation.  I learned a whole lot about the pluto_main database structure in relation to device templates.  Somewhere I have additions that add the ability to backup shell scripts (setup & pnp detect scripts, etc.) associated with the device template, and all child entries, and code that does device template association by psc_id in-case someone updates their sqlcvs after backing up but before restoring (I experienced a problem with this once and wanted to account for it).  I don't remember how much of that is in the one I posted.  At some point I'll look at what's here and the changes I'd made since then and merge them.

Again, glad it worked for you!  Tell me how it went!


Developers / Re: TouchOrbiter - Auto-configuring new orbiter
« on: October 17, 2010, 07:59:16 am »
Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...
Just to pick up on this point - had done exactly this previously for the n900 and it works and creates an orbiter that can be just run on the n900, no pre-config needed. I got stuck creating a viable .deb for it and haven't been back to it since :( but will try and get it installable, once I figure out the packaging stuff.


Coley are your code changes available anywhere?  No one seems to be maintaining the maemo builds right now, I've never set up a maemo build env but I would take a crack at figuring it out and packaging it. 

Unrelated: There is also currently a bug installing the existing orbiter on the lastest PR1.2 because of the '.install' file for n900 pointed to in the wiki.  I know what needs to be done to fix it but niteman hasn't responded to me e-mails so I'm not sure if he's around to fix the file.


Developers / Re: TouchOrbiter - Auto-configuring new orbiter
« on: October 17, 2010, 07:53:24 am »
First and foremost, thank you all for speaking your minds.  Ongoing intelligent discussion must continue to occur on this project.

Why don't you actually try to look at and understand what we have, before spouting off?

I really am Thom, I really am.  It's not easy when this system is so large.  I understand everything very well in my head; it's the implementation that is lacking right now.

Shake your head? Do you understand what Orbiter actually does?

I don't think you do.

I do understand what it does (mostly).  I don't understand all of the intricacies of the C++ language but I can read it and tell what it is doing.  I have spent hundreds of hours reading the code in svn.  I've been following svn changes daily for about two years and I'm investigating many aspects of the system and improving my knowledge every day.

and circumventing the PPL? That's funny. You still have to run Proxy Orbiter on the core.. Guess what? That's a subclass of Orbiter. PPL code.

Okay, circumventing was a bad choice of words.  My understanding of the licences that commercial installers have undertaken (and yes this may vary) is that they pay a fee when the sell a device that is 'intended to run orbiter', so if they sell a hybrid that runs orbiter they will pay a licencing fee for that device, but not a fee for each instance of orbiter the hybrid runs.  Then they can supply as many additional devices that run a 'touch orbiter' or 'web orbiter' without having to pay any additional licencing fees for those devices.  Example: If I am a re-seller and sell a device with 'Orbiter' installed or intended to run 'Orbiter' then I must pay a fee to pluto when I sell this device.  But... if I sell a device installed or intended to run 'Touch Orbiter' then I will not have to pay the fee when I sell this device, no PPL code or applications.  This is my understanding.

Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...

I don't believe I've tried the options together I will, thank you.  I tried -DPADORBITER but without any the other options.

And yes, Orbiter will be rewritten at some point. This does bring up my other point. I'd like people to make UI toys in Clutter, so we can have something to mash between our fingers, something we can use and interact with to define the features we need in a new orbiter..But I've already gone over this repeatedly, with just about everybody missing the point...

I have been looking at clutter and I am amazed at how abstracted it is and seemingly easy to use, at least the basic stuff.

The Touch Orbiter is at best an interim solution for the problem of moving orbiter to other systems where the C++ DCE library isn't available.

I agree with you.  But until Orbiter is re-written without PPL constraints it is a solution that will be persued by many.  But I also see that the touch orbiter interface looks like it could be extensible to permit a wide range of data transfer capabilities and provide orbiter like functionality rather that simple image display and x,y return.  dce through http?  or could hari's rpc code essentially enable that type of functionality?  never mind, this is another topic and more code for me to read.

I mean it fellas, am I the only one smart enough to actually work on the Pluto bits of the code? Are you all totally chicken shit? It certainly seems that way. No. Let's not actually understand what we have, let's just put our fingers in our ears LA LA LA LA LA and work around it! Stop it. Roll up your sleeves, grow a sack, and actually dig in and understand what we have..Then, and only then, can we move forward.


Thom you are not the only one smart enough.  But this brings me to my previous post.  While I dream nightly about dce messages firing between devices and envision more devices interfacing with greater ease...  We are not all as experienced as you are with development or with the many facets of this system.  I have a lot of respect for you and your understanding of this system, and your commitment to the project, but you are aggressive, appear arrogant, act dictatorial, and belittle people too often for me to really want to commit to doing anything you ask or demand.  I want you to be a leader not an bully.  Just because I don't understand Orbiter as well as you do does not make me less worthy of an intelligent response.  Thom I don't agree with what you do here all the time and you don't have to agree with what I do either but I'm trying to help make this system better.  I put more time into learning this system then I really should and I didn't think constructive help and a push in the right direction was too much to ask towards helping to make auto-configuring more of a reality.

What I want most is for people to stop adding 'features'.  Maybe an RC; maybe a release would be conceivable.  There is a 'Do as I say and not as I do!' attitude from the core team and that's really unfortunate and counter-productive.  Challenges for adding new features have been posted regularly since Beta was announced.  Beta is about a year old and new features are still be added, an RC doesn't appear on the horizon.  If the core devs won't abide by the declarations then open the damn thing up so others can put their features in too!@

My rant ends now.  I will continue to do what I am able when I am able to.

With respect,


Developers / Re: TouchOrbiter - Auto-configuring new orbiter
« on: October 12, 2010, 10:41:09 pm »
I do understand this is a learning experience, but...

I think making touch orbiters for native clients is a waste of time. Actually spend some time with Orbiter, and figure it out... Otherwise, all of you making touch orbiters are going to run the risk of reinventing what we already have. I'm growing very irritated by the whole thing.


There seems to be a divergence between how you 'want' things done and how everyone else is moving and implementing things. 

Do you have a native linux orbiter that works standalone of an MD or other MID device that you would like to share?  I think that would be nice with Orbiter but some work needs to be done to enable it to easily run standalone of an MD on linux (I did try) but I certainly didn't have the knowledge before this past weekend.  I've looked at the Orbiter code and I shake my head... why should I touch it when you are continually saying it's being re-written from scratch?  Orbiter is bloated and consumes a lot of resources.  Native orbiters for each and every possible device do not make sense to me, it's a nightmare of maintenance of multiple devices that all do the same thing.  And there are a dozen new devices to support every month. 

It also seems to me that touch orbiter circumvents having to pay a licence fee (PPL) to sell a device with orbiter (no I am not a dealer and I do not intend to sell anything) and so a licencing fee is not required for those that resell, probably one reason why CHT is going this route.

The existing linux/mini2440 touch_orbiter in svn has not recieved any love since inception and it has a memory leak making it unusable after a brief time and uses almost as much cpu as the native orbiter (this I can resolve now that I've been through the process and have figured out why/where).  I'd like to create a single device to support multiple linux distributions and windows/mac that can easily configure itself. 

The touch orbiter allows me to use my webdt's with squeezeslaves installed - audio zones everywhere I have a webdt!  Padorbiter uses too many resources for this to be possible.  I can even do *other* things, like browse the web, with my webdt & touch_orbiter running, not possible with Padorbiter.  You have said yourself that you can't 'shoehorn' it all in.

And to top it off this was even something you had suggested implementing.  My feeling pretty much mimics this:

Thom, I'm quite in a mood of slashing my wrists right now, for no good reason, and I get this mood each time I want to do something for this system, not sure why. I did this Touch Orbiter thing on a whim, for quick and dirty way of getting more devices with Orbiters on them in a snap, and get other people to write similar code for other platforms, for an instant explosion of supported devices.

Your response was this:
Dude, I wasn't trying to make you depressed, or anyone else for that matter.

I am trying to get people to try and make the process of using these proxy orbiters plug and play process.

we have:
is entirely text
* the ability to detect screen resolution
* the ability to select a skin
* the ability to select users to use this orbiter
* the ability to detect whether PNG or JPEG is supported

This can be funneled into a New Orbiter DCE command to the Orbiter PlugIn, which, when coupled with two new device templates:

* Proxy Orbiter - PNG Images
* Proxy Orbiter - JPEG Images

with the ImageQuality device data set appropriately,

This can all be made plug and play.


A recent conversation in irc with los93sol and you were praising him for trying to do just this.  So, I did this to find and fix a memory leak that was preventing touch_orbiter from being a viable option and to learn more so I may be able to contribute more in the future. 

I started this thread so that I wouldn't be re-inventing what has already been done, as you say.  I wanted to find others who are building touch orbiters for devices so that a common solution could be found for automagically configuring all these devices, not just mine.  I suppose I'll not bother, leave it alone, and continue to manually configure my system and not try to make things plug and play.  Thanks for the support!


Users / Re: What devices are you running Web orbiter 2.0 on?
« on: October 12, 2010, 10:00:34 pm »
You have edited the template for your amp to achieve this right? How do I go about changing this for the web orbiter itself, so that it works for all MDs (I don't have any amps)? Am I supposed to be looking in /var/www/LinuxMCE-admin/weborbiter?

This can only be changed in DeviceTemplates for individual AV devices.  There is no possible change to weborbiter to implement this.  Once implemented in the DeviceTemplate it does not matter what orbiter you use they will all function the same... for that device.  I don't know if there is a way to implement this functionality if you are not using an external AV device (like an amp), but orbiter would still not be the correct location to do it.


I'm trying to export two templates i've created, but no luck.
The export shows errors and i cant find any file. shows it.
Question: how to export the templates and where are they stored, so i can backup them and submit to svn?

The script in the lmce distro does not function properly.  You may have better luck with one I posted earlier in this thread but I do not recall the state I left it in at this exact moment.  I will look at it again but don't have the time right this instant.


Pages: 1 ... 61 62 [63] 64 65 ... 87