bblboy54

okay, sorry bro... let me re-read everything in this thread thus far, and stir it around in my brain a bit.

Thanks I really am trying to help the best that I can..... I could just reload but I saw a couple other posts about this same issue and I'd really like to help find a solution and give back to the community -- I just don't have coding experience

I'm not sure if those are related because I think the rpcbind has to do with NFS and I think discovery.py is complaining about bind/named.... I could be way off base as well but I thought I'd post this in case it jogged someone's mind. I'm going to keep looking around to see if I can figure out anything else.

As you have changed the default internal network to a different ip range, and bind is incorporated into the system to provide services to the internal network provided by LMCE, it is possible that the bind configuration file needs to be updated to the modified internal IP. There are several places that are hardcoded with 192.168.80.x network address, it could be as simple as changing that file.

I am not sure where it is, and I am away from my system, so I can not look. Some places of interest:

a.) mysql server config = /etc/mysql/my.cnf (this could be in etc, but pluto does utilize its own directory structure for some things)b.) For mysql mythtv, and pluto db information, there probably has to be a GRANT ALL bit run on the new internal network ip.c.) NFS shares in /etc/exports are probably still set to 192.168.80.0/255.255.255.0d.) Samba config files are also probably still referencing the 192.168.80.x networke.) Apparently bind is also hard set in /etc/named.conff.) There can also be a future mythtv issue, check the /etc/mythtv/mysql.txt files (they could be many places, use 'find'g.) There is probably some changes needing made also to the dhcp server settings as well

I understand this is circumventing the "recommended" settings. And I would never try it myself, but rather than scream "Infidel" at everything, which I know doesn't always happen, perhaps someone who knows the system better than myself can chime in, as to all the places the internal network is configured to the system.

Regards, and Best Wishes,

Seth

Logged

".....Because Once you've LinuxMCE'd....."System stats located at my user page:

I am interested to find out what binds us to the .80.x networks as well. I wouldn't have been so hesitant to start playing if it weren't for that requirement, but I came up with my own solution that works quite well for me. I simply picked up a cheap router, loaded dd-wrt firmware to it and setup a VLAN for LMCE to run on where it is seperate the rest of my network. This lets me cut holes across so the two networks can talk when I want them to, but not interfere with my existing IP schema

Logged

bblboy54

a.) mysql server config = /etc/mysql/my.cnf (this could be in etc, but pluto does utilize its own directory structure for some things)b.) For mysql mythtv, and pluto db information, there probably has to be a GRANT ALL bit run on the new internal network ip.c.) NFS shares in /etc/exports are probably still set to 192.168.80.0/255.255.255.0d.) Samba config files are also probably still referencing the 192.168.80.x networke.) Apparently bind is also hard set in /etc/named.conff.) There can also be a future mythtv issue, check the /etc/mythtv/mysql.txt files (they could be many places, use 'find'g.) There is probably some changes needing made also to the dhcp server settings as well

All of the places you listed above actually do have the correct 192.168.5.xxx addresses so it seems that the configuration utility set everything up properly. I didn't check the databases themselves, however, as I'm really not sure of the best way to do that. Also, for reference, the mythbackend process is still running fine. I can access mythweb and see that it is actually recording the shows that I have scheduled..... it has the screen shots of the shows as well. If mysql was really broken, I wouldn't think that myth would be able to function as well.

Logged

bblboy54

root@dcerouter:/usr/pluto/bin# ./DCERouter Copyright (C) 2004 Pluto, Inc., a Florida Corporationwww.plutohome.comPhone: +1 (877) 758-8648This program is distributed according to the terms of the Pluto Public License, available at: http://plutohome.com/index.php?section=public_license This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the Pluto Public License for more details.---------------

bblboy54

Since it appears that the segfault is happening directly after it has a problem with the mythtv plugin is it possible to disable that plugin on startup for troubleshooting purposes? Basically if I can tell it not to load the myth plugin and everthing works then we know that it has something to do with that plugin specifically.

The same thing still is happening tho. I checked the disabled box and save, did a quick reload, and then rebooted the core to be sure and I'm still getting the seg fault after MythTV_PlugIn. If the DCERouter process isn't running, is it possible that configuration changes from the web admin aren't really changed?