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 ... 57 58 [59] 60 61 ... 82
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.


Developers / TouchOrbiter - Auto-configuring new orbiter
« on: October 12, 2010, 03:14:59 pm »
I've been learning some c++ and I've spent the weekend hacking away playing with online sdl tutorials and the touch_orbiter_1.0 in svn and I have managed to create a linux touch orbiter that is working well for me using sdl.  Great learning experience.

What I would like to do now is add configuration setup like the padorbiter has.  From the I've tracked down it looks like there is a 'createorbiter' DCE command that padorbiter uses to create a new orbiter device on the core.

1) I'm assuming a new DCE command will be necessary to create the proxy_orbiter (and associated orbiter). 
2) It seems to me that if a new DCE command is required to create the proxy_orbiter then any device using touch_orbiter could utilize the same command for the proxy_orbiter creation and setup.  Anyone care to comment on whether I am right or wrong here?

Has anyone looked at this yet or begun any work towards this in any of the touch orbiter platforms?


Developers / Re: Linux TouchOrbiter
« on: October 12, 2010, 03:11:35 pm »
Hmm, ooops.  Little tired when I posted that.  I'll repost unless there's a way to move it.  Thanks Hari.


Developers / Linux TouchOrbiter
« on: October 12, 2010, 06:46:08 am »
I've been learning some c++ and I've spent the weekend hacking away playing with online sdl tutorials and the touch_orbiter_1.0 in svn and I have managed to create a touch orbiter that is working well for me using sdl.

What I would like to do now is add configuration setup like the padorbiter has.  Based on what I've tracked down it looks like there is a 'createorbiter' DCE command that padorbiter uses to create the device on the core.

1) I'm assuming a new DCE command is necessary to create the proxy_orbiter (and associated orbiter) instead...  at least that's what I think from what I see.  
2) It seems to me that if a new DCE command is required to create the proxy_orbiter then any device using touch_orbiter could utilize the same command for the proxy_orbiter creation and setup.  Anyone care to comment on whether I am right or wrong here?

Has anyone looked at this yet or begun any work towards this in any of the touch orbiter platforms?


That's likely the most recent I have.  I had done more work and fixed a few more things and cleaned up the code a bunch as I learned more but I havn't had a chance to see if I've got anything newer backed up anywhere.  I'll have to look.

The actual 'insert' code may be commented out in the posted version of the script to avoid accidentally screwing up a database, you may have to uncomment it at the end of the .php file to get it to actually insert records into your database.  When you are viewing the insert statements it will show negative numbers as place holders for new Primary Key IDs that will be created when the actual insert statements are run.


Pages: 1 ... 57 58 [59] 60 61 ... 82