Cirion,I'm even more confused now, I did it all again from scratch, and it worked fine. Xine in KDE looks like this for me (I really thought it should say dshowserver instead of Matroska but apparenlty not):

Just thought I'd mention, Jean, it actually indicates that it is demuxing not decoding with matroska. It does mention dshow further down. Demuxing is only pulling the streams out of the container not actually decoding it which is the heavy duty bit.

Perhaps it is just using matroska to demux, then your bit to decode? After all, it isn't really your codec's responsibility to demux, that's container management

I'm even more confused now, I did it all again from scratch, and it worked fine. Xine in KDE looks like this for me (I really thought it should say dshowserver instead of Matroska but apparenlty not):

Now I do not even know what else to try...

I think it's great that you have gotten it to work, and even better that you are willing to share! But I honestly do not believe your Wiki works... I have tried every possible way I can think of, and it does not work for me. You must have done something that is not in the wiki.

This is what I have done when following your 10 steps in the wiki:

Step 1) Download coreavc-for-linux on my MD as root.I did this by ssh'ing to my core, from there shh to my moon59.

ssh linuxmce@192.168.80.1sudo sussh moon59Tried the svn command and it failed.... Subversion not installed. (This point is missing from your wiki.)After installing subversion I could run the svn command

apt-get install subversionsvn checkout http://coreavc-for-linux.googlecode.com/svn/trunk/ coreavc-for-linuxSubversion could be installed as a prerequesit together with other missing packages. (see later steps)

Step 2) Download dshowserver.From the information you gave I belive the file from June 20 to be the correct one.Still in on my MD:

Step 4) Buy CoreAVC, install it on a windows machine and copy CoreAVCDecoder.ax from that to the MD.In my opinion this part should be the first step in your wiki. There is no need to do the first 3 steps if you can not or will not do this one...The wiki fails to mention that there is no .mplayer folder in the home directory of a MD.I transfered my CoreAVCDecoder.ax with a USB stick and with KDE I copied it to my home directory on the MD. After that I copied to the correct directory.Still on my MD:

mkdir /usr/lib/win32/cp CoreAVCDecoder.ax /usr/lib/win32Step 5) Register CoreAVC on the MD.The wiki fails to mention that there is no .mplayer folder in the home directory of a MD. Exporting registry will fail but no errors...Still on my MD (And I did use my registered serial instead of the 55555-55555-CORE-55555-55555).

Step 7) The info that should come in step 8. came here... And setting up the development environment should have been a prerequisite to the whole proses and come before step 1)Step 7) did not say how much of the external wiki should be followed and where it should be installed. I followed the external wiki and installed it on my core. I only followed the steps in the section "Setting Up the Development Environment".

Step 8. Had no info, but I got the point in step 7)Here is also where I was unsure on what to do. I did setup the development enviroment on my core, and the Wiki does not say where to compile/install libxine...

I could continue on my core and copy the libxine.so.1.19.0 to my MD and do the rest there, which was my first try, but that resulted in Xine not working on the MD anymore and no media played after that.

Compiling fails on both the core and the MD. I cannot say if the core was missing build-essential or not, since I had compiled other stuff there before. But the MD did not have it, and both Core and MD needed to install libxext-dev before compiling.

Needed packages could be installed in one go in the first step like this:

apt-get install subversion build-essential libxext-devSince I set up the development enviroment on the core, I tried compiling from the MD while the source was in the Core's home folder. Even being logged in as root, does not give the permission to do that. The compiler then fails with the following error:

checking whether the C compiler works... configure: error: cannot run C compiled programs.If you meant to cross compile, use `--host'.See `config.log' for more details.The solution was to copy the source to the MD.

Running the patch on my Core or my MD with the patch -p1 <path/to/coreavc-for-linux/xine/dshowserver.patch command did not work for me. The prompt just got stuck nothing was done. I tried waiting for 5 hours once... CTRL X stops it. Using -Np1 -i like Zaerc suggested worked fine.

rebootAfter a reboot there is no difference at all for me. Still the same amount of jerkiness in MKV HD files, and still the same amount of green artifacts.Now you know how I did everything, and that it was not possible for me to follow everything 100%.

I really hope this helps you in finding what I did wrong or different from you Jean, and I hope this helps someone else that wants this to work.

Colinjones: thanks for clarifying that, it's always better to call things by the right names :-)

Cirion: sorry if my directions are unclear. Before trying to make it work in LMCE, we should focus on getting a proof that it's actually using CoreAVC when running verbose on KDE. Right now your output shows that CoreAVC is not being used, so at least we know that this is the problem.

The development environement should have been installed on the MD, since this is where we want to compile xinelib.

Did that work? Did you see that it was being compiled without fatal errors when running this on the MD?

I'm wondering why the patching fails when you run my syntax. If for some reason the patch was not happening, it would explain why the new xinelib does not use CoreAVC.Can you confirm for example that after running the patch, the following file exists on your MD: linuxmce/charon-merge/ubuntu/xine-lib-1.1.10.1/src/libxinevdec/dshowserver.c

PS: What's the architecture of your MD? The one I used is AMD64, and I'de be happy to send you my compiled xinelib to try that out on your system if you wish.

My MD's are both AMD64. They use a Athlon 64 X2 4400+ and sit on a Abit AN-M2HD motherboard.I'm not running in 64bit on them. I use i386 since that is the only way to get SASC-NG to work with my DVB-C cards.

If you have a file compiled for 64bit I'm happy to try it, I'll just rebuild to 64bit on one of the MD's. Also, if you could send me you patched xine-lib-1.1.10.0 source folder I could try that too. I'll send you my e-mail adress in a pm.

Just my 2 cents. I've been working on this since I saw the first post.This setup works with both the x86 and x64 710RC2 DVD installers (as far as installation). I haven't tried a manual install with the CD version.

I do have a question though, how can I tell if it is working properly on a diskless MD?

To check if it's working, I first run xine with the --verbose option in KDE. It should talk about using version 1.7.0 shortly after recognizing the matroska stream. This will mean that it's indeed using CoreAVC. From there it's a fair assumption that xine in LMCE will do the same as long as the shared object was placed in the right folder, and to be completely sure, you can compare the CPU usage between the old shared object and the new one (by monitoring with top while playing a video) and you should notice a clear difference.

If you'll check the man page, you'll find that: patch -p1 < <path to coreavc-for-linux>/xine/dshowserver.patch is actually equivalent to: patch -Np1 -i <path/to/coreavc-for-linux/>xine/dshowserver.patch. With the added benefit of quitting if the patch was already applied, instead of asking to reverse the patch instead which can be confusing.

Doh. Just saw this after rereading the thread. I'm going to try Jeangot's suggestion of symlinking the other instances of libxine.so.1.19.0 (/usr/lib and /opt/libxine/lib) to the newly compiled version in /usr/local/lib/. I'll post the results later.

I'm very sorry but this: tar -xjf <path to dshowserver-ia32-r63-gentoo.tar.bz2 is just plain wrong, either you are telling tar to read from a file and then redirect a file to it's standard input instead, or you're intending a <placeholder> but you forgot the ">". Instead I don't really see much of a problem with tar -xjf <path/to/>dshowserver-ia32-r63-gentoo.tar.bz2, so please enlighten me.

If you'll check the man page, you'll find that: patch -p1 < <path to coreavc-for-linux>/xine/dshowserver.patch is actually equivalent to: patch -Np1 -i <path/to/coreavc-for-linux/>xine/dshowserver.patch. With the added benefit of quitting if the patch was already applied, instead of asking to reverse the patch instead which can be confusing.

Now obviously pasting things with <placeholders> isn't going to work when you copy/paste them literally anyway, but the real problem however was because you misspelled "libxine" in the first place. So thanks for your lovely "compliment", but the only one that messed up here was you. It's a bit sad to see you (and nobody but you) complain about these non-related trivial things to cover that up though.

And no, I haven't tried it myself because I don't see this problem at all (apart from that I am not a big fan of closed source software). But if I had, we probably wouldn't even be having this discussion now would we?

I can't imagine why more people don't try to help with the project considering the warm reception efforts are met with. LOL

I'm going to try Jeangot's suggestion of symlinking the other instances of libxine.so.1.19.0 (/usr/lib and /opt/libxine/lib) to the newly compiled version in /usr/local/lib/. I'll post the results later.

Ok, that did the trick. I moved the files in those directories to .bak and symlink'd the libxine from /usr/local/lib. Now xine indicates using coreavc, and playback is much improved. Before, xine would spike to 100% during action sequences, but now dbshow runs a steady 50-60% of cpu.

Next step is to get coreavc working with mplayer so I can get smooth 1080p mkv playback through the linuxmce interface.

For anyone still having problems getting this to work, please read on:I was trying to add CoreAVC to a new MD thsi weekend, following my own Wiki instructions. I decided to take a shortcut when building the dev environement and after downloading the LMCE source code, I did not complile it, and instead went straight to the xinelib compilation. Xinelib complained about missing zlib and Xshw or something like that, which I provided via Ubuntu packets.Well, the resulting xinelib was ignoring dshowserver and Coreavc, just as described by Cirion.

Therefore I want to indicate that it is very important to go through the ./configure and make when installing the dev environement (even though this takes hours) as this provides specific versions of libraries used by xinelib for all this to work.

I was going to update the Wiki accordingly but apparently something is broken there regarding Captchas. When trying to save, the wiki says that I entered the captcha incorrectly, but there is no captcha displayed...

But now that I'm looking into the WinMobile Orbiter, I had to download the source again. Following the wiki I now se a change in how to download and compile it. I now se that you have to download the source as the user LinuxMCE and not use sudo su like I did earlier.