31
Developers / Re: Developing a Weather Plugin, videos
« on: September 13, 2015, 05:16:56 pm »
I'll take a look, and make any needed changes to the plugin or the designer data. Keep trucking on. 
-Thom
-Thom
News:
Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com
LinuxMCE sponsor
open.home.automation
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.
32
Installation issues / Re: LMCE 1404 20150630062730843 Nvidia Install Reboot Loop
« on: August 26, 2015, 06:15:57 pm »
To explain a bit more about what phenigma is doing (phenigma, please correct me, as I will most likely be wrong on small details):
Our install process has been _very_ ad-hoc.
LinuxMCE depends on and utilizes many packages, many of them not only from our own repositories (for the DCE devices, the DCERouter, and the many scripts that frame them), but the many dependencies that each of these devices need in order to function.
Furthermore, many of these dependencies from the Ubuntu side are intended to be configurable, and can potentially be configured in ways that create unnecessary obstacles to LinuxMCE integration, so these things have needed to be pre-seeded in the past, and lots of little tweaks have been needed along the way.
Phenigma is doing some MUCH needed work, to clean this up. It's long, it's grimy, parts of it are freaky, and other parts will invariably cause hair loss, but what will come out of this is literally the ability to do:
etc..
and have LinuxMCE install itself and its needed dependencies to the point where the next boot then falls into the AV Wizard, and subsequently into a functional LinuxMCE system.
This leads into a refactoring of the whole start-up process, to use systemd. Whether you like it or not, systemd has become the accepted standard for the start-up of system and user services, and it is in our best interest to ensure that LinuxMCE starts and stops itself in a way that can cleanly be expressed in systemd.
As always, if anyone out there can help phenigma in his quest to vastly improve the plumbing of the system (which will ripple all the way up to the user experience), please contact him. This is important work.
-Thom
Our install process has been _very_ ad-hoc.
LinuxMCE depends on and utilizes many packages, many of them not only from our own repositories (for the DCE devices, the DCERouter, and the many scripts that frame them), but the many dependencies that each of these devices need in order to function.
Furthermore, many of these dependencies from the Ubuntu side are intended to be configurable, and can potentially be configured in ways that create unnecessary obstacles to LinuxMCE integration, so these things have needed to be pre-seeded in the past, and lots of little tweaks have been needed along the way.
Phenigma is doing some MUCH needed work, to clean this up. It's long, it's grimy, parts of it are freaky, and other parts will invariably cause hair loss, but what will come out of this is literally the ability to do:
Code: [Select]
# apt-get install lmce-core
# apt-get install lmce-hybrid
# apt-get install lmce-disked-md
etc..
and have LinuxMCE install itself and its needed dependencies to the point where the next boot then falls into the AV Wizard, and subsequently into a functional LinuxMCE system.
This leads into a refactoring of the whole start-up process, to use systemd. Whether you like it or not, systemd has become the accepted standard for the start-up of system and user services, and it is in our best interest to ensure that LinuxMCE starts and stops itself in a way that can cleanly be expressed in systemd.
As always, if anyone out there can help phenigma in his quest to vastly improve the plumbing of the system (which will ripple all the way up to the user experience), please contact him. This is important work.
-Thom
33
Developers / Re: Slow and steady ... moving from Trac to Gitlab
« on: August 22, 2015, 04:33:41 am »Sweeet! And thanks for your efforts!
At work, we switched from Git/Trac to Git/Gitlab, and it's sooo much more of a productive environment. We've got hooks from certain projects into Jenkins for building RPM's 5 minutes after a commit, and that's sweet from a packaging point of view. Jenkins really rocks as well! (BTW, there's a .deb builder plugin for Jenkins if that's of interest to you)
I have a small request of you and the core devs. Gitlab represents a real opportunity to enable more people to get involved in LinuxMCE development and testing. In the past, I didn't want to have any form of SVN access; I know enough to know I don't know enough about LMCE to event want any commit access (bull in a china shop syndrome). So, that limited me to filing tickets with diffs attached.
Gitlab changes all of that. The core devs can steward the main linuxmce project, and personal workspaces allow more novice folks like myself the opportunity to contribute through an isolated environment and merge requests. So, I would like to make the following request:
Could you folks create a wiki page with some example workflows that would enable folks like myself to contribute more, while minimizing the level of effort on the core devs to take advantage of what we do?
I'm thinking of example workflows like:
- simple bug fix for existing code
- significant bug fix for existing code or refactoring
- simple new feature (new code)
- significant new feature (majorly intrusive)
I think that giving us examples of how you want us to work would be good for us novices to learn, while making life easier for those already overcommitted core devs. Maybe even a quick page on how issues should be filed might be good for standardizing and leveraging Gitlab's capabilities...
Just thought I'd put this out there for your consideration.
Thanks again for your hard work on this! I'm sure it wasn't easy, but it will be worth it in the long run!
/Mike
A good post! Of course ,you're assuming we actually _have_ a workflow, but we don't....really....other than:
* File a ticket in trac
* assign your commits with Refs #1234 for that ticket
* make sure when you're done with it to close it, either with Fixes #1234, or by marking it closed or fixed. (depends on the ticket type).
Maybe we should... I dunno, what do you think, posde?
-Thom
34
Developers / Re: Developing a Weather Plugin, videos
« on: August 17, 2015, 11:33:22 pm »
Hey guys, have rewritten the Configuration device data parser in the Weather device to use cleaner parsing methods, invalid data should no longer cause a segfault, but print an error, and exit the device.
Commit is here:
http://svn.linuxmce.org/trac/changeset/31086
-Thom
Commit is here:
http://svn.linuxmce.org/trac/changeset/31086
-Thom
35
Developers / Re: Link Aggregation in LMCE
« on: August 14, 2015, 06:56:18 pm »
Dude, you've got my vote. What do you need from us?
-Thom
-Thom
36
Installation issues / Re: Issue with 12.4 video play back of mp4
« on: July 12, 2015, 07:51:03 pm »
The output from Xine_Player's screen session may also prove helpful here, can you paste it?
-Thom
-Thom
37
Users / Re: apt-get upgrade problem
« on: July 01, 2015, 04:38:06 am »
You might want to go to 12.04 or 14.04 going forward, as 10.04 is no longer supported.
-Thom
-Thom
38
Installation issues / Re: Hauppauge Colossus PCIE
« on: June 22, 2015, 08:46:28 pm »
Somebody needs to grab the card, verify its operation outside of LMCE, and then we can get a device template made for it.
-Thom
-Thom
39
Feature requests & roadmap / Re: Integration of streaming sites?
« on: April 28, 2015, 07:09:15 am »
We would love to. It mostly boils down to DRM issues in Linux.
-Thom
-Thom
40
Users / Re: Need some dedicated testers.
« on: April 13, 2015, 02:40:54 am »
Same here with latest android build in channel topic.
-Thom
-Thom
41
Feature requests & roadmap / Re: Mintube
« on: March 26, 2015, 10:24:49 pm »
Add it. At the very least, look in the wiki under computing application.
-Thom
-Thom
42
Developers / Re: Developing a Weather Plugin, videos
« on: February 09, 2015, 04:43:21 pm »
Guys, you can capture all the radar data from weather.com.
If you look in MythWeather's source tree, there is an XML file (maps.xml), that contains all the known radar imagery.
It just needs to be mapped.
-Thom
If you look in MythWeather's source tree, there is an XML file (maps.xml), that contains all the known radar imagery.
It just needs to be mapped.
-Thom
43
Users / Re: Roku 3: Does Roku Netflix Player template 2049 apply to the newer devices
« on: January 27, 2015, 12:00:19 am »
Yes, it does. It was rewritten to be a C++ driver, that talks ECP to the newer Roku 2/3/4 devices.
-Thom
-Thom
44
Feature requests & roadmap / Re: does/can linuxMCE interface to totally custom applications?
« on: January 20, 2015, 07:50:35 pm »
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
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
45
Developers / Re: Myth MD/Orbiter
« on: December 01, 2014, 06:12:15 am »
Nah, just another developer who is all talk.
We've had plenty of them. All talk, no show.
What he wants to do is not only possible, but doable, with maybe 100 hours of work, including the requisite research. Shorter, if he were to actually talk to us, and work out the details.
But no, it's another person who finds excuses, instead of solutions. So long as he acts like this, none of us have the patience for him.
Ask anyone else who has put in elbow grease on this project, we bend over backwards to help them.
-Thom
We've had plenty of them. All talk, no show.
What he wants to do is not only possible, but doable, with maybe 100 hours of work, including the requisite research. Shorter, if he were to actually talk to us, and work out the details.
But no, it's another person who finds excuses, instead of solutions. So long as he acts like this, none of us have the patience for him.
Ask anyone else who has put in elbow grease on this project, we bend over backwards to help them.
-Thom