Why OpenShot will Not Run on my Linux Tablet

In This earlier posting, I had written, that although I had already deemed it improbable that the sort of Linux application will run on my Linux tablet, I would nevertheless try, and see if I could get such a thing to run. And as I wrote, I had considerable problems with ‘LiVES’, where, even if I had gotten the stuttering preview-playback under control, I could not have put LiVES into multi-tracking mode, thereby rendering the effort futile. I had also written that on my actual Linux laptop, LiVES just runs ~perfectly~.

And so a natural question which might come next would be, ‘Could OpenShot be made to run in that configuration?’ And the short answer is No.

‘OpenShot’, as well as ‘KDEnlive’, use a media library named ‘mlt’, but which is also referred to as ‘MeLT’, to perform their video compositing actions. I think that the main problem with my Linux tablet, when asked to run such applications, is that it is only a 32-bit quad-core, and an ARM CPU at that. The ARM CPUs are designed in such a way, that they are optimal when running Dalvik Bytecode, which I just learned has been succeeded by ART, through the interpreter and compiler that Android provides, and in certain cases, at running Codecs in native code, which are specialized. They do not have ‘MMX’ extensions etc., because they are RISC-Chips.

When we try to run CPU-intensive applications on an ARM CPU that have been compiled in native code, we suffer from an additional performance penalty.

The entire ‘mlt’ library is already famous, for requiring a high amount of CPU usage, in order to be versatile in applying effects to video time-lines. There have been stuttering issues, when trying to get it to run on ‘real Linux computers’, though not mine. My Linux laptop is a 64-bit quad-core, AMD-Family CPU, with many extensions. That CPU can handle what I throw at it.

What I also observe when trying to run OpenShot on my Linux tablet, is that if I right-click on an imported video-clip, and then left-click on Preview, the CPU usage is what it is, and I already get some mild stuttering / crackling of the audio. But if I then drag that clip onto a time-line, and ask the application to preview the time-line, the CPU usage is double what it would otherwise be, and I get severe playback-slowdown, as well as audio-stuttering.

In itself, this result ‘makes sense’, because even if we have not elected to put many effects into the time-line, the processing that takes place, when we preview it, is as it would be, if we had put an arbitrary number of effects. I.e., the processing is inherently slow, for the eventuality that we’d put many effects. So slow, that the application doesn’t run on a 32-bit, ARM-quad-core, when compiled in native code.

(Updated 10/09/2017 : )

Continue reading Why OpenShot will Not Run on my Linux Tablet

I’ve just installed LaTeX on my Android / Linux tablet.

In This Posting, I roughly explained how I was able to install Linux on my Samsung Galaxy Tab S.

Since then, the Linux software that I was able to install, and which works, include, among other applications,

  • GIMP
  • Blender
  • LibreOffice (a Comprehensive Install)
  • InkScape
  • GVim
  • MPlayer (Video With Sound)
  • LaTeX
  • LyX (A Word-Processor based on LaTeX, and not quite WYSIWYG)
  • (a Graphical LaTeX Code-Editor)
  • ‘Dia’ (a Useful Diagram-Editor)
  • Miscellaneous Diagram-Drawing Software (that uses LaTeX as a Back-End)
  • wxMaxima (a Computer Algebra System with GUI)
  • GNUPlot (Gives 3D Plots)
  • Yacas (Yet Another Computer Algebra System)
  • ‘mkvtoolnix-gui’ (A video-file concatenation tool)

But, doing so also consumed several GB of storage, even though that tablet only has 16GB of storage. Currently, my Linux guest-system is taking up 4.41GB.


(Updated 10/08/2017 : )

Continue reading I’ve just installed LaTeX on my Android / Linux tablet.

I now have Linux installed on my Samsung Galaxy Tab S.

A fact which I had lamented about, was that my Samsung Galaxy Tab S, First Generation – Android tablet – had essentially crashed. Its behavior had gotten so unstable as to make it unusable.

What this also did – given that I have a working Pixel C – was make the software / firmware -installation on the Tab S expendable, which meant that as soon as I was over the loss, I found myself willing to experiment with it.

So I did a factory reset, which made it stable again, at the expense of deleting all my user-data and separately-installed apps from Google Play. Essentially, the tablet had crashed while I was doing a routine update of apps, for which reason the FS corruption was limited to the ‘/sdcard’ partition, where user-installed apps are stored, as well as perhaps, to the ‘/data’ partition, where application data is stored. The factory reset empties those, and, because no system software update was taking place at the time of the crash, the ‘/system’ and ‘/boot’ partitions probably did not suffer from any corruption.

Then, I installed Linux on that tablet, using the Google Play store app named “GNURoot“, as well as using the Google Play store app named “XSDL“. When we install Linux on Android-capable hardware, we need to have a working Android system on that as well, because only the Android software can really provide the display drivers, and the I/O.

XSDL is an Android app which emulates a Linux X-server, which Linux sessions could connect to, as long as the Linux sessions can be persuaded not to try launching their own X-server instance, which their packages tend to depend on.

GNURoot is an app for Android 6+ that allows Debian / Jessie packages to be installed directly to the Android File System, and which runs those packages as though it was Linux. Remarkably, it does not require the device be rooted. It also uses the Android kernel. With the correct packages installed, it’s possible to get a proper desktop-session going between ‘GNURoot’ and ‘XSDL’. But the process is not user-friendly.

At first I had tried to install a system of ~400 packages, that provide ‘XFCE’, only to find that this desktop-manager could not connect to the ‘XSDL’, X-server, at least in any way I could get working. But then I tried uninstalling ‘GNURoot’, reinstalling ‘GNURoot’, and then installing the packages for ‘LXDE’, which is a lightweight, yet better desktop manager than the older XFCE would have been. This time, doing so required I patiently install ~600 packages.

Apparently, LXDE could be told to connect to an ‘XSDL’ instance quite well, and I obtained a working desktop-session. I also installed “GIMP” and “Blender”, which both ran fine – even on my Android tablet !



There was one caveat to using this configuration however, which is that I absolutely needed to connect an external, Bluetooth mouse, as well as an external Keyboard. Apparently, the ability of ‘XSDL’ to provide virtual replacements for those, just wasn’t up to snuff.

(Updated 10/04/2017 : )

Continue reading I now have Linux installed on my Samsung Galaxy Tab S.

New Potential in my Galaxy Tab S.

As I wrote in this earlier posting, I believe that my ancient Galaxy Tab S First Generation (Android) tablet has finally bit the dust, due to File System Corruption.

This is not just due to the wonky behavior following the latest hard-boot (during a routine software-update no less), but also because over the years, the amount of free memory on it has become very small, even though I have uninstalled most of the apps that were once installed on it. Typically, failure to reclaim unused space, is one of the earliest signs of FS corruption.

Depending on how one looks at it, visualizing this as a terminally-crashed tablet can have its upside, especially since my needs for a stock Android tablet are met in my ownership of a Pixel C. What this actually means is that I can regard the present installation on the Tab S as expendable, which means that eventually, I’d be able to experiment with it as I wish. For example, I might eventually want to root the Tab S, or install Linux on it…

But one fact which I seem to gather after some reading, is that even to install Linux on Android-capable H/W, does not take place as it does with PCs, where the Linux system is the only running O/S. Instead, Android-capable H/W seems to require that one way or another, we install Linux alongside Android. Thus, unless I get Android working again on the tablet first, I also wouldn’t be able to get Linux working on it.

Further, rooting an Android device does not (necessarily) cause the firmware to be flashed. Instead, if we want to flash the firmware, this is a separate operation which can also be done.

Long story short, whether I’ll ever be able to resurrect that tablet, depends on how it’s partitioned, and in which partitions I suspect the FS corruption has hit.

For example, if I just root, then the data and apps on the ‘/sdcard’ will not even be affected, and if that’s where the FS corruption was, the FS corruption will just stay there. The similar effect would take place, if I was to flash a custom ROM Image on the device, which would affect the ‘/system’ partition and/or the ‘/boot’ partition, but not affect the ‘/sdcard’ .

I would strongly suspect that the FS corruption is on the ‘/sdcard’ , especially since I wasn’t updating the O/S, when the latest crash took place. And what that would seem to suggest, is that my next step should actually be, just to perform a factory reset: The simplest advice sometimes given! That should reset the ‘/sdcard’ , and the ‘/data’ partition, mainly.

If that causes the tablet to become stable again, Then I could proceed next, to root, to install Linux, etc., etc., etc.. Or, I could just recommence with Android, with more reclaimed memory, and with a stable tablet…