[tbone]

Hi there,

I recently received a Samsung Galaxy Tab2 10.1, model P5110, and am currently trying to run xbmc on it. I have tried the following XBMC builds (don't know how to refer to them, so I will post the exact download links):

http://mirrors.xbmc.org/releases/android...bi-v7a.apk (stable, I believe)
http://mirrors.xbmc.org/nightlies/androi...bi-v7a.apk (nightly build)
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk (gotham build with libstagefright)

I'm experiencing the same problem with all the above, choppy playback on both 720p .mkv movies, and on classic 700mb .avi files. From what I saw from the debug, they all run at around 4-5 fps. From the debug I also noticed that 720p movie playback is at 100% processor usage, while .avi files keep the processor usage at around 60% (probably software decoding? but if the processor is not maxed out, why the choppy playback, even if software?).

Also, the sound is in sync with the time position of the movie, so everything seems to be related to the video playback.

With MXPlayer, for example playback is smooth, no problems for both the 720p and the regular movies, so this doesn`t sound like something android related. Both XBMC and MXPlayer are playing them as streams from a local NAS I own, so I guess I can rule out network connectivity.

I'm running the default Android 4.0.4 provided by samsung, with no modifications whatsoever.

I don't know what to post for aditional information. The technical specs for the device are:

Chipset TI OMAP 4430
CPU Dual-core 1 GHz Cortex-A9
GPU PowerVR SGX540

What throws me off is that MXPlayer is able to play the files back flawlessly, while xbmc doesn't. I guess the resources are enough for 720p playback. Searching on the forums dind't produce anything relevant to this, so any reply would be greately appreciated.

[Ned Scott]

Not sure, but one thing to keep in mind: MXPlayer often has options we don't have, since we can only use open-source-friendly code/options/apis. Developers of other Android players have even told us that they would like to help us, but that their code isn't compatible with open source licenses.

[tbone]

Hi Ned,

First of, thank you for your reply.

Second, I don't mean any disrespect by this, but it sounds something like "we went on a direction and we're sticking to it. If it works, it works, if not, we're sorry". I'm not talking about the source here, I'm talking about the fact that nobody knows if the source code for this really is compatible for this chipset, or there's another issue, because nobody tried it. I'm willing to be active on the forum and post logs and offer support if anybody wants to take a shot at it.

I saw all these other posts about xbmc and android, and I understand some chipsets aren't fully supported, but if anybody wants to build something for this, I am willing to test whatever comes out.

Again, I mean no disrespect by this! I appreciate everything that has been done by the xbmc community, because I know it meant a lot of hard work to get to this point, and all the staff replying on the forum (saw a lot of posts regarding choppy playback on tablets, where people didn't even know how to spell their name, let alone post something that can be of use to somebody who knows the code, and help the troubleshoot). Your patience is really appreciated.

Thanks,
-tbone

[Ned Scott]

I'm not a developer, just a support member. Think of me as the office assistant at a doctor's office who is doing leg work to help give the developers more time to develop. As far as I'm concerned, this is all magic to me. This would be why I said "Not sure". I would not look for any deep meaning in my original reply :)

Your best bet would be to report your findings in the libstagefright thread: http://forum.xbmc.org/showthread.php?tid=152005