Recent Posts

Pages: 1 ... 3 4 [5] 6 7 ... 10
41
Users / Re: Need some dedicated testers.
« Last post by phenigma on January 21, 2015, 05:17:09 pm »
Brononius, what version of LinuxMCE are you running? qOrbiter is only available on 1204 and up.

J.
42
Users / Re: Need some dedicated testers.
« Last post by brononius on January 21, 2015, 03:50:25 pm »
damned, no luck... :$
I think it should be located under /usr/pluto/installers/. But at first sight, the file isn't on my server.

Code: [Select]
corius_1029915:/# locate .apk

corius_1029915:/# locate .msi
/usr/pluto/installers/OrbiterInstaller.msi
/usr/pluto/installers/PlutoBaSInstaller.msi
/usr/pluto/installers/PlutoRebootSetup.msi

corius_1029915:/# ll /usr/pluto/installers/
total 10620
drwxr-xr-x  2 root root    4096 2013-02-23 21:48 ./
drwxr-xr-x 18 root root    4096 2015-01-21 09:42 ../
-rw-r--r--  1 root root     401 2012-08-13 19:49 fremantle.install
-rw-r--r--  1 root root       0 2012-08-13 19:49 ImportContacts.zip
-rw-r--r--  1 root root  198764 2012-08-13 19:49 Orbiter.CAB
-rw-r--r--  1 root root 1663892 2012-08-13 19:49 Orbiter_CeNet4_x86.CAB
-rw-r--r--  1 root root 2002466 2012-08-13 19:49 Orbiter_CeNet4_XScale.CAB
-rw-r--r--  1 root root 3086699 2012-08-13 19:49 OrbiterCE_SDL.CAB
-rw-r--r--  1 root root 3427840 2012-08-13 19:49 OrbiterInstaller.msi
-rw-r--r--  1 root root  472064 2012-08-13 19:49 PlutoBaSInstaller.msi
-rw-r--r--  1 root root       0 2012-08-13 19:49 PlutoRebootSetup.msi
corius_1029915:/#
43
Users / Re: Need some dedicated testers.
« Last post by phenigma on January 21, 2015, 03:20:26 pm »
mhm.  That looks like the touch orbiter.  I've requested a new webadmin package which should have the links.  Until then you can find the file on your core, I'm not at my system atm and cannot remember the exact location off the top of my head.

You can use the console 'find' command to locate all files with an .apk extension to find the file, otherwise I can check when I get home much later today.

J.
44
Users / Re: Need some dedicated testers.
« Last post by brononius on January 21, 2015, 03:07:57 pm »

When I install it (forwards me to http://deb.linuxmce.org/LinuxMCE-Orbiter.apk), it looks very like the old one. :$
And on the server, a new 'Generic Proxy Orbiter' has been added.
45
Users / Re: Need some dedicated testers.
« Last post by phenigma on January 21, 2015, 02:23:29 pm »
hmm.  I probably changed its' name after removing the qt4 variant.  It should be the correct one.

J.
46
Users / Re: Need some dedicated testers.
« Last post by brononius on January 21, 2015, 10:56:47 am »
Then, from you android device, you can navigate to the webadmin page on the core.  At the webadmin login page there is a link to "Download Orbiter, Utilities and other software", click that and then you can download "Orbiter For Android Qt5". 

Just gave it a try, everything goes fine. Up to the point that i don't have an orbiter for QT in the list. Only an orbiter for Android.
I guess this isn't the same?
47
Installation issues / Re: No incoming phone calls?
« Last post by thor on January 21, 2015, 02:03:49 am »
One thing I've checked on my own system is whether the voicemail offered by my provider is enabled/disabled (I made that mistake once or twice).

In a terminal, after
Code: [Select]
sudo asterisk -rvvvvv, doing a 'sip show peers' or 'sip show registry'. All your phones should be registered. If not, track down why.

Not sure if you could do this since you reinstalled 1004, but compare 'dialplan show' of the old with the new. I've found asterisk to be a bear when tracking down errors.

Also, check the at home, or away status (go into lmce-admin website ->  Security -> Security status) and how it affects the way your telephones answer/ring (Telecom -> Call routing); on that same page, check: "# of seconds to ring before ivr (0=none)".
48
Like Crestron, new device drivers can be written in C++, (they can also be written in Ruby to be used by our Generic Serial Device, and in shell script to be parsed by our Whisperer).

The general process is this:

* Define a device template, which specifies the capabilities of the device (what commands it can accept, what events it can emit, how to find the device in a plug and play manner, any software that needs to be installed, etc, and any additional related devices that need to be a part of the installation in order for it to function)
* Use DCEGen to create a C++ project containing stubs, or use the built in Ruby Editor to fill in Ruby snippets (Ruby code also defines a few specific loops to handle device input, device initialization, and close, which would otherwise be explicitly defined in C++)
* Fill in the blanks, compile, add the device to your device tree... then test, fix, compile, repeat.

This is explained in detail on the wiki: http://wiki.linuxmce.org/index.php/Developing_a_DCE_Device

And in more detail on pages like:

http://wiki.linuxmce.org/index.php/Developers_Guide
http://wiki.linuxmce.org/index.php/Generic_Serial_Device

and others.

Once the device development has reached a point where things work well enough, you can work with us to push the driver into the source tree, and its relevant database information into the central sqlCVS database.

One important aspect to understand:

LinuxMCE is _not_ Crestron/AMX/etc. It was designed as the Anti-Crestron. That is, instead of explicitly defining from dirt every possible action, and debugging those actions, LinuxMCE provides an architecture of convention where the most common situations are greatly simplified (A/V hookup, for example, is no longer a matter of endless strings of macros, but we derive what needs to be done by a combination of knowing how to control each and every device, as well as the way they are connected in relation to other devices. The end result being that a user has to do much less work to get things working, usually adding devices creates scenarios automatically, with user scenarios added at their own convenience with wizards.)

We have a considerable amount of architecture. Over 4 million lines of C++ code, of our own, not counting the 12 or so projects that we appropriate from upstream. This takes time for any interested developer to understand, and my standard answer to this is, "take a year of your life, and learn this system."

The holes left in our architecture are a result of planned features that never quite left the database schema (such as multiple outputs in a matrix), and that we simply don't have the setup to be able to develop or test.

-Thom
49
Users / Re: cd-ripping
« Last post by phenigma on January 20, 2015, 06:47:56 pm »
Sounds like a bug to me as well.  Talk to posde on irc to get an svn account (if you don`t already have one) and put a ticket in if you can.

J.
50
Feature requests & roadmap / Re: control video source switchers??
« Last post by phenigma on January 20, 2015, 06:46:18 pm »
Input switching is easily accomplished and controllable through IR/serial/ethernet/CEC communications. 

Output switching is on the map but I don't think we have full ability to control matrix switches at the moment, there has been some experimentation and we have some ideas on where to go to make it work.  None of the devs have any of this hardware to test with though so it is not something we are working on at the moment.

J.
Pages: 1 ... 3 4 [5] 6 7 ... 10