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 - Monkgs

Pages: 1 [2] 3 4 5
16
Developers / Re: Custom kernel modules in LMCE
« on: September 19, 2008, 06:32:04 am »
Colin,

 Did you have a go at this yet. How did it work out? I have that kernel compile and waiting I just have not made the changes to boot from it yet!

 Dave

You can always setup a new boot option for the new kernel. If it doesn't work right then just boot the old one.

17
Users / Re: MCE 0810 / Blu Ray
« on: September 12, 2008, 01:22:56 pm »
There is no LMCE0810 in the near future.
I won´t indicate any dates. It will just start a bunch of speculations.
We have to resolve several issues before we even get it to compile correct.
Untrue. See this thread http://forum.linuxmce.org/index.php?topic=6194.0.

Remember, we do not have any commerical sponsors behind us. Only the community.
Also untrue. There are many companies (or at least one) selling LMCE based smart home solutions who contribute to the development of LMCE.


18
Developers / Re: Custom kernel modules in LMCE
« on: September 12, 2008, 12:15:24 am »
Well, the Wiki is up now. I tried to get as many modules as I could. If I missed something, let me know.

http://wiki.linuxmce.org/index.php/Upgrading_the_Kernel

19
Developers / Custom kernel modules in LMCE
« on: September 10, 2008, 11:40:55 am »
According to the Upgrading the Kernel wiki, and the charon svn there are a few drivers compiled as part of LMCE. Are these sources actually patched in any way from their original versions? Excluding the video drivers, most of the drivers appear in the mainstream kernel and the rest aren't even installed on my LMCE box.

I've been running a 2.6.26 kernel for sometime now, with no issues. I would like to document this in the Wiki along with a mini-HOWTO. And hopefully not break anyone's setup in the process.

20
Users / Re: Demo: LinuxMCE's UPnP to a Nokia N810, playing audio and video.
« on: September 10, 2008, 10:51:27 am »

Are you referring to the upcoming 0.12 version or the existing 0.11?
Don´t have a 360 to test with so I cannot say for sure.
A lot of things for X360 have been added into trunk version.

And mostly. The problem is MS way of implementing thins as ususal.

/niz23

I was simply referring to the documentation from the website. Also the developers have made several posts on the forums indicating that it's far too much work to support the Xbox, and that it won't be happening. Additionally there is no xbox code in the latest development trunk.

21
Users / Re: Demo: LinuxMCE's UPnP to a Nokia N810, playing audio and video.
« on: September 10, 2008, 07:06:49 am »
And last but not least. Support for Xbox360 and PS3 is excellent.

/niz23

Just to be clear, Media Tomb does not fully support Xbox 360. It may support audio, but definitely not video.

22
Users / Stability survey
« on: September 09, 2008, 09:17:46 am »
Discuss.


23
Users / Re: PXE boot just keeps rebooting..
« on: September 09, 2008, 06:54:26 am »
Adding some info and a quick fix for this problem.

Basically, when a computer PXE boots it loads a configuration file from the tftp server which tells the boot loader what settings and what kernel to load. This configuration file is assigned based on MAC address. If for whatever reason the MAC address stored in the Pluto database does not match the MAC address used by the PXE boot rom of your NIC, then this configuration file never gets loaded and your computer will continuously boot the "first time setup" configuration file.

This is a big issue with some newer nForce chipsets. Older nForce NICs had a firmware bug that caused the MAC address to be stored in reversed order. The Linux driver solved this issue by reordering the MAC bits so they were in the correct order. With the newer nForce NICs, the firmware was changed so the order was no longer reversed. The driver however still reverses the MAC bits, so the result is a reversed MAC in the OS.

There is a fairly easy way to fix this. You'll need your NIC's MAC address from the PXE boot rom, NOT from the Linux boot messages. This will usually be displayed when the PXE boot sequence tries to get an IP. Mine was "01:1F:D0:83:EA:AE".

You'll also need to know your MD's device number. This is displayed before the system reboots. It will say "Assigned permanent IP '192.168.0.100' to device '54'" or similar. Write down what number it says after device. This is your device number.

On the core, as root, go into the folder "/tftpboot/pxelinux.cfg". Look for the file that contains the device number matching your MD. Using 54 as an example, you would look for the line "KERNEL 54/vmlinuz". This file is the configuration info your MD is SUPPOSE to load, but isn't. In my case the file was "01-ae-ea-83-d0-1f-00". Notice how it's the opposite of the MAC address I got from the PXE boot above. In your case it might not be the opposite.

Each file is named after the MAC address of the client it belongs to, and is prefixed by "01-". You'll want to symlink the configuration file to a new filename, which matches the MAC address you wrote down earlier.

Using my information as an example, I would do this: "ln 01-ae-ea-83-d0-1f-00 01-00-1f-d0-83-ea-ae". You may use a symlink instead, if you do not intend to apply the immutable attribute (below).

A quick reboot and my MD is up and running. I'm not entirely sure if the pxelinux.cfg folder is ever wiped and regenerated from the database. As a precaution against scripts removing your link, you may make it immutable by issuing "chattr +i 01-00-1f-d0-83-ea-ae".


24
Feature requests & roadmap / Re: Better Media Organization / Browser
« on: September 08, 2008, 06:06:02 pm »
And yes I think everyone recognises that the coding is long hard work, but rewarding. I have done some coding so know the late nights and the hair-tearing with bugs.  The documentation and wikis etc are tedious and are not rewarding in the same way.

What's your point?

25
Feature requests & roadmap / Re: 2 orbiters on one machine??
« on: September 08, 2008, 10:15:58 am »
While I know this isn't supported "out of the box", surely it can't be too hard to get this working with some tweaking. I think you'd have some HID issues if you went the multi-desktop route and wanted to use the remotes to control each orbiter separately. Instead I think the way to go about this would be to run two X-servers, that way you could isolate the input devices. For dual-video card boxes, this shouldn't be an issue. For multi-head video cards you might run into some issues.




26
Feature requests & roadmap / Re: DHCP & network configuration revamp
« on: September 07, 2008, 07:07:58 pm »
Done ;) I'm gonna do some more testing before I upload it. The gateway mode is business as usual (IP aliasing if you have only 1 nic), the standard mode does away with all that and gives you just one normal interface. I need to do some more testing though, because I'm sure lots of scripts expect two NICs (other than the ones I've already patched).








27
Feature requests & roadmap / Re: Roadmap
« on: September 07, 2008, 05:48:36 pm »
Somewhere on that list we need an admin site rewrite. It's pretty bad, and that's being nice about it.

28
Users / Re: Any RAID gurus in here? (more RAID problems)
« on: September 07, 2008, 03:21:35 pm »
I know this thread is old, but I just thought I'd post the solution in case anyone else runs into this issue.

This issue occurs on nforce boards utilizing the HPET chip, running kernels built with AMD_X64 prior to 2.6.23 and running Asterisk module zt_dummy. I'm not sure what broken code exists in the zt_dummy module, but it causes a lockup of seemingly random devices (read NIC, SATA, IDE, etc.) after an arbitrary number of RTC errors.

Using a kernel that is compiled with HPET_EMULATE_RTC=y option will solve your issue (this config option is enabled by default in all build architectures except AMD_X64, in which it was disabled by accident). Additionally, removing the zt_dummy module will work (but also break Asterisk). On some boards that have both RTC and HPET chips you can disable the HPET chip in the bios, although I don't recommend this on anything that will be playing media. The HPET is useful for smooth playback of processor intensive media, such as h264 content.

I'm not entirely sure if these boards emulate RTC for older operating systems, like Windows XP or if they have both an RTC and HPET. If you disable ACPI that should also force the system to use the RTC or emulate it at least.



29
Users / Re: Radiator zone valves
« on: September 07, 2008, 02:03:28 pm »
There are lots of z-wave controlled relays with isolated contacts. Such as the ACT ZRF113 or the ZRW113X. I think temperature sensors were the one thing that actually works for 1-wire stuff. Although I've never tried it personally. I have a 1-wire network that I will test out later and let you know.

30
Users / Re: Quality of TV tuners?
« on: September 07, 2008, 10:13:53 am »
I did a more in-depth comparison last night.

My satellite box is connected to my tv by standard rca composite cable, and to my pvr-500 tuner 1 via s-video.
The recorded video is of much better quality than composite straight to the tv.
Comparing an s-video feed straight to the tv to a recorded s-video feed, I could see no difference in quality. The only difference I could see was that the recordings were a couple of pixels short (horizontally) from filling up the screen.

Excellent. This is what I was hoping to hear. Thanks!

Pages: 1 [2] 3 4 5