Messages

136

Developers / Re: up to date svn ?

« on: October 29, 2007, 03:33:45 pm »

The only significant difference between the svn that 0710 will be built from and the svn.charonmedia.org is that the 0710 repo is not public and has a more recent sync from mythtv 0.20-fixes. I have read access to the 0710 repo and will sync from it after the release.

I would like to move to MythTV trunk in the public repo and I'm working on making the build scripts not depend on hard coded paths and URLs. Except for making some suggestions to improve the MythTV default configuration and looking at a couple of "MythTV crashing in LMCE" problems, I'm not involved with 0710 release. If all goes according to plan 0804 will be build from the sources available at svn.charonmedia.org, which will be mirrored at svn.linuxmce.org, soon...

BTW There is a developer mailing list at www.charonmedia.org...

137

Developers / Re: Building a dev environment for 0704?

« on: October 25, 2007, 12:36:48 am »

I added some hacks to Install_Build_Needed_Packages to get libmysqlclient15-dev installed.

just get the sources at svn.charonmedia.org and type:

./configure
make install_dev_packages

Alternatively, you can inspect src/Ubuntu_Helpers/BuildUbuntu_Functions.sh and look at the Install_Build_Needed_Packages function. The hack I made may not be the best hack. It might be better to force a specific libmysqlclient15-dev package, rather than specific libmysqlclient15off and mysql-common packages. For an example, see libvorbis-dev, where I forced a specific libvorbis-dev version rather than upgrading the underlying library.

138

Developers / Re: Where is Pluto Inc?

« on: October 24, 2007, 07:32:26 pm »

From what I can tell they are basically an OEM now, they make software which others market under their own names. I talked with Aaron just last week and they are alive and well. If you look at the svn repo I created you will see hundreds of commits brought over from the Pluto source. By donating these pieces of code it lets vendors know that if they want something similar to LMCE, but maybe with more polish or a different PVR component, they can go to Pluto and have them whip something up for them and take care of all the licensing. But part of the job of the OEM is to stay behind the scenes and let someone else take all the credit in public.

I'm more concerned about where Paul is.

139

Developers / Re: Reorganizing development for scalability

« on: October 24, 2007, 07:14:30 pm »

Let's move this discussion to the mailing list...

140

Developers / Re: Reorganizing development for scalability

« on: October 24, 2007, 03:12:07 am »

I don't see how we can point everyone to the new sqlCVS unless we get the sucker to build...

I don't think sqlCVS is unimportant.

BTW If someone could get it working on their own and then tell me how to get it working on the server this would speed up the process of getting it working...

141

Developers / Re: Reorganizing development for scalability

« on: October 22, 2007, 06:58:17 pm »

Is there space/capability on the servers that you setup to host the sqlcvs master(server)?
Yes.

New devices and device templates as well as changes to existing ones are just as crucial to move forward as being able to compile the code base.

I don't think it is just as crucial, we can update the DB in the compile and so add devices and device templates. When we get things compiling, I'll look at what it will take to get a sqlcvs working for us.

142

Developers / Re: Reorganizing development for scalability

« on: October 22, 2007, 07:31:57 am »

I understand that MythTV's backend is doesn't contain the functionallity of DCERouter at this time.  My suggestion was that maybe it should.

The concept behind MythTV and Pluto are one and the same, to create the "Mythical convergence device" for the home. Consequently there is a lot of overlap in functionality. MythTV is bolted on to Pluto for the PVR functionality, but it actually contains many of the components for which Pluto already has home grown solutions. In many cases these are more mature solutions. Pluto is a lot like Freevo, and in it's architecture is more like a bazaar than the cathedral like MythTV. In their development the roles are reversed which helps explain the strengths and deficiencies of both.

I think what you really want to do is have a choice in what DVD player to use or what movie player to use and get the full functionality of whatever player you choose without needing to reconfigure everything. The good news is that LMCE is open, it is what you do with it. If you write code to translate between the Pluto and MythTV movie databases then they will play nice for you and everyone else.

LMCE can bring the strengths of both these approaches to the same problem together into a unified whole. Paul has done a lot porting the Pluto components to Ubuntu, but there are two problems we need to address right now, stability and integration. And we have to do this without forgetting to apply patches for functionality like Peter's Insteon driver. Part of the stability and integration problem will probably be solved by both the MythTV and Pluto groups, but parts are unique to the LMCE software or unique to the esoteric hardware used out there by LMCE users installing the software on their own PC's.

Step 1 for me is to get LMCE to bootstrap itself. This is the best way to make sure that all the components can be build independently and that all the dependencies can be satisfied on a running LMCE system. (I've run into missing dependencies trying to compile various individual components, I would rather resolve them all and share with everyone else than just resolve my own issues and move on.)

143

Developers / Re: Reorganizing development for scalability

« on: October 20, 2007, 05:13:26 pm »

The tag is there to help with any future syncs from pluto's repo, there is also a vendor branch where most of the action happens. (See the subversion documentation on vendor branches).

I haven't heard back from Paul since early last week, the plan was to let him commit his changes to the new tree.

All the commits starting with a horizontal line are pulls from the Pluto repo. I used a couple of scripts to do this. This was before I had trac installed so, I didn't realize that the extra lines would cause this problem, otherwise I would have filtered them out. The comments are still there and available via "svn log". Each commit also contains the pluto revision number it corresponds to. These were applied in order so you can see that there are some missing revisions. This is mostly due to commits to other branches in the same repo, unrelated to LMCE.

144

Developers / Re: Reorganizing development for scalability

« on: October 20, 2007, 06:03:21 am »

SVN+TRAC: http://svn.charonmedia.org
DEV MAILING LIST: http://www.charonmedia.org

We may want to move this to linuxmce.org later, but this should work for now. I haven't finished setting up trac, but it has some spam prevention enabled, as does the mailing list (first post is moderated.) There are directions for the getting the svn trunk using a tbz download followed by an svn update. Other checkouts are left as an exercise to the reader, the tbz is less than400MB so it saves a lot of time on the checkout of the 1.4GB trunk branch.

There is no build script we can use yet. I've been working on this locally for a few days, but it will take a few more before I get something basic going.

145

Developers / Re: Reorganizing development for scalability

« on: October 20, 2007, 02:08:54 am »

Danielk I have seen chriss say several times that he already has SVN and trac setup, why are those messages being ignored by you?

Those were definitively not ignored. We've been talking off-line. He's using a server that is also being used for other things so he can't let other people on it, except in a very limited way, nor is he comfortable using standard ports for various services on that machine so it's not ideal.

I have an SVN/trac/mailman server set up that I'm testing right now. Just give me a few more hours...

146

Developers / Re: Reorganizing development for scalability

« on: October 17, 2007, 05:22:02 pm »

Have you managed to build the MythTV devices? I imagine this is where the focus of your fixes would be.

I haven't actually tried this yet. I've build the Orbiter and some other modules. For MythTV the first thing I want to do is actually just configuration stuff. When running full screen it shouldn't be using a window frame, when recording NTSC it should record the captions, when recording PAL it should record teletext, it should be compiled with threading support, it should use a decent V-Sync (RTC or OpenGL V-Sync), the video directory should use the XFS filesystem and a daily defrag should be run, autodelete should leave more of the disk available for non-mythtv stuff by default to avoid both fragmentation and because we should assume that the partition contains more than MythTV recordings, we should set up the Linux kernel for A/V (enabling preempt smaller time slices), MythTV should be coordinating the time of the Schedules Direct download, MythTV should be themed to match the LinuxMCE theme, the orbiter OSD and MythTV OSD's are not coordinated, etc. etc.

MythTV is also just not as stable as it should be in the LinuxMCE environment. This will probably take a bit more work to get to the bottom of and fix. It looks like we're pulling some qt 3.3.8 packages, which is known not to work well in multi-threaded environments, but the problem is probably more complicated than that.

My own pet peeve is the inability to configure LinuxMCE to use an existing MythTV frontend - I have a frontend that has been recording since September 2004. It's rock solid and my family relies on it heavily. I am not willing to replace that with LinuxMCE, at least not in the foreseeable future.

I think you must mean an existing backend. This can be done, but is a bit problematic at the moment because of how the listings are downloaded. You basically need to make the LinuxMCE core machine the master backend, and turn your existing master backend into a slave backend. Or you can just keep both master backend running independently and point your frontend to the one you want to watch recordings from. This can be done by making a copy of your ~/.mythtv directory and editing the mysql.txt in that new directory with the DB info for the other master backend; then just run mythfrontend from that directory when you want to connect to the other master backend.

I personally think that there is a lot of issues in how tightly coupled the orbiter has become to some of the media devices and think that this is the cause of a lot of issues, as it makes the code brittle and too hard to do simple changes.
I also think that all teh Media player (XXX_player) devices should be contained by the media director itself and not the onscreen_orbiter - but that is another issue.

Can you give an example?

147

Developers / Re: Reorganizing development for scalability

« on: October 16, 2007, 12:07:43 am »

are you the same as the danielk mythtv dev?

Yup. And one of the reasons I'm getting involved is because the MythTV integration needs a little loving.

I also have a drawer full of X10 stuff I haven't unpacked since I moved recently and I think Pluto is a much better option than MisterHouse or my own scary scripts for setting something reasonable up. And since I moved, I've been planning to set up an Asterisk server as well. LinuxMCE is the only thing that promises to get all my hardware to play nicely together. I think it's pretty close, some of the MythTV issues I see will take me 10 or 15 minutes to fix once we have source repository to work with and a build process that will let me test the changes easily.

BTW I've yet to get LinuxMCE to compile from the ground up, but I've gotten some parts of it to compile. One of the things we need to do early on is get a proper build process in place. Right now I'm trying to reconcile the LinuxMCE 0704 code and Pluto's svn. Then I'll set up the public repository and mailing list with Chriss' help, then we'll see where things go...

148

Developers / Re: Reorganizing development for scalability

« on: October 15, 2007, 03:12:47 pm »

DTS, the main benefit of the mailing list is more instantaneous communication.

Chewi, for commit rights we'll give these to those that contribute patches to trac. Initially it will be me, Chris and Paul, when we've committed a few patches from someone that person will be asked if they want commit rights and the responsibility that comes with it. Chewi do you want to move tickets over from Mantis? Someone needs to do it...

149

Developers / Re: Reorganizing development for scalability

« on: October 12, 2007, 08:03:55 pm »

Status report...

I've had some problems contacting Paul and Razvan, but I'm moving ahead with setting up a server with svn + trac. I'll just start the repository using what sources we have. The server I'm setting up for the SVN is an old P3, but it has a gig of RAM and a 1000 GB per month of download bandwidth, this should be enough for SVN. If we want to replicate the kind of nightly build process Pluto uses we'll need a more powerful server for that. I think the server Paul has is sufficient for that purpose and it's probably best to keep SVN on a separate machine anyway. Plus, I don't think the nightly build scripts Pluto uses will work for us, the scripts seem to be pretty hard coded with IP addresses and the like right in the scripts, so we'll need to edit these for our purposes before we can use them.

150

Developers / Re: Reorganizing development for scalability

« on: October 11, 2007, 12:52:24 am »

I tested a bunch of revision control systems last year and darcs lost data. As did arch, the one with my favorite UI of the distributed revision control systems at the time. Darcs was also difficult to work with, a problem that arch and git don't suffer from.

I didn't know someone had written trac scripts for git, I stand corrected. But I still don't want to use a 0.0.1 script to link the revision control system and bug tracking systems. The whole reason I want to get involved is to make it easier for developers to jump right in and start coding without having to learn a whole bunch of new systems. Perforce, svn, cvs, rcs and ClearCase are probably the only revision control systems that fit that criteria. Of those, svn and cvs are only ones it makes sense to use for a new repository for open source development, and most projects that were using cvs have switched to svn for faster diffs and better branching.

If this is a monumental success with hundreds of active developers we can always switch to git or bazaar or whatever is best at the time later. The important thing now is to get a repository setup with all the latest changes and on a server that can handle the load..