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

Pages: 1 ... 58 59 [60] 61 62 63
Installation issues / Re: beta-problem with MD
« on: October 19, 2009, 07:29:03 pm »
did you also check this
Code: [Select]
: ?
to go back, you'd have to do some major work....I tried that one before last Friday and it didn't really work out...that was exactly the reason, why I did try the DVD.

I have read that.  Looks like the removal would introduce other problems.


Installation issues / Re: beta-problem with MD
« on: October 19, 2009, 06:26:46 pm »
Essentially you proposal would mean to probably reinstall the whole core and change the sources there, which might have further implications, because I assume the developers thought about something, when they included the avenard repo testing...from there you will also get the latest nvidia-drivers. As I also saw there are some problems with nvidia-180-glx, which is also broken.
As far as I understand, currently there is no easy solution for this...except if you switch from mythtv to vdr, perhaps.

I believe the 'testing' repository was added to the DVD install before the avenard repository changed to 0.22-fixes.  I could be wrong but I hadn't heard anything about support for 0.22 within LMCE0810.  See:

The nvidia-180-glx package is also from the avenard repository and has also undergone changes in the last few days.  A checkout using the 'release' repo from avenard repo does work.  Individuals requiring vdpau will have to manually install libvdpau0.  See:


Installation issues / Re: beta-problem with MD
« on: October 19, 2009, 05:48:57 pm »
I'm taking a stab in the dark here but if your having the mythtv installation problems can you check your /etc/apt/sources.list file.  Specifically the avenard repo.  

3 or 4 days ago the avenard repository changed and the 'testing' repository is now tracking myth 0.22 fixes rather than myth 0.21 fixes as it had been.  This could be causing a dependency problem on your installation.

Try remove 'testing' from the avenard repo line, if it exists, and be sure you leave 'release' (which is still tracking the 0.21 fixes).

Alpha 2.37 does not appear to have the avenard repo enabled at all.  I installed Alpha 2.37 2 days ago and did not experience this issue and the avenard repo was not enabled by default.  Try removing the 'testing' repo from you sources.list before bailing on the dvd install.


Installation issues / Re: beta-problem with MD
« on: October 19, 2009, 01:43:31 pm »
For those having MD creation issues following a DVD Beta install, have you read:

You need to create the initial MD image by running the script: /usr/pluto/bin/ before any MDs can be created.


Installation issues / Re: network problems on new 8.10 beta
« on: October 17, 2009, 11:17:44 pm »
Congratulations.  It's a complex system but the wiki and the forums are full of good information.  Have Fun!

Installation issues / Re: network problems on new 8.10 beta
« on: October 17, 2009, 05:11:22 pm »
I then tried a fresh install after I disabled the onboard NIC, using a very common Intel pro/100 PCI nic.
I tried all the same with an Intel Pro/1000MT as well.

As colinjones said, you need two (2) NIC cards for a hybrid/core system.  Make sure the onboard NIC is re-enabled and leave the Intel card in the system as well.


So I will report back once we've done our tests.

All the best


Wow.  Thanks Andrew, it looks like a great machine if the touch interface is supported.


Installation issues / Re: Resolved - This orbiter will be closed message.
« on: October 07, 2009, 01:04:50 am »
phenigma, Did you figure out how to get the update or when the fix will be available?  I asked Thom also but I don't think he's online and I have the same problem too and I'm fully updated also.

If you have a build environment set up you could try to build the package and install it on your core using dpkg.  Otherwise... I imagine it'll be in the next alpha build.


Installation issues / Re: Resolved - This orbiter will be closed message.
« on: October 05, 2009, 10:51:55 pm »
I can confirm that this is still happening on Alpha 2.36.

Thom, the issue with m_bMediaRunning not being set false, unless the core is running (,) still exists.  Nothing in SVN has changed which would rectify the issue.  I don't have a build environment yet so I can not provide a direct patch.  I intend to get on irc and request some assistance with the build environment but I've been away and havn't had a chance yet.

I believe that adding the line:

Code: [Select]
        m_bMediaRunning = false;

to LM::LM() in LM.cpp [line 70-83] will fix the problem.


Users / Re: 810 Setup core to boot into KDE
« on: September 21, 2009, 08:04:17 pm »
Ahh, I see what you're saying.  It read it a little differently I guess, it sounded to me like he wants to run a dedicated core with a KDE desktop.  (core server but no media director functionality).

The functionality for this exists in the LMCE_Launch_Manager code (I havn't tested it myself).  LMCE_Launch_Manager seems to be erroneously loading an extra orbiter (for many) which could defeat the ability to disable the MD functionality.


Users / Re: 810 Setup core to boot into KDE
« on: September 21, 2009, 04:08:36 pm »
However it still loads the Orbiter aswell as KDE at the same time.
I want it to start KDE only so i can use firefox to access lmce admin website. Since the Launcher no longer exists in 810

It sounds like you have KDE loading at boot just fine.  The fact that orbiter is still loading may be another issue...  many people are experiencing a second orbiter loading erroneously on boot right now.  It is possible that your machine is also erroneously loading orbiter.  You may find that when this issue is fixed it may also fix your problem.


Users / Re: thezfunk LinuxMCE Project build
« on: September 21, 2009, 05:01:09 am »
The second try with a working Core WAN NIC went slightly better.  Wound up at a Failed to Start X error.  No problem, dove into the wiki here:  Down at the bottom is says to set your xorg.conf to 'vesa' from 'nv'.  Much easier said than done.

Logging into the MD left me at a prompt as the sambahelper user.  That's where I am stuck.  Every time I try doing anything it says I don't have permissions and every time I try logging in as root...I don't know the password and the one I have on the core doesn't seem to work.  I even managed to get into vim and fumble around enough to change 'nv' to 'vesa' but I couldn't save.  Permissions forbade me.  Some prodding or help is politely asked for from the community.

PS...according to the wiki the default password for sambahelper is nothing or just hit enter.  Says I have the wrong password when I try that.

I had a similar issue on my Zotac 330 Ion.  I couldn't use sudo on the MD because sambahelper told me I had the wrong password.  To get around this I had to set an actual root password for the MD. 

When you log into the MD your prompt should tell you what moon# the MD is... remember the number.

On the core/hybrid you need to open a terminal in KDE or press Ctrl-Alt-F1 to get tty1.  Login with your username and password.  Then to become superuser type:

Code: [Select]
$ sudo su -
and enter your password.  Change directory to /usr/pluto/diskless and chroot into the MDs structure.  Once you have done this you can change the root password for the MD with the passwd command.

Code: [Select]
# cd /usr/pluto/diskless
# chroot XX   <-- replace XX with the moon number (device number) of your MD.
# passwd
Enter new UNIX password:

Enter the root password for the MD and then exit the chroot environment and give up superuser by typing 'exit' twice.

Code: [Select]
# exit
# exit

Now you can login as root on the MD with the password that you just set and you will be able to edit your xorg.conf file.


Installation issues / Re: Double orbiter and other strange things - Try this
« on: September 21, 2009, 04:33:08 am »
Sorry about your back man.  I recommend whiskey ... and a good Chiropractor.

The 0710 launch manager ran in X, is that the Qt4 app you're referring to that was ported to the current LMCE_Launch_Manager?  I'm learning...


Installation issues / Re: Double orbiter and other strange things - Try this
« on: September 21, 2009, 01:42:30 am »
Your welcome Thom.  This is an extremely complex system and I am very grateful for all the work everyone has put it in.  I'm glad I can contribute, even if it is just a little.

I've spent much of my day wrapping my head around LMCE_Launch_Manager (LM) and decided to try a few things out.  Because I don't have a dev environment set up I am really unable to do much with LM, except stare at the source incessantly.  So I noticed that there was a lot of logging within the source that doesn't end up in a log.  I also noticed that *some* extra logging shows when you run LM from a console.  So I commented out LM in the boot scripts and logged in on tty1 and ran LM there while capturing output...  Still not all the logging showing but some extra.  The first portion of the log is here:

Code: [Select]
Opening DB connection..
Checking if core is up...
Requested respawning of new children devices
Spawning new children devices - media
Starting device 21 OnScreen Orbiter
Error when querying device status
Finished spawning new children devices - media
Finished respawning of new children devices
>>Performing autostart if configured..
>>Autostarting core....
Starting process /usr/pluto/bin/
... continues...

The line "Running" through to "Finished respawning of new children devices" show that the functions LM::updateScripts and LM::respawnNewChildren are called.  This is happening before the LM::doAutoStart function is called and is the premature execution of orbiter.

There are 2 places in code this looks like it could happen:
1) a call to LMdeviceKeepAlive() <-- this seems rather unlikely given that DCERouter is not running to have sent this msg yet
2) either m_bCoreRunning OR m_bMediaRunning are true in the middle of LM::Initialize

Because LM::respawnNewChildren logs that it's calling LM::startMediaDevices it stands to reason that m_bMediaRunning is TRUE in LM::Initialize (supports #2 above).  As well, because the logs do not show LM::startCoreDevices being called it seems reasonable to assume that m_bCoreRunning is FALSE (especially since the autostart core routines seem to run after LM::respawnNewChildren), **edit: it's also the only way that m_bMediaRunning wouldn't have an opportunity to be set false...

So... My hypothesis at the moment is that m_bMediaRunning is erroneously being set TRUE during one of the LM:initialize_* functions.  I'm not sure what else may or may not be happening in between because what is/isn't logged seems kinda random to me.

Wait... What about this:
m_bMediaRunning is never assigned an initial value and has the possibility of not being assigned a value of FALSE during the LM::initialize_* functions.  m_bMediaRunning can only be set FALSE if m_bCoreRunning is TRUE during LM::initialize_Start (when checkMedia() is called).  So, sketchy again on the C++ but... will the memory location that m_bMediaRunning points to not just contain whatever was in the memory location beforehand?  And if it contains a 1 and m_bMediaRunning *is not* set FALSE somewhere then it could be TRUE?  If this is the case it would be just a matter of setting m_bMediaRunning=false at the top of LM::initialize_Start()...(or somewhere else)?

This could also explain why some people experience the problem and some don't.

I might be completely crazy here...  I've been beating my head into this monitor for a while...  ???


Installation issues / Re: Double orbiter and other strange things - Try this
« on: September 20, 2009, 05:00:05 pm »
Thanks for confirming the boot order for me Thom!

I've been digging further into this and am starting to get a good grasp of the lmce boot process.

I have done a near forensic audit of my logs during the incorrect boot process and have narrowed down the issue to occurring within LMCE_Launch_Manager.  My C++ is pretty sketchy so I decided to double check every possible script I could during the boot process.  I couldn't find anything in the scripts which would cause orbiter to load prematurely so I went back to LMCE_Launch_Manager.

Complete LaunchManager.log from an incorrect boot:
Code: [Select]
05      09/19/09 10:18:24.919           Detected core as device #1 <0xb77616c0>
05      09/19/09 10:18:30.390           Requested respawning of new children devices <0xb77616c0>
05      09/19/09 10:18:30.546           Failed to open file /usr/pluto/locks/pluto_spawned_local_devices.txt <0xb77616c0>
05      09/19/09 10:18:30.546           Continuing, assuming no devices are running <0xb77616c0>
05      09/19/09 10:18:30.546           Spawning new children devices - media <0xb77616c0>
05      09/19/09 10:18:31.112           Finished spawning new children devices - media <0xb77616c0>
05      09/19/09 10:18:31.123           Finished respawning of new children devices <0xb77616c0>
05      09/19/09 10:18:31.133           Sending  SYSCOMMAND_DEVICE_UP from LM device 1 failed <0xb77616c0>
05      09/19/09 10:18:32.383           Starting process /usr/pluto/bin/ <0xb6dffb90>
05      09/19/09 10:18:48.609           void ClientSocket::Disconnect() on this socket: 0x9540f40 (m_Socket: 9) <0xb6dffb90>

By cross-referencing with pluto.log it seems premature execution of orbiter is occuring between "Spawning new children devices - media <0xb77616c0>" and "Finished spawning new children devices - media <0xb77616c0>".  But these sections of code shouldn't be executing if the Core is not running yet (at least from my understanding of the code)...

So I forced to execute BEFORE LMCE_Launch_Manager by adding it to right before the call to  The system seems to boot PERFECTLY (or it seems so to me... I'm still learning).  The following is my complete LaunchManager.log from the new boot:

Code: [Select]
05      09/20/09 10:06:08.659           Detected core as device #1 <0xb77f66c0>
05      09/20/09 10:06:13.920           void ClientSocket::Disconnect() on this socket: 0xb6e4b5a8 (m_Socket: 9) <0xb77f66c0>
05      09/20/09 10:06:15.271           Requested respawning of new children devices <0xb77f66c0>
05      09/20/09 10:06:15.548           Failed to open file /usr/pluto/locks/pluto_spawned_local_devices.txt <0xb77f66c0>
05      09/20/09 10:06:15.548           Continuing, assuming no devices are running <0xb77f66c0>
05      09/20/09 10:06:15.549           Spawning new children devices - core <0xb77f66c0>
05      09/20/09 10:06:37.140           Finished spawning new children devices - core <0xb77f66c0>
05      09/20/09 10:06:37.145           Finished respawning of new children devices <0xb77f66c0>

LMCE_Launch_Manager understands that the core is already started and doesn't re-execture  Now a "Spawning new children devices - core" executes (because the core is now started) and the "Spawning new children devices - media" section doesn't seem to be executed (but I think it should be).

Now, I am no C++ expert, I'm wondering about an expression in LM.cpp which tests to determine if the spawn devices-media section will execute:

Revision 22269 - LM.cpp - Line 1584
Code: [Select]
1584        if ( ( (m_bCoreHere &&m_bCoreRunning) || !m_bCoreHere) && m_bMediaHere && (m_sAutostartMedia=="1" || false) )

Should there not be a space between the && and m_bCoreRunning for the expression to evaluate properly?  If LMCE_Launch_Manager knew the core was not running it wouldn't attempt to execute the spawn devices-media section at this time.  Likewise it *should* execute this section if the core is running (but didn't).

I'm sorry if I'm way off here but the only C++ experience I have is a college course nearly 10 years ago.  I'm willing to keep beating my head into the screen trying to sort this through but this is my best guess right now.

Pages: 1 ... 58 59 [60] 61 62 63