purpse,

where do you get 1,5m accuracy with GPS using civil equipment? I rarely get the 15m

My HTC Wildfire seems to hit me right on the head each time... while outside... in an open parking lot. Well... it hit me right on the head in London, ducked behind tall buildings too. And while moving at 100 km/h by train. I must have the military version

The init script will see the START_LIRCD="false" and do nothing.

There are a few things to check:

* is LIRC_DCE running?
* if LIRC_DCE is running, check the logs for these messages:

Code:

Added remote %s device %d layout %c

and

Code:

There are no remote controls -- LIRC will be dormant

If you see the second message, you don't have a remote control setup in lmce-admin. You'll need to set one up. Normally, with a device of the "mce_usb2" template you also get a sibling device of the "Windows XP MC Remote" template.

When LIRC_DCE logs "Added remote", it found one of these sibling devices.

* if LIRC_DCE isn't running, you need to find out why: do you have a mce_usb2 device?, is the "Disabled" box unticked for the device?

Notice that, unless things were changed since I last looked in LinuxMCE, you still have to select "mce_usb2" device (i.e. not "mce_usb", nor the "mce_usb2 (MS)"). LIRC merged mceusb and mceusb2 back into a single driver (which my patch addresses), but LinuxMCE still knows about the old, split, drivers.

Please make sure you comment out the LogLevels line in /etc/pluto.conf so you get verbose logging. You need to reload the router after you make this change.

LIRC_DCE is supposed to write /etc/lirc/lircd.conf and start lirc, not Ubuntu. In Dianemo, hardware.conf isn't touched at all, so Ubuntu doesn't start lirc during its boot process. This should be the same in LinuxMCE.

Sound like either you haven't selected the mceusb2 remote for your MD (Media Directors page in the admin website) or LIRC_DCE didn't execute even once to create /etc/lirc/lircd.conf - that's why irw doesn't display anything. Check /etc/lirc/lircd.conf to see what's in it.

This being LinuxMCE, there's also a chance the system should have created the mceusb2 device using PnP, but do check.

I think maybe I am insane! Or maybe its you as this post says you committed a patch that should fix the problem.

Well... I did commit that patch, but I have no idea if it was packaged or not You can check to see if the "mceusb" module is loaded or not using "lsmod". Tha module is needed for things to work too, in addition to the things I ask to be checked. If it wasn't packages, then you may have to apply the patch yourself.

Sorry if I came out a bit strong with the insanity quote, I'm not in my best of moods these days. I'm still working on my "don't try to help people if your brain is on hold" idea

no lircd on mds and no command irw. there is an inputlircd process running as well as LIRC_DCE

'pluto-lirc-wrapper' (contains LIRC_DCE) depends on 'lirc-pluto', which depends on 'lirc' among other things.

irw is in package 'lirc'.

If you have LIRC_DCE running, 'pluto-lirc-wrapper' is probably installed. So where's 'lirc'...?

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

[irw]

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.

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).

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.

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

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

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

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:

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.

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.