[nikiiv]

This is most bizarre
I am on x64 so I cannot see how skipped frames I have, however.. I installed brand new Jaunty and brand new Babylon Beta 1 and seems that multi-threading is working fine

This is so thrilling...

[blackstar_ii]

I am running INTREPID on an Intel DualCore rig and I also saw this issue with uneven loading of the cpus. I have not verified this in detail, but the fix for me was to start xbmc under a different process scheduling policy. Currently I am using 'schedtool -B -e /usr/local/bin/xbmc --standalone' which works ok.

There is a better result with one of the policies reserved for root, but I am running xbmc under a normal user account.

The default INTREPID policy kind of makes sense as keeping all processes on one cpu improves latency and loss on task switching. It's just that it does not react to load peaks fast enough to avoid frame drops.

The policy I use means that cpu reallocation happens slower, so there is a higher preference to stay on two cpu once a peak has happened. The load is not perfectly even, I'd say about 60/40 ratio. I had guessed that this was due to single thread audio decoding (and there still being a preference to consolidate threads onto one cpu).

Killa sample runs without framedrops, where as before it was consistently loosing about five+ frames per loop. (I test with making a playlist with repeat to isolate disk/network caching.)

Hope it helps someone...

[bbaldino]

Just stumbled across this after upgrading to Intrepid and seeing issues. Is there any possibility of using an older version of XBMC to alleviate this? Or is the problem in both the OS and XBMC, meaning you'd have to re-install Hardy and XBMC to get it back?

[adelias]

I tried schedtool but unfortunately it didn't fix the problem. Hopefully a fix is in the works and will be available soon.

[mcka]

Has anyone tried to use the hardy kernel or hardy kernel config in the new ubuntu version? I'd gess that it's caused by a new or updated kernel module, so perhaps a custom kernel could help?

[althekiller]

Has anyone tried to use the hardy kernel or hardy kernel config in the new ubuntu version? I'd gess that it's caused by a new or updated kernel module, so perhaps a custom kernel could help?

Yes, no difference.

[ERamseth]

Does this problem rear it's ugly head in XBMC Live edition?

[alanwww1]

Not in 8.1, but it does in 9.04.

[ubiq]

I was happily using the smoothvideo branch before it was merged to the linuxport branch and now reverted back to the linuxport branch. I did a clean install and noticed that now my high bitrate material made my dual-core very unevenly loaded. One core could almost be idling with 10% usage while the other core could reach 100% and frames would drop.

I know this is very well known problem but for some reason this workaround fixes this issue for me. I was surprised to see that it wasn't merged from the smoothvideo branch so I manually edited the pthread.c file and made the needed changes and compiled again. Now all my video files play with pretty much even core load and I can use software decoding.

I know that VDPAU has made this problem pretty obsolete but every now and then I come across a file in my library that doesn't work right with VDPAU and at the moment VDPAU isn't so ready that it knows to fall back to software decoding in such cases. Also the ssa/ass embedded subtitles (with attached fonts) are yet not working with VDPAU.

I'm pretty sure that all of you are aware of the workaround found in the smoothvideo branch and I would like to know if it is going to be merged to the linuxport also or is it known to cause problems and that is why it isn't going to be merged? For me it works fine except when using high quality upscaling. That is when the workaround can not produce evenly distributed core load.

ubuntu 8.10 intrepid, up-to-date
svn 20244, manual compile

[althekiller]

bob didn't merge it because he confirmed it doesn't fix anything, only alleviates in some cases. We aren't keen on patching externals for no good reason, so this will likely never go into mainline.

[ubiq]

Ok, thanks! So I'll just keep using this workaround myself as long as it works or until VDPAU is in mature enough state or this problem is somehow figured out

[bobo1on1]

This seems to work, kind of:

Code:

echo 0 > /proc/sys/kernel/sched_migration_cost

[speed32219]

Frame drops in the latest releases is major when playing BD rips. (m2ts) on my 8300 chipset running kernel 2.6.27-14-generic and the latest May/June/July XBMC builds. (Note: Frame drops occurs using VDPAU, if I don't use VDPAU than my CPU's are running in the mid to high 70% range, but no loss of Video packets other than the 12-20 from the start of the movie)

I have an almost exact hardware setup (Nvidia 8200 vs the failing 8300 chipset) running kernel 2.6.27-11-generic Intrepid and r19419 that runs perfect. I am now trying to get a fresh copy of the r19419 build to try on the on the failing machine above. The one that works when playing BD, H264 MKV, MP4, etc. the CPU utilization is <10-12% across the CPU's with no packet loss! So if you have that virgin build, post it somewhere and let me know.

Asus M3n78-EM 8300 AMD 5050e 2 GB DDR800 and 500 GB WD HD - failing VDPAU XBMC r21749 and many others Fail
GigiaByte GA-M78SM-S2H AMD 4850e 2GB DDR800 and same 500 GB WD HD - Works like a champ! XBMC r19419

Edit: Crap, posted in the wrong thread. That will teach me to close some of the tabs I have open.

[althekiller]

Code:

for i in /proc/sys/kernel/sched_domain/*; do echo $(( `cat "$i/domain0/flags"` | 16 )) > "$i/domain0/flags"; done

Try to run that as root, it allows the kernel to wake idle CPUs when a thread that was running on them awakes. Apparently the kernel gods say it's too aggressive on multicore CPUs, some cache affinity blah blah blah... It alleviates most of the problems I've seen, if it works for you, do it. Credit to theuni for bisecting the kernel to find the change that caused all of this, and bobo1on1 for digging up the procfs tunable.

[alanwww1]

Code:

for i in /proc/sys/kernel/sched_domain/*; do echo $(( `cat "$i/domain0/flags"` | 16 )) > "$i/domain0/flags"; done

Try to run that as root, it allows the kernel to wake idle CPUs when a thread that was running on them awakes. Apparently the kernel gods say it's too aggressive on multicore CPUs, some cache affinity blah blah blah... It alleviates most of the problems I've seen, if it works for you, do it. Credit to theuni for bisecting the kernel to find the change that caused all of this, and bobo1on1 for digging up the procfs tunable.

Hey guys !

This works really well.

i just tested the Dark Knight file with a 2Ghz C2D it was dropping frames in every sec. After running this line it works like charm. No dropped frames and even CPU load.

Great work and thanks everyone contributed to the solution. Now there's absolutely no need to stuck with Hardy anymore.