The VideoLAN Forums

I have an Acer Iconia Tab 8 A1-840FHD, which has an Intel Atom Z3745 Quad-core 1.33 GHz CPU, but when trying to start VLC it claims that I'm trying to run a x86 build on a non-x86 system?!

Intel Atom Z3745 Quad-core is a 64bit processor and KitKat has a 64bit version. What makes you think that your are running a 32bit (x86-build) on your tablet?

Intel Atom Z3745 Quad-core is a 64bit processor and KitKat has a 64bit version. What makes you think that your are running a 32bit (x86-build) on your tablet?

Because it's in the error-message that VLC throws on the screen!?

Well, x86_64 is backwards-compatible with x86, so that is not the issue.

Use something like sysinfo for Android to look at what CPU_ABI/CPU_ABI2 are.

Well, x86_64 is backwards-compatible with x86, so that is not the issue.

Use something like sysinfo for Android to look at what CPU_ABI/CPU_ABI2 are.

Is this the information you need?

# Build #
ID=KOT49H
Product=a1840fhd_ww_gen1
Device=ducati2fhd
Board=baylake
CPU ABI=x86
CPU ABI 2=armeabi-v7a
Manufacturer=Acer
Brand=acer
Model=A1-840FHD
Type=user
Tags=release-keys
Finger
Print=acer/a1840fhd_ww_gen1/ducati2fhd:4.4.2/KOT49H/1409562162:user/release-keys
Time=1409562229000
User=pandora
Host=pandora01
Hardware=ducati2fhd
Radio=unknown
Bootloader=unknown
Incremental Version=1409562162
Release Version=4.4.2
SDK Version=19

---
Angelo

CPU ABI=x86

It should work fine then.

CPU ABI=x86

It should work fine then.

Well, it doesn't

I can send a screenshot if desired.

Angelo

Tested again with the latest nightlies on an x86 Android with CPU API=x86 and CPU_ABI2=armeabi-v7a and it works fine.

Tested again with the latest nightlies on an x86 Android with CPU API=x86 and CPU_ABI2=armeabi-v7a and it works fine.

Where are these builds because I have exactly the same problem with both vlc, vlc beta from google play and the nightly android x86 build. The nightly armv7 build installs and works to the extent it plays audio files but crashes when a video file is selected. All the others fail with

X86 code on non x86 device

Sysinfo# Build #
ID=KOT49H
Product=a1840fhd_ww_gen1
Device=ducati2fhd
Board=baylake
CPU ABI=x86
CPU ABI 2=armeabi-v7a
Manufacturer=Acer
Brand=acer
Model=A1-840FHD
Type=user
Tags=release-keys
Finger Print=acer/a1840fhd_ww_gen1/ducati2fhd:4.4.2/KOT49H/1409562162:user/release-keys
Time=1409562229000
User=pandora
Host=pandora01
Hardware=ducati2fhd
Radio=unknown
Bootloader=unknown
Incremental Version=1409562162
Release Version=4.4.2
SDK Version=19

Ah ...the armv7 build VLC-debug-20150129-0104.apk works. Presumably via arm code emulated on the Intel processor rather than native x64 code. Surprisingly smoothly if it is using emulation. But why doesn't the x86 build work?

It is weird indeed. But I cannot seem to reproduce this problem, and it is always able to run on my x86 Android test setup...

Edit: Jean-Baptiste is right about the bug on some Acer firmware. (My testing device is a vanilla Android-x86, not an Acer, so this may be why.)

Sure, Acer is known to --please stay polite-- up their x86 firmware.

Sure, it's always easier to point the finger somewhere else.......

Sure, it's always easier to point the finger somewhere else.......

I'm sorry, but Acer kernel claims to be ARM CPU, while it is not. This is not our fault. And we cannot do a workaround unless we have a device.

Sure, it's always easier to point the finger somewhere else.......

I'm sorry, but Acer kernel claims to be ARM CPU, while it is not. This is not our fault. And we cannot do a workaround unless we have a device.

>> CPU ABI=x86 <<

And why do other x86 software work??????

We use /proc/cpuinfo for this, because that flag can lie.
Other x86 software work, because they do not check.

And the proof is here:
http://git.videolan.org/?p=vlc-ports/an ... =HEAD#l119

We use /proc/cpuinfo for this, because that flag can lie.
Other x86 software work, because they do not check.

So you use cpuinfo because the CPU ABI=x86 can be false, but earlier I read that the kernel of Acer 'lies', which I guess is the cpuinfo file. Makes sense... well not really actually. Like I stated earlier, it's always easier to point the finger elsewhere.....

We use /proc/cpuinfo for this, because that flag can lie.
Other x86 software work, because they do not check.

So you use cpuinfo because the CPU ABI=x86 can be false, but earlier I read that the kernel of Acer 'lies', which I guess is the cpuinfo file. Makes sense... well not really actually. Like I stated earlier, it's always easier to point the finger elsewhere.....

Are you stupid or are you making it on purpose? Read the code.

Also, the fact that it works with ALL intel devices, except one ACER and one ASUS that share the same driver/board/cpu and the same kernel, is of course our fault.

Well, the problem here is sort of like this:

Imagine that you have a machine which sorts cans of soda from an assembly line into two piles. And say that we have two types of soda, soda A and soda B. Each can of soda has a barcode on it, and this should normally be 001 for soda A and 002 for soda B. This machine will take each soda from the incoming line, scan its barcode, and direct the soda to the appropriate pile.

Now imagine that someone in the assembly line made a mistake, and that somehow a 002 sticker wound up on a can of soda A. Then the machine will accidentally direct this can to the soda B pile, and you pick up this can, taste it, and notice that it is not soda B, but soda A.

In this case, VLC is sort of like the soda sorting machine, reading data supplied by the target - cpuinfo in the case of ASUS, and barcodes with the soda machine. And so if the data being provided is in accurate, an inaccurate decision could be made. The assumption is that the barcode will be correct most of the time - and in fact it is the norm that the barcodes are put correctly, and not incorrectly, which is why the machine is actually able to work in the first place.

Other players may just have an x86 build and just assume that it will work. In that case it is like a machine which normally processes soda of only one type - it just takes it and puts in in the pile. No reading barcodes needed, and this is why many other x86 apps will just work fine, because they assume that the soda A will always be soda A.

Now an obvious fix, at least for the ASUS case, is that now that we are aware of this device's quirks, we could hardcode an exception to do that, and I might do that if I get enough free time for it.

Hopefully this will help with understanding the problem at hand.