Messages

76

Users / Re: Can't get MCE_USB remotes to work on 10.04 MDs

« on: October 08, 2011, 02:45:35 am »

I did an apt-get update, apt-get upgrade last night but I still do not have working mce_usb remote and receiver.

Do I need to apply your patch manually or should it have been applied to the latest build?

Insanity: doing the same thing over and over again and expecting different results.

I only asked you to have a look at the requirements for things to work and tell me if they're there so maybe people get a clue of what's wrong. I'm not involved deeply enough with LinuxMCE development (I don't even have a Core, I use Thom's from time to time), but even so the checklist embedded in the question should have found something missing so other people, who do LinuxMCE development, can go "aha! missing dependency" or something.

I didn't patch anything

77

Users / Re: Can't get MCE_USB remotes to work on 10.04 MDs

« on: October 03, 2011, 04:47:24 pm »

Uplink,

Core remote works fine.
MD's don't work at all.

The only difference is the MD's are windows transmitters, Core has a usbuirt

That difference is very important. USB-UIRT remotes don't use pluto-lirc-wrapper at all. See if package pluto-lirc-wrapper is installed. If it is, see if LIRC_DCE is running and if you have a lircd process as well. If they are running, execute irw on the MD, then press some keys on the remote. irw should display the keys you press. If this works, but the remote doesn't control the Orbiter, something's fishy. If anything in the checklist doesn't check out, let us know what.

78

Users / Re: Can't get MCE_USB remotes to work on 10.04 MDs

« on: October 01, 2011, 03:11:16 am »

I think lirc_mceusb2 got merged into lirc_mceusb, but LinuxMCE still expects it. If lirc_mceusb isn't loaded, then your remote won't work. I committed a two line patch that addresses this: http://trac.linuxmce.org/trac.cgi/changeset/24885 just now. I didn't test it though (except in Dianemo, where it works fine).

79

Users / Re: Anyone using or thinking of using the LeGrand BTicino Bus system?

« on: October 01, 2011, 02:55:53 am »

Unfortunately, the only page that does Bticino justice is in Italian: www.bticino.it and there's no language option as far as I can see.

80

Users / Re: OMG, why do you make this so difficult?

« on: August 21, 2011, 08:30:44 pm »

4. *My Main Point* Why not just tell people that you’re short on help and not to expect the install to work right the first time? Why not tell people to not click too quickly through the setup because background things are still going on?  Tell us to be patient.  Sorry, but the YouTube videos really set you up at a high standard.

I wonder how a "help needed" banner would work on the front page and some warnings on the installation pages, plus invitations to update the instructions if they don't match the experience (that's what collaboration in free software is about).

I used to be an IT guy (self taught) and now I’m a construction worker!  How do you like that?  In my 18 years in IT (ten years ago – economy here) I never ever responded as unprofessionally as golgoj4’s response even when a user was a jerk like me.  It’s bad PR for the project.  He has to realize that he’s part of the team and his behavior reflects on the entire project.  Sure, I was a *jerk*, but he outdid me by far.  When I do IT stuff (unpaid) for friends and even friends of friends, I don’t get upset when they are confused or even when they get upset.  Sure, I feel it all inside, but never express it to them.

I don't remember golgoj4 responding like this before, so I guess he waited for the right moment to do it. I guess you just got "lucky". Normally you'd get a similar kind of response from someone else but he's either not awake yet, or he is trying this new restrain in expression thing we're trying out.

Also, to not get in any "fuck you, fuck all of you and your pets" state of mind, I stopped helping friends and friends of friends in IT (unless they pay me quite a hefty sum, which they're not willing to). These days I can even genuinely tell them that I don't know Windows (I forgot it all - for real). I don't care if they don't call me anymore (because all the calls I received were about their computers anyway)


This being said, if you have the time and will to help, please have a look at the bits that annoy you and see if you see any quick fixes. Possy loves tickets in trac, so you should report your issues there (or contribute to already open tickets if they address your issues). Code and patches are always very welcome

81

Users / Re: OMG, why do you make this so difficult?

« on: August 21, 2011, 05:28:19 pm »

Your response is beyond the caliber I expected.  "Yet another crybaby" is a telling phrase that you should reexamine!  If there are this many "crybabies," maybe you're doing something wrong just as I suspected.

Your use of foul language in this situation shows your character too well!  I was civil, can't you be as well?  You’re not a very good representation of the other fine people who I know work hard.

I know that my post was born out of frustration and wasn’t as coherent as I might want, but it is clear that you didn’t take anything positive away from what I had to say.  You have to admit, in every complaint a person hears, there is a bit of useful information that can make a process/product/service better.  I’m sorry you couldn’t see that.

Again, I would like to participate to make the solution better, but with a mouth like your’s, who wants to?  You certainly shouldn’t be in the Marketing Department!

And, I do NOT think you work for me!  Thank God for that!

As soon as you put things in perspective and realise golgoj4 is a construction worker who took on writing qOrbiter without any programming background, I think you'll agree with me that he has the full right to say "fuck you" with plenty of exclamation marks to your face.

Yes, LMCE has some arcane ways of doing things. These have been added BECAUSE people wanted to make life easier for the users like you. Well, it backfired. Also, the people who worked on those bits disappeared into the void and LMCE doesn't have much help these days. If you don't like it AND you don't want to be patient and try to work things out, maybe help out a bit, then tough. I'm not saying this because I want to bash you. I'm saying this because this is reality. The things you want to be made easier for you lack staff. No amount of yelling, foot stumping and dropping on the floor screaming like a little kid will fix this. If you do this, the best thing that can happen is be left there until you cool down and realise your technique doesn't work. The worst thing that can happen is being kicked in the stomach while you're down. These days the LMCE developers have a tendency towards the latter, to relieve stress

82

Users / Re: Dianemo Orbiter 1.2 for iOS - now availabe free from the App store

« on: August 09, 2011, 07:11:22 pm »

What. No Android Love.

There's a guy working (very slowly) on a Android Orbiter. We don't have an Android Orbiter ourselves. Even for the iOS orbiter the hard work was done by someone else, and I only wrote some extra code on top

83

Users / Re: Diskless MDs not PXE booting

« on: August 01, 2011, 06:56:54 pm »

13. After it got an IP, it began the PXE boot.
14. After eth0 apparently came up, the Jetway reported it couldn't connect to the router, so it rebooted.
15.  60 minutes later, it's still rebooting because it can't find the router.

WTF.

Began the PXE boot in what way? Does it load the "default" PXE config file, then the kernel, then the initrd.img files or it doesn't get this far? If it doesn't get this far, check syslog on the Core and tell us what is says.

A normal default image boot log looks like this:

Code: [Select]

Aug  1 15:39:37 dcerouter dhcpd: DHCPDISCOVER from 08:00:27:51:34:0e via eth1
Aug  1 15:39:38 dcerouter dhcpd: DHCPOFFER on 192.168.80.129 to 08:00:27:51:34:0e via eth1
Aug  1 15:39:39 dcerouter dhcpd: DHCPREQUEST for 192.168.80.129 (192.168.80.1) from 08:00:27:51:34:0e via eth1
Aug  1 15:39:39 dcerouter dhcpd: DHCPACK on 192.168.80.129 to 08:00:27:51:34:0e via eth1
Aug  1 15:39:40 dcerouter in.tftpd[14552]: connect from 192.168.80.129 (192.168.80.129)
Aug  1 15:39:40 dcerouter atftpd[14552]: Advanced Trivial FTP server started (0.7)
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.0 to 192.168.80.129:2001
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/56424f58-0000-0000-0000-08002751340e to 192.168.80.129:49152
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/01-08-00-27-51-34-0e to 192.168.80.129:49153
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A85081 to 192.168.80.129:49154
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A8508 to 192.168.80.129:49155
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A850 to 192.168.80.129:49156
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A85 to 192.168.80.129:49157
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A8 to 192.168.80.129:49158
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0A to 192.168.80.129:49159
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C0 to 192.168.80.129:49160
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/C to 192.168.80.129:49161
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/pxelinux.cfg/default to 192.168.80.129:49162
Aug  1 15:39:40 dcerouter atftpd[14552]: Serving /tftpboot/default/vmlinuz to 192.168.80.129:49163
Aug  1 15:39:45 dcerouter atftpd[14552]: Serving /tftpboot/default/initrd to 192.168.80.129:49164
Aug  1 15:39:57 dcerouter dhcpd: DHCPDISCOVER from 08:00:27:51:34:0e via eth1
Aug  1 15:39:57 dcerouter dhcpd: DHCPOFFER on 192.168.80.129 to 08:00:27:51:34:0e via eth1
Aug  1 15:39:57 dcerouter dhcpd: DHCPREQUEST for 192.168.80.129 (192.168.80.1) from 08:00:27:51:34:0e via eth1
Aug  1 15:39:57 dcerouter dhcpd: DHCPACK on 192.168.80.129 to 08:00:27:51:34:0e via eth1

See where in the above sequence your boot process breaks down.

84

Users / Re: Diskless MDs not PXE booting

« on: July 29, 2011, 05:15:36 pm »

BTW, how can I tell if the diskless image is actually being created?  I looked on the core and can't find any running process that would indicate the MD's image is being created.

The script Diskless_Setup.sh creates the image. If that is running, the Diskless MD filesystems are being created. If you don't see it, it's not happening. It creates the /usr/pluto/diskless directory and MD subdirectory.

If this is not the case for you, here's how it all works:

1. New MD PXE boots default boot image.
2. Default boot image connects to the Core and tells it to create a new MD device.
3. Default boot image displays "announced ourselves to the router" and waits for messages from the Core.
4. Core creates a MD device (check your device tree)
5. Core allocates IP address to new MD, tells new MD about it (you get "Allocated permanent IP" message on MD).
6. Core runs Diskless_Setup.sh, tells new MD about it (you get "Running Diskless_Setup.sh" message on MD).
7. When Diskless_Setup.sh finishes, Core tells MD about it. If it fails, the MD will display "Diskless_Setup.sh failed" message. If it succeeds, you'll get a success message and the Core will also tell the MD to reboot.
8. MD reboots into its new filesystem.

At no point should Diskless_Setup.sh die without the MD getting a message (error or success).

If you don't have the MD device in your tree after the router announcement, you have a different problem. If you do have the device in the tree, and MD says Diskless_Setup is running, but you don't see Diskless_Setup on the core, run /usr/pluto/bin/Diskless_Setup.sh yourself on the Core and see what's happening.

85

Installation issues / Re: 2 tuner trouble

« on: July 28, 2011, 04:01:21 pm »

Hi Uplink,

Yes indeed the pvr150 exposes 3 devices, i thought Mythtv wasn't seeing this right (and already i have learned )
By digging in deeper what exactly do you mean, what steps can i make?
thanks a lot,

Br,
Raymond

Going down the udev route, you'll have to see if there are more parameters you can use to select the device for the symlink. Right now your rule matches all three devices, and it's the last one that gets the symlink. With a bit of luck, there's something that differentiates these three devices and udev use that information. I vaguely remember something called like "kernel parameters" (or something with "parameters" in its name) which would be different for each device and you can use it to narrow down the selection so the symlink points to the right device.

86

Users / Re: Diskless MDs not PXE booting

« on: July 28, 2011, 02:28:26 pm »

Hi,

Just curios but - what happens on the MD when you are trying to PXE boot?

Do you get a kernel panic, do you get we are announced to the router, at what point does the MD fail and what is the message?

Cheers.

He said it's not getting past the DHCPOFFER message in syslog, so I assume the MD says "Getting DHCP address" (or similar) with dots printed after it, possibly displaying a new dot once every 1-3 seconds. This is a PXE BIOS message. No Linux or boot loader has been loaded at this point.

87

Installation issues / Re: 2 tuner trouble

« on: July 28, 2011, 02:11:02 pm »

Uplink this is what i get:

Code: [Select]

lrwxrwxrwx 1 root root 7 2011-07-21 15:04 /dev/pvr150 -> video25
br,
Raymond

So it points to the wrong device. The pvr150 driver exposes three devices. Myth can only use the first one. You probably need to dig some more to see how to tell udev to make the symlink to the first device. I have a non-udev scripted solution somewhere in a long forgotten place (translation: I may not be able to find it) that updates MythTV settings at boot time base on concepts similar to the USB serial ports in LinuxMCE. I can't promise I'll find it, let alone help integrate it - time constraints and all.

88

Users / Re: Diskless MDs not PXE booting

« on: July 27, 2011, 06:57:10 pm »

One thing that did come to mind is this:

The DHCPOFFER message doesn't contain the parameters for PXE boot, so the machine is ignoring it. Not exactly sure how this could happen though.

But if you look in /etc/dhcp3/dhcpd.conf you should see a section that looks like this:

Code: [Select]

subnet 192.168.80.0 netmask 255.255.255.0 {
        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";
        option pxelinux.reboottime = 30;

        default-lease-time 86400;
        max-lease-time 604800;
        pool {
                 allow unknown-clients;
                 range 192.168.80.129 192.168.80.254;
        }
}

The important bit here is this:

Code: [Select]

        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";

If these two lines are missing, the PXE BIOS doesn't even bother to continue the negotiation and starts from the beginning. If they're not there it means someone decided to break PXE booting for some unknown reason.

89

Users / Re: Diskless MDs not PXE booting

« on: July 27, 2011, 06:39:58 pm »

First, whoever said "eth0 is supposed to be external", forget that idea and beat whoever put it in your head to begin with

Next, I always hate it when the DHCPOFFER reply seems to get lost on the network. I still don't have a pattern about how to fix this when it happens. Last thing I wanted to throw into a wall because of this was a SoundBridge (their forums said it was a hardware issue, so no hope for a fix in a firmware update).

m3freak: I'm pretty sure your core is OK. The problem is when negotiating DHCP. Could be as "simple" as what purps said. Could be something else altogether. If I can run a LiveCD on a machine that exhibits DHCPOFFER-ignorance, I run a LiveCD just to make damn sure I can get DHCP with the out of the box distro. If not, I look in /var/log/syslog on both the Core and the machine in question to match them up. I even go as far as to run tcpdump on the machine that won't take DHCPOFFER as an answer to see if the message comes in (at this point I also get all kinds of ideas that there might be a "third party" on the network messing things up).

Not an easy thing debugging this. And it's annoying too.

I only skimmed over the thread, but I think the Realtek you mentioned is in your core. Try to leave the driver swap for last. See what you have in the machine you want to use as an MD.

90

Installation issues / Re: Ultimate Goal of LinuxMCE

« on: July 27, 2011, 06:15:27 pm »

Kubuntu goes fine, but when I run the LinuxMCE script I get a 'no resume image, doing normal boot' and then it boots to a prompt.
No worries, the forum or the wiki will have the answer, and I'll learn a little Linux on the way. Again no dice. Other people have had the same error, but there seems to be no answers.

This is one of those lightbulb moments: Can you verify that things have really stopped? There are cases when things are just slow before X is started and you are left watching a login prompt which can make you think that's as far as you'll go. A thing that comes to mind that could slow things down this way is the lack of a Internet connection. Please login and paste a list of running processes in here. Use this command:

Code: [Select]

ps -axf to get the process tree. Ping google.com while you're there to confirm the Internet works too.

Why do I get the feeling I shouldn't assume you know how to redirect the output of a command to a file and paste it to a website?