Messages

46

Users / Re: Will beryl or compiz break LMCE? (see bottom of thread)

« on: December 21, 2007, 12:35:20 am »

That's great news! I really didn't like the idea of being forced to use a specific WM...

47

Users / Re: Storage sizing

« on: December 18, 2007, 08:49:49 pm »

As to the size of DVD's it really depends on what kind of DVD's you rip. I currently have 107 dvd's riped that take up 954GB, which would work out to 8.91GB on average...

I'm currently thinking of just re-encoding a lot of those DVD's. I find that re-encoding them to x264 at a decent bitrate saves a lot of disc space and my eyes often see it looking BETTER than the original... My main consern is the lose of the menus and special features. Does anyone know of a way to re-encode a DVD, while still keeping all the menu's and special features... that I almost never use...

48

Developers / Re: DLNA Support?

« on: December 18, 2007, 08:28:17 pm »

Honestly, I had some stability issues with MediaTomb (it would crash often after playing a few mp3's, or running for a day straight), when I tested it with my PS3... but to be fair that was about 6 months ago and those issues could have been resolved since then...

49

Users / Re: PSP as Orbiter

« on: December 18, 2007, 08:22:10 pm »

No, the PSP doesn't have a touch screen. I agree the new smartphones are great canadites and more of them to need to get supported. I just replaced my Treo 700p, which was completely unsupported, with the new HTC Mogul, a WM6 device (ick, I know). Anyhow, those devices are sort of, kind of, supported. I did manage to get it running... but it had some issues. I was going to track those issues down and perhaps build a proper WM6 orbiter, but then my Core MB died... again... I still haven't got to replacing it yet (long and complicated story).

But, I still think it would be cool to use the PSP as an orbiter.

50

Users / Re: Will beryl or compiz break LMCE? (see bottom of thread)

« on: December 18, 2007, 06:55:27 am »

Compiz is not just for Gnome, many people run it in KDE as well. Granted there are Gnome elements in it, but some are actually being stripped out.. and it really doesn't matter what libraries an app uses...

The problem, as you stated, is that Compiz requires 3d acceleration that can compete with other 3D things... of course that's rare and with Compiz-Fusion 0.6 it's actually very stable and can work with other GL apps nicely (it's been running for 2 weeks straight on my Gentoo box)... and when it doesn't you can set Compiz to turn off compositing for that app.

The bigger problem is that the new design of the MD UI will shift allot of the alpha-blending stuff to the new KDE WM, as stated by Paul... this will effectively kill all other WM options for LinuxMCE... this shift i all heartedly disagree with...

Edit: I forgot to mention that I did install Cedega and Crossover Office (two Wine variants) on my Core and they worked just fine.

51

Users / Re: Cable TV with Linux MCE (Virgin)

« on: December 09, 2007, 09:30:48 am »

You get a TV capture card and connect it to your computer. Connect the Video Out on the cable box to the capture card. Then either connect the computer to a serial connection on the cable box (only if it's supported) or use an IR blaster to have LinuxMCE control the cable box. Then you can output to your TV using whatever your TV supports. Some TV's support VGA, DVI, HDMI, S-Video, Component, etc. It all depends on your TV and computer video card.

I'm pretty sure this is all explained in the Wiki...

52

Users / Re: Core w/ raid 5...

« on: December 09, 2007, 09:26:21 am »

Yes, LinuxMCE supports RAID; it's in the WiKi... Although I wasn't particularly impressed with how it handles it. There doesn't seem to be an easy way to have the RAID array be the root of all the storage (mount directly to /home). Of course you could do this manually, but that defeats the purpose. The end result is that everything will use your main drive and ignore your RAID array by default...

I don't know if Linux supports that particular card or not, but if Linux in general supports it then LinuxMCE does.

53

Users / Re: networking

« on: December 09, 2007, 09:16:22 am »

Yes, but that would make the Core serve the internet, which seems to be not what he wants. It's not the most secure solution, but it is the default one and the one I use...

At least before my Core died... for the third time... due to electrical surges of all things... and yes I have a surge protector... not that they're really any good when a real electrical surge occurs inside the house...

54

Users / Re: networking

« on: December 08, 2007, 07:20:46 am »

You can configure the wrt54gs to be the internet gateway without being the DHCP server for the house and still have all your computers connected to the wrt54gs .

Method 1:
You will need to setup an appropriate VLAN that will allow one of your Ethernet ports to connect to LinuxMCE's External interface, which routes to the wrt54gs WAN port, and the rest be a dumb switch that connects to LinuxMCE's internal interface. The wrt54gs will route everything connected to the external interface out to the internet (first going through it's internal firewall) all all the rest will be routed to LinuxMCE. If any one of your computers need to connect to the internet it will first go through the wrt54gs to LinuxMCE and then back to the wrt54gs out to the internet. This method is pretty secure, but if you don't know how to setup the wrt54gs to do this...

Method 2:
This one is the easiest. Give the wrt54gs an IP on a differnt subnet as the LinuxMCE core and make sure the dhcp server is turned off on the wrt54gs. Connect the only NIC (yes you only need one for this) on the LinuxMCE core to one of the LAN ports on the wrt54gs. Tell LinuxMCE to connect to the internet using the gateway IP that you set on the wrt54gs and manually set the IP address for LinuxMCE's external interface (even though there is one NIC there will be 2 interfaces) to an IP on the same subnet as the IP you set the wrt54gs to. The end result is all traffic will flow through the wrt54gs and all internet traffic will be routed out via the wrt54gs.

55

Developers / Re: LinuxMCE Developer's Guide

« on: December 08, 2007, 06:56:20 am »

I echo Mathew's comments, but I'd like to also add that everyone posting in the forum should read that page (unless you're already a guru)! It made for enlightening read. Although I understood how DCERouter worked at a high level, this summarizes a lot of the details very well.

Thank you!

56

Users / Re: Importing Mythtv Recordings

« on: December 07, 2007, 04:08:52 am »

It's actually in the MythTV wiki, which is why I didn't duplicated it here.

57

Users / Re: Importing Mythtv Recordings

« on: December 07, 2007, 02:33:57 am »

Yes, I do this frequently. I explain this in another post. Do a search and you should be able to find it easily.

Note that you will have to do this using mysql and the command line.

58

Developers / Re: Appliance vs Package vs Distro

« on: December 07, 2007, 01:12:00 am »

On configuration and the DB, I absolutely prefer all configs to be mediated by the DB. It makes keeping multiple scenarios available much more straightforward. It makes config UI more accessible to different user apps, without as many permissions problems. It makes configs across the network more easily programmable than editing files, modeling dependencies between components, and to their configs, in simple relations. It enables easily deploying new installs against existing configs, whether local or from a networked community, which is one of the visionary promises of LMCE.  And offers all kinds of other features that the bare filesystem doesn't (eg. scalability including factoring to a standalone but clustered network config server). The way to get what we all want is just to include a script that updates the DB when filesystem configs are changed, just like the reverse that LMCE already provides.

I think we may be thinking of two different things here. The configuration for DCERouter, including the device configuration, scenarios, etc, should definitely continue to be in the database. Moving that configuration from the database to files would be a waist of time... and going in the wrong direction... What I'm talking about is the configuration for the external applications, such as MythTV and Asterisk. There is no getting around LinuxMCE having to modify the configuration through that app's specific configuration process. MythTV has its own database, so the configuration should be there and only there. Currently it's in other locations in the LinuxMCE database as well, which frustrates people like me to no end. Also, for other apps that don't have a database, such as Asterisk (yes, I know it's possible, but we aren't doing that right now) that configuration should be modified directly through that app's configuration files. Again, let me reiterate that we will still have to modify those configuration files even if we store the configuration in LinuxMCE's database or the app won't be configured.

Let me clarify what directly means: All configuration should be modified through a standard API. The orbiters and such would not know or care how the configuration is being modified, whether it be through a database or configuration files. It would just do the tasks it currently doing without the database storing duplicate data. We wouldn't run into any permissions or networking issues as a LinuxMCE service would be taking care of all the configuration stuff (which would be running with the necessary permissions); the orbiters would just be telling the service what needs to be configured and the service takes care of it. This is the point of having the standard API. None of this would be possible without it.

59

Developers / Re: Appliance vs Package vs Distro

« on: December 06, 2007, 11:34:27 am »

Wow, this turned into a rather heated debate...

The MPlayer/Xine discussion:
The current approach of the system deciding which media player to use for a particular task is the correct one, in my opinion. Granted, that there is more work to do and some code probably needs to be cleaned up (I'll just take Thom's word on this as I haven't looked at it myself), but the general approach is sound. Lets say a brand new codec came out that only one Media Player specially designed for that codec could play, we would want LinuxMCE to just launch that player without the user having to think about it; as far as they would be concerned LinuxMCE could play their media and that's all they (including me) would care about. Of course if MPlayer does prove to have more performance (yes, this is extremely important for LinuxMCE) than Xine in certain areas then we should expand MPlayer's use for those cases, but only those cases.

The package discussion:
The whole package debate is moot. LinuxMCE already has packages and the new release will expand on this. It has been LinuxMCE's goal from the beginning to be on top of another distro like that. And, no, this would not in any way make it not an appliance. LinuxMCE should always have a default install and wizards that configures everything for the user and JUST WORK. Making packages doesn't change that... The packages just help with upgradability and scalability... which also helps with the security...

The UI discussion:
I couldn't agree more that the UI needs work. I have mentioned this several times in other places and even gave some thoughts as to improving it. I also couldn't agree more that developers that specialize in functionality shouldn't be creating the UI. I, myself, am an "under the hood" type of developer and as such I almost never create a UI on my own. What I usually do at work is create some focus groups from users, and create a few mock-ups for them that mimics the most important functionality (this production quality code is later re-used). The end-users usually have the best ideas on how the UI should operate. Then I work with some artists (not very many developers can do this and we desperately could use some artists in this project) to make the UI look pretty. Then I take it back to the users and get their thoughts again. After a few more tweaks we have a damn nice UI. This may seems like a lot of work, but it really isn't and is the best approach, IMHO, to get a functional, intuitive, and pretty UI. This also coincides with the Unified Process. You OOP devs should know what I mean...

The configuration discussion:
This is where I think I disagree with some of what Thom said. I don't think the database should be used to store the configuration as an intermediary between the applications config and LinuxMCE. We definitely need an API that as an intermediary (we don't disagree there), however this API should directly modify the applications configuration rather than have the config stored in LinuxMCE's database and then use what is stored in that database to actually modify the configuration. If it modified the configuration directly then user changes to that configuration (if they used the applications own configuration editor, for example) would not be wiped out and LinuxMCE would just continue on using that configuration. I don't think this would break the appliance aspect of it as the wizards and install process (in the orbiter, or web, or whatever) would continue to use that API and wouldn't care how that API gets or sets the config. Granted this isn't important if all we want is an appliace, but we want more (at least I do). I want to be able to have something that JUST WORKS and be able to customize it easily without having to go through LinuxMCE's databases or specialized configurators. This is certainly a tall order; I'm definitely not disagreeing there, but lets face it, the people who are using this system now are the type of people who want to customize things... but without getting a migraine from dealing with LinuxMCE constantly changing things back and then having to poor through the database and code to see why that's happening...

Summary:
LinuxMCE should always be able to be an appliance by default, but should also play nice with others. Please note that I'm not in any way putting down the devs that put this thing together. It's remarkable that they were able to get all the apps they have working together as seamless as they are now... I just want that expanded upon so it's even more seamless in the configuration standpoint. Also, the UI needs work before LinuxMCE will ever reach the average end-user. I cannot and currently do not recommend LinuxMCE to my friends and family because I know it would frustrate them to no end (though they wouldn't care about being able to configure things outside of LinuxMCE)...

60

Developers / Re: Appliance vs Package vs Distro

« on: November 30, 2007, 08:35:37 am »

I'm a fan of working hard after the 710 release to get LinuxMCE in a package form. I think the admin site needs to be completely re-written (it should be an optional plugin for the package version), we need to get rid of the mysql database (at least the parts that have to do with system config) and get rib of all os specific stuff like the boot scripts. The package version should care about firewalls, remote access, ssh keys or any of that stuff. Users should be based on the OS users and the list goes on.

Then if people feel there is still a need for an appliance version, we can pick an OS, and do much like we do now. Except, the website would be installed by default, we would care about firewalls, ssh etc. In fact it would be very similar to now, but the appliance stuff should be very low maintenance. The majority of work would lie in the package.

Is this the feeling amongst the community or have i taken it further then what people were expecting?

We can't get rid of the database, but I do agree that the system configuration stuff should be cut out. If LinuxMCE wants to do system configuration it shouldn't duplicate the config in a database and then modify the config files. It should just read and write the config files. In fact, I think any configuration for another application should use the that specific application's configuration files. I just gets really annoying... Of course re-writing this is a major chore...

I too am a big fan of the packages and the 0704 release was a big step in that direction. There are still some issues to work out, however.

I do think that the website should continue to be installed by default... it's currently the only way to configure many things... of course, you're right, the website could use some improvement... but I also think there are bigger issues that need to be tackled first.