[d4rk]

As of now, AFAIK, XBMC doesn't work in native 64-bit mode. However, most 64-bit versions of OSes also run 32-bit apps so you might be able to get the current version running on your 64-bit installation. Maybe someone who has tried this can chip in.

[djdafreund]

I'm cool with continuing to use 32bit for now i guess until this works. I don't want to upgrade just to try it. I don't know if things are as easy to run as it is for x64 running 32bit (which to date is easy for me, and problem free.) or if some special compiling needs to be done to work the same on Linux. Still learning, but fast. I love, LOVE Ubuntu so far. Somewhat easy for a win user, out of the various ones i've tried to date. XBMC works great on it, easy to compile and update and all.
I'd like to read some good positive feedback here if someone does get it working fine, or even mentions it DOES work fine using 32bit version even on top of 64bit Ubuntu.

[malloc]

I was able to get XBMC to compile, link, and run on a 64-bit machine. Unfortunately, the only thing it runs is the startup logo screen. It immediately crashes after that. With this:

Xlib: extension "XINERAMA" missing on display ":0.0".
WARNING: The XBMC_HOME environment variable is not set.
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
++ WARN: could not retrieve file info for `image.nrg': No such file or directory
++ WARN: can't open nrg image file image.nrg for reading
Segmentation fault (core dumped)

I pulled up gdb to see where the fault was:

Starting program: /.../xbmc-linux/XBMC/BUILD/XboxMediaCenter
[Thread debugging using libthread_db enabled]
[New Thread 47384433104480 (LWP 11408)]
Xlib: extension "XINERAMA" missing on display ":0.0".
WARNING: The XBMC_HOME environment variable is not set.
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
[New Thread 1082693952 (LWP 11427)]
[New Thread 1091086656 (LWP 11428)]
++ WARN: could not retrieve file info for `image.nrg': No such file or directory
++ WARN: can't open nrg image file image.nrg for reading
[New Thread 1099479360 (LWP 11429)]
[New Thread 1107872064 (LWP 11430)]
[Thread 1107872064 (LWP 11430) exited]
[New Thread 1116264768 (LWP 11431)]
[Thread 1116264768 (LWP 11431) exited]
[New Thread 1124657472 (LWP 11432)]
[Thread 1124657472 (LWP 11432) exited]
[New Thread 1124657472 (LWP 11433)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47384433104480 (LWP 11408)]
0x00002aaaac26c8df in list_dealloc ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so

Does anybody have any pointers on how to proceed?

Also, that warning is very baffling. I grep'd the code for "could not retrieve file info for" and it appears to be coming from libcdio (which makes sense given the file name). But why is XBMC trying to read a CD image and where is this call originating?

[d4rk]

Code:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47384433104480 (LWP 11408)]
0x00002aaaac26c8df in list_dealloc ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so

Looks like python is crashing not libcdio. A backtrace would be more useful.

EDIT: libcdio does check drives on startup FYI, to see if there are any discs in them.

[Gamester17]

There are a couple of 64-bit patches on out SourceForge tracker that either have not been reviewed at all or have been rejected with a comment to the author asking for some changes to be made before the patch can be approved, see:
http://sourceforge.net/tracker/index.php...tid=581840
http://sourceforge.net/tracker/index.php...tid=581840

Maybe you might want to start by looking at those two

libcdio does check drives on startup FYI, to see if there are any discs in them.

Why is libcdio checking the CD/DVD-ROM drive directly at startup, I thought that it should not do that until XBMC had fully loaded?, ...changing that might slighthly speed up the load time as well?

[malloc]

I'll look into those existing patches. Here's my backtrace:

#0 0x00002aaaac26c8df in list_dealloc ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#1 0x00002aaaac2a74ea in mro_internal ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#2 0x00002aaaac2a7a54 in PyType_Ready ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#3 0x0000000000b6152d in PyType_Ready (a=0x2aaaac514620)
at XBPythonDll.cpp:231
#4 0x00002aaaac2a8fc8 in PyType_Ready ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#5 0x0000000000b6152d in PyType_Ready (a=0x2aaaac5144a0)
at XBPythonDll.cpp:231
#6 0x00002aaaac27dff0 in _Py_ReadyTypes ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#7 0x00002aaaac28ab3b in Py_InitializeEx ()
from /.../xbmc-linux/XBMC/BUILD/system/python/python24-i486-linux.so
#8 0x0000000000b61039 in Py_Initialize () at XBPythonDll.cpp:109
#9 0x0000000000b5d45b in XBPython::Initialize (this=0x11dc440)
at XBPython.cpp:272
#10 0x0000000000b5d61d in XBPython::evalFile (this=0x11dc440,
src=0xdbfad5 "Q:\\scripts\\autoexec.py", argc=0, argv=0x0)
at XBPython.cpp:422
#11 0x0000000000b5d7c3 in XBPython::evalFile (this=0x11dc440,
src=0xdbfad5 "Q:\\scripts\\autoexec.py") at XBPython.cpp:408
#12 0x0000000000b5d7f4 in XBPython:rocess (this=0x11dc440)
at XBPython.cpp:379
#13 0x0000000000730d92 in CApplication:rocess (this=0x11d4ec0)
at Application.cpp:5486
#14 0x000000000099afda in CXBApplicationEx::Run (this=0x11d4ec0)
at XBApplicationEx.cpp:205
#15 0x000000000099e929 in main (argc=1, argv=0x7fff59b4b458)
at XboxMediaCenter.cpp:76

[d4rk]

Why is libcdio checking the CD/DVD-ROM drive directly at startup, I thought that it should not do that until XBMC had fully loaded?, ...changing that might slighthly speed up the load time as well?

The disc detection routine (which runs is a different thread) starts during XBMC initialization. Since it's in a different thread, it shouldn't affect performance much.

[d4rk]

I'll look into those existing patches. Here's my backtrace:

I wouldn't be surprised if the python integration API has 32-bit specific stuff for passing stuff back and forth. You could try compiling it with python disabled or else, track down the bugs.

[yuvalt]

1. there is a patch in SF for the python code -- try applying it and see if it's better. if it is, I will apply it to svn.
2. this problem also occurs in 32-bit...haven't been able to track it down, yet

[malloc]

how do i disable python?

[malloc]

1. there is a patch in SF for the python code -- try applying it and see if it's better. if it is, I will apply it to svn.
2. this problem also occurs in 32-bit...haven't been able to track it down, yet

1. The python patch in http://sourceforge.net/tracker/index.php...tid=581840 does nothing except add -fPIC to the gcc call. It's necessary to get it to compile on 64-bit platforms, although I would recommend -fpic instead (not sure of the difference but it seems -fPIC is the "safer" bet which probably means a performance hit). It's necessary to get it to compile and link, so I suggest applying it (I haven't seen any issues with having it on 32-bit systems).

2. Are you talking about the libcdio thing or python? I haven't seen the python error on 32bit.

[yuvalt]

how do i disable python?

I think in guilib/system.h there's a definition of HAS_PYTHON (search for the right one), then make clean and try.

-Yuval

[malloc]

Progress update:
Disabled Python and the GUI came up.
Searching for a samba share crashed it.
Trying to play a video didn't work (but it didn't crash).

[malloc]

Odd, the python crash goes away if I compile from source. It doesn't actually help anything though because it still can't load the python engine, it just doesn't crash anymore.