Messages

1

Installation issues / Re: 810 Core, MD and Orbiters

« on: November 25, 2010, 05:01:33 am »

Still replying to my own thread

So- LinuxMCE isn't very stable in my environment; the Core crashes randomly, despite trying it on different hardware. The MD's take at least 40 minutes to boot (without editing the boot scripts heavily), and they don't boot cleanly all the time (takes multiple reboots to get it to start). Finally, the insteon integration, or at least the serial component, crashes randomly as well.

Does no one else have these problems with LinuxMCE? (At the risk of being banned) Are there no other options than Windows Media Center for just the content delivery (I don't want to go that way, but just for the reliability of media delivery, that's what I'm starting to lean towards due to my only customer in the house being not as tolerant as I am ).

I've managed to get a lot done with it, including integration with arduino's and dallas one wire devices to react to environment changes (generic serial keeps crashing).

Any idea's/help/pointers?

Please don't take this as "another user griping about the solution", but I've had this thread open for about 4 months now with no real progress. The snapshots ISO's haven't booted for me either for this time as well, even in VM.

I'll come clean, I've been given an ultimatum; get it working (mostly) or find something else

2

Installation issues / Re: 810 Core, MD and Orbiters

« on: November 05, 2010, 03:48:25 am »

I'm still not able to make much progress in this part. But I've since found that adding new devices (MD's as they turn on and off) kick this state with Generic_Serial. If I SIGHUP that process, Insteon comes back to life after going through the queue.

Strange...

3

Installation issues / Re: 810 Core, MD and Orbiters

« on: October 19, 2010, 04:09:23 pm »

SIGHUP again, but a new line number:

Error while calling method: Cannot call class method: cmd_350
error: SIGHUP, line: 1524
backtrace:
   in: (eval): 1524
   from (eval):1524:in `plmparse'
   from (eval):34:in `cmd_350'
   from (eval):1529
 <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>
01   10/19/10 10:05:49.302      For obscure reasons could not handle the message <0xb4f32b90>


I'm going to check the Ruby code now to see where it may be failing. I do have TED devices which may be interfering by sending signals that are picked up by the Insteon device and then sending them to the Generic_Serial script.

4

Installation issues / Re: 810 Core, MD and Orbiters

« on: October 18, 2010, 11:30:50 pm »

Update-

through messing with it, if I SIGHUP the process, things come back to life after watching the log and the message queue seems to begin to update. I've killed, rebooted, etc now multiple times a day eventually having to soft reboot the core, and then rebooting the core. It's always this process that keeps hanging up:

/usr/pluto/bin/Generic_Serial_Device -d 125 -r localhost -l /var/log/pluto/125_Generic_Serial_Device.log

I've read the wiki regarding Generic_Serial_Device, and am unable to determine what would be causing it to go into a CPU loop like it appears to be doing at random.

Still looking into it.

I should note that to get the USB serial adapter to be recognized in the 810 beta, I had to run the serial hack here: http://wiki.linuxmce.org/index.php/Serial_Hack



Below is the latest output from the log. I see that the process queue increases. Now to try to find what is causing the hangup and the eventual increase:

Last Successful Command:
***):out:02 62 14 10 BE 0F 10 00 Length:8
(***):IN:00 62 14 10 BE 0F 10 00 Length:8
05   10/18/10 18:08:48.588      GSDMessageTranslator isCmdImplemented = false <0xb577db90>
05   10/18/10 18:08:48.639      #### Pre-Process Queue = 1 <0xb577db90>
05   10/18/10 18:08:48.639      _QueueProc Pre - 193 : 0 <0xb6f80b90>
05   10/18/10 18:08:48.639      GSD-Sleep Pre 193 : 0 <0xb6f80b90>
05   10/18/10 18:08:48.639      Process Queue = 1 <0xb6f80b90>
01   10/18/10 18:09:06.003      Ruby was unable to handle the command in reasonable amount of time <0xb6f80b90>
05   10/18/10 18:09:06.003      GSD-Sleep Post 193 : 0 <0xb6f80b90>
05   10/18/10 18:09:06.003      _QueueProc Post - 193 : 0 <0xb6f80b90>
05   10/18/10 18:16:22.068      GSDMessageTranslator isCmdImplemented = false <0xb577db90>

Here's where it begins to fill
05   10/18/10 18:16:22.098      #### Pre-Process Queue = 1 <0xb577db90>
05   10/18/10 18:16:22.099      GSDMessageTranslator isCmdImplemented = false <0xb577db90>
05   10/18/10 18:16:22.105      #### Pre-Process Queue = 2 <0xb577db90>
05   10/18/10 18:16:22.110      _QueueProc Pre - 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:22.110      GSD-Sleep Pre 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:22.110      Process Queue = 2 <0xb6f80b90>
01   10/18/10 18:16:40.006      Ruby was unable to handle the command in reasonable amount of time <0xb6f80b90>
05   10/18/10 18:16:40.006      GSD-Sleep Post 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:40.006      _QueueProc Post - 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:40.006      _QueueProc Pre - 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:40.006      GSD-Sleep Pre 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:40.006      Process Queue = 3 <0xb6f80b90>
01   10/18/10 18:16:58.003      Ruby was unable to handle the command in reasonable amount of time <0xb6f80b90>
05   10/18/10 18:16:58.003      GSD-Sleep Post 192 : 0 <0xb6f80b90>
05   10/18/10 18:16:58.003      _QueueProc Post - 192 : 0 <0xb6f80b90>
05   10/18/10 18:29:31.498      GSDMessageTranslator isCmdImplemented = false <0xb577db90>
05   10/18/10 18:29:31.530      #### Pre-Process Queue = 1 <0xb577db90>
05   10/18/10 18:29:31.531      _QueueProc Pre - 193 : 0 <0xb6f80b90>
05   10/18/10 18:29:31.531      GSD-Sleep Pre 193 : 0 <0xb6f80b90>
05   10/18/10 18:29:31.531      Process Queue = 4 <0xb6f80b90>
01   10/18/10 18:29:49.003      Ruby was unable to handle the command in reasonable amount of time <0xb6f80b90>
05   10/18/10 18:29:49.003      GSD-Sleep Post 193 : 0 <0xb6f80b90>
05   10/18/10 18:29:49.003      _QueueProc Post - 193 : 0 <0xb6f80b90>
05   10/18/10 18:31:41.474      GSDMessageTranslator isCmdImplemented = false <0xb577db90>
05   10/18/10 18:31:41.497      #### Pre-Process Queue = 1 <0xb577db90>
05   10/18/10 18:31:41.524      _QueueProc Pre - 193 : 0 <0xb6f80b90>
05   10/18/10 18:31:41.524      GSD-Sleep Pre 193 : 0 <0xb6f80b90>
05   10/18/10 18:31:41.524      Process Queue = 5 <0xb6f80b90>
01   10/18/10 18:31:59.006      Ruby was unable to handle the command in reasonable amount of time <0xb6f80b90>
05   10/18/10 18:31:59.006      GSD-Sleep Post 193 : 0 <0xb6f80b90>
05   10/18/10 18:31:59.006      _QueueProc Post - 193 : 0 <0xb6f80b90>

I SIGHUP
01   10/18/10 18:32:03.032      Error while calling method: Cannot call class method: cmd_350
error: SIGHUP, line: 1529
backtrace:
   in: (eval): 1529
   from (eval):1529:in `plmparse'
   from (eval):34:in `cmd_350'
 <0xb4f32b90>
01   10/18/10 18:32:03.154      For obscure reasons could not handle the message <0xb4f32b90>
01   10/18/10 18:32:03.155      For obscure reasons could not handle the message <0xb4f32b90>
01   10/18/10 18:32:03.155      For obscure reasons could not handle the message <0xb4f32b90>
01   10/18/10 18:32:03.155      For obscure reasons could not handle the message <0xb4f32b90>
01   10/18/10 18:32:03.155      For obscure reasons could not handle the message <0xb4f32b90>

And things start working again

5

Installation issues / Re: 810 Core, MD and Orbiters

« on: October 13, 2010, 03:06:08 am »

When I sighup the process and soft reboot the core, everything comes back but for an unspecific amount of time (could be 30 minutes, could be 10 hours). Same effect in that all insteon devices quit working and the same errors are at hand.

6

Installation issues / Re: 810 Core, MD and Orbiters

« on: October 12, 2010, 01:25:30 pm »

Thom,

Thanks- I'll wait for it then.

As of this morning, the Generic_Serial process has gone a-wall again, and Insteon doesn't work.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                        
24145 root      20   0 62520 7896 4320 S  109  0.2 967:52.08 Generic_Serial_

root     20590  0.0  0.0   3000   988 ?        Ss   Oct11   0:00 /usr/bin/SCREEN -d -m -S Insteon_PLM125 /usr/pluto/bin/Spawn_Device.sh 125 localhost Generic_Serial_Device
root     20592  0.0  0.0   2876  1444 pts/18   Ss+  Oct11   0:00 /bin/bash /usr/pluto/bin/Spawn_Device.sh 125 localhost Generic_Serial_Device
root     24145  109  0.2  62520  7896 pts/18   Sl+  Oct11 969:52 /usr/pluto/bin/Generic_Serial_Device -d 125 -r localhost -l /var/log/pluto/125_Generic_Serial_Device.log

From /var/log/pluto/125_Generic_Serial_Device.log
(***):Database Delta=00
(***):Configuration is:00
(***):From:127
(***):current State:0
(***):Wanted State:0
(***):ReportStatus: device:127 Status:0
(***):SndIns:Queue:7
(***):out:02 62 11 BE 54 0F 19 00 Length:8
(***):IN:02 62 11 BE 54 0F 19 00 06 Length:9
(***):IN:02 50 11 BE 54 13 20 30 27 00 00 Length:11
(***):Command Completed.
(***):Processing 0x19 Status Report
(***):Database Delta=00
(***):Configuration is:**
(***):Databse CHANGED -getting remote database
(***):Setting Database Config
(***):SndIns:Queue:15
(***):out:02 62 13 28 DD 0F 19 00 Length:8
(***):IN:02 62 13 28 DD 0F 19 00 06 Length:9
(***):IN:02 50 13 28 DD 13 20 30 2B 00 00 Length:11
(***):Command Completed.
(***):Processing 0x19 Status Report
(***):Database Delta=00
(***):Configuration is:00
(***):From:128
(***):current State:0
(***):Wanted State:0
(***):ReportStatus: device:128 Status:0
(***):SndIns:Queue:14
(***):out:02 62 14 5E 9E 0F 10 00 Length:8
(***):IN:02 62 14 5E 9E 0F 10 00 06 Length:9
(***):Got PING ACK
(***):receive timeout=1
(***):receive timeout=2
(***):receive timeout=3
(***):Command Stalled!  resetting and retrying
(***):Current Command:1
(***):SndIns:Queue:14
(***):out:02 62 14 5E 9E 0F 10 00 Length:8
(***):IN:02 62 14 5E 9E 0F 10 00 06 Length:9
(***):Got PING ACK
(***):receive timeout=1
(***):receive timeout=2
(***):receive timeout=3
(***):Command Stalled!  resetting and retrying
(***):Current Command:1
(***):SndIns:Queue:14
(***):out:02 62 14 5E 9E 0F 10 00 Length:8
(***):IN:02 62 14 5E 9E 0F 10 00 06 Length:9
(***):Got PING ACK
(***):receive timeout=1
(***):receive timeout=2
(***):receive timeout=3
(***):Third attempt, Failing Command!
(***):Command Completed.
(***):SndIns:Queue:13
(***):out:02 62 11 CE A9 0F 10 00 Length:8
(***):IN:02 62 11 CE A9 0F 10 00 06 Length:9
(***):Got PING ACK
(***):receive timeout=1
(***):receive timeout=2
(***):receive timeout=3
(***):Command Stalled!  resetting and retrying
(***):Current Command:1
(***):SndIns:Queue:13
(***):out:02 62 11 CE A9 0F 10 00 Length:8
(***):IN:02 62 11 CE A9 0F 10 00 06 Length:9
(***):Got PING ACK
(***):IN:FE F8 FE Length:3
(***):ERROR IN PLMPARSE- Unknown Command
(***):DEBUG:FE F8 FE Length:3
(***):IN:FE Length:1
(***):IN:FE FE F8 FE Length:4
(***):ERROR IN PLMPARSE- Unknown Command
(***):DEBUG:FE FE F8 FE Length:4
(***):receive timeout=1
(***):receive timeout=2
(***):receive timeout=3
(***):Command Stalled!  resetting and retrying
(***):Current Command:1
(***):SndIns:Queue:13
(***):out:02 62 11 CE A9 0F 10 00 Length:8
(***):IN:02 62 11 CE A9 0F 10 Length:7
05   10/11/10 16:48:03.812      GSDMessageTranslator isCmdImplemented = false <0xb57d1b90>
05   10/11/10 16:48:03.856      #### Pre-Process Queue = 1 <0xb57d1b90>
05   10/11/10 16:48:03.856      _QueueProc Pre - 193 : 0 <0xb6fd4b90>
05   10/11/10 16:48:03.856      GSD-Sleep Pre 193 : 0 <0xb6fd4b90>
05   10/11/10 16:48:03.856      Process Queue = 1 <0xb6fd4b90>
01   10/11/10 16:48:21.004      Ruby was unable to handle the command in reasonable amount of time <0xb6fd4b90>
05   10/11/10 16:48:21.004      GSD-Sleep Post 193 : 0 <0xb6fd4b90>
05   10/11/10 16:48:21.004      _QueueProc Post - 193 : 0 <0xb6fd4b90>
05   10/11/10 16:48:34.713      GSDMessageTranslator isCmdImplemented = false <0xb57d1b90>
05   10/11/10 16:48:34.718      #### Pre-Process Queue = 1 <0xb57d1b90>
05   10/11/10 16:48:34.725      _QueueProc Pre - 192 : 0 <0xb6fd4b90>
05   10/11/10 16:48:34.725      GSD-Sleep Pre 192 : 0 <0xb6fd4b90>
05   10/11/10 16:48:34.725      Process Queue = 2 <0xb6fd4b90>
01   10/11/10 16:48:52.004      Ruby was unable to handle the command in reasonable amount of time <0xb6fd4b90>
05   10/11/10 16:48:52.004      GSD-Sleep Post 192 : 0 <0xb6fd4b90>
05   10/11/10 16:48:52.004      _QueueProc Post - 192 : 0 <0xb6fd4b90>
05   10/11/10 16:50:35.950      Got a reload command from 0  <0xb57d1b90>

7

Installation issues / Re: 810 Core, MD and Orbiters

« on: October 11, 2010, 09:27:09 pm »

Okie dokie- been running with this for a little while longer now. I wanted to post an update to some of the thing's I've managed to fix and others that are still odd.

(solved) Question #1
I solved by commenting out:

#chmod -R 2770 "$BaseDir"/user_* 2>/dev/null
#chmod -R 2775 "$BaseDir"/public 2>/dev/null
#chgrp -R public "$BaseDir"/public

in

/usr/pluto/bin/SetupUsers_Homes.sh

By having those three lines, the boot process for each media director will take more than an hour, and the permissions are already set correctly. For those that are more familiar with the system, any reason why I shouldn't be doing this? I haven't noticed any side effects (yet).

(resolved) Question #2
Was stemmed from performance issues with PXE booting, and those three lines.

(solved/resolved) Question #3
I figured out what was happening- the known bug of a tmp file not being created. Since then, I've wrapped the startup of the program for the n900 in a script to create the file and then start the app. Kinda ghetto. Does anyone have a dev environment for the n900 setup whereby this file requirement can be fixed in source?

(unsolved) Question #3a hence moved to Question #4
I've got a Windows XP Tablet, tried installing the tablet software, it keeps saying "the installation package could not be opened. contact the application vendor to verify that this is a valid windows installer package." Anyone else run into this?

(new) Question 5
I have my Insteon HA stuff mostly integrated... I'm still working on figuring out how to add the motion detectors from Insteon in a way that will trigger events within LinuxMCE. Anyone else have experience in integrating the Insteon motion detectors?

(new) Question 6
root      5313  106  0.2  63136  7584 pts/17   Sl+  11:47 217:22 /usr/pluto/bin/Generic_Serial_Device -d 125 -r localhost -l /var/log/pluto/125_Generic_Serial_Device.log

This process is pegging my CPU at 100% utilization, which is subsequently killing the core. Here is an excerpt from that log file:
05   10/11/10 12:36:39.004      Process Queue = 3 <0xb6f67b90>
01   10/11/10 12:36:57.004      Ruby was unable to handle the command in reasonable amount of time <0xb6f67b90>
05   10/11/10 12:36:57.004      GSD-Sleep Post 193 : 0 <0xb6f67b90>
05   10/11/10 12:36:57.005      _QueueProc Post - 193 : 0 <0xb6f67b90>
05   10/11/10 12:36:57.005      _QueueProc Pre - 193 : 0 <0xb6f67b90>
05   10/11/10 12:36:57.005      GSD-Sleep Pre 193 : 0 <0xb6f67b90>
05   10/11/10 12:36:57.005      Process Queue = 4 <0xb6f67b90>
01   10/11/10 12:37:15.007      Ruby was unable to handle the command in reasonable amount of time <0xb6f67b90>
05   10/11/10 12:37:15.007      GSD-Sleep Post 193 : 0 <0xb6f67b90>
05   10/11/10 12:37:15.007      _QueueProc Post - 193 : 0 <0xb6f67b90>

While it is in this state, the Insteon system in unresponsive within LinuxMCE.

(new) Question #7
I have a hefty zoneminder installation already running here. I tried adding the mjpeg streams into LinuxMCE, and it could not detect them at all. Also, when I had the camera's added, my Insteon system became unresponsive within LinuxMCE.

That's it for now. Some other stuff that I had fixed along the way:

MediaDirector HDMI Video
In order to get video out over the HDMI port, the addition to the "Monitor" section below is required:

Section "Monitor"
   ...
        Option "ConnectedMonitor" "DFP-1"
   ...
EndSection

In addition the specification of "BusID" within the "Device" section was absolutely necessary. I my case it was
Section "Device"
   ...
        BusID      "PCI:3:0:0"
   ...
EndSection

I'm still working out audio over HDMI...

At the moment, I'm more concerned over question #6, as it is impacting the usability of the system and has a negative cascading performance effect overall.

Thanks all!

8

Installation issues / Re: 810 Core, MD and Orbiters

« on: August 12, 2010, 01:06:24 pm »

posde,

thanks!

Re #1
===
Does it matter if the MD's hard drives are partitioned and formatted? The reason why I ask is that these are brand new OEM unformatted hard drives. I could try disabling them and seeing if there is an improvement then.


Re #3
===
The firewall is disabled, and they still cannot connect. But since you mentioned that this should work anyways, I'll do some sniffing to see if there is something on my end that is blocking it.

9

Installation issues / 810 Core, MD and Orbiters

« on: August 12, 2010, 01:55:27 am »

Howdy all,

first, I'd like to thank all the developers for working very hard on a great project; I've been a lurker for a while and I'm ready to take the plunge.

I've installed the 810 beta2 core on a system, and that's working fine. Since I already have an extensive and (overly) complicated LAN installed (wireless DMZ, lan, wan DMZ, OSPF, dual ISP, oh my), I've put the WAN of the core into my LAN, and the Core's LAN is going to be only for the MD's (I already have Asterisk, zoneminder and other systems running elsewhere). I've disabled the firewall to attempt to make things easier with LinuxMCE as I'm learning it. I've developed some questions and have some experiences to share.

Question #1:
As stated before, the core is chugging along. But my MD's PXE boot from the core on their own VLAN, but it takes over 40 minutes to boot into the configuration screen, and that in itself is very laggy in response. I've since moved the Core's LAN onto its own dedicated gig-e switch and ran iperf across the interfaces; the speeds are more than acceptable (even within the VLAN). I can't explain why it takes so long to load, and then never boot the MD's interface after configuration. The interface just hangs there, though I can SSH into the MD's and interact with them very well. The MD's are all the same system: http://www.newegg.com/Product/Product.aspx?Item=N82E16813500037 with 2 Gig's RAM and 80 Gig HD's.

Question #2:
Lurking on the forum and observing other's posts, I can't determine if there is a way to boot the MD's right from the HD's. I have small and fast drives in the MD's at my disposal. Is there a process to not have to PXE boot and just load the MD's software from the system's HD? (Maybe through the use of just "dd'ing" the booted image to the first drive?

Question #3:
Since I already have a wireless dmz, and I'm aware of the architecture of "put everything behind LinuxMCE," and hopefully ya'll understand that this isn't simply possible for me, is there a way to run the orbiters off of the WAN interface? I've tried connecting a Nokia n900, and it's not able to connect.

Question #3-subset-a-mark-1:
I've got a Windows XP Tablet, tried installing the tablet software, it keeps saying "the installation package could not be opened. contact the application vendor to verify that this is a valid windows installer package."


I'm really excited to try and get this going; I'm just running into some hiccups and don't know how much of them are due to my own unique situation and have solutions, and how many may be due to the beta.

I've tried downloading and installing the LinuxMCE-8.10-23233-i386.iso snapshot, but it wont boot using a USB drive, DVD or in VM. I'm downloading the previous snapshot to try that.

Thanks all- and I look forward to your suggestions!