## One specific feature of the BOOX Max2 e-Reader falls short.

In a previous posting I wrote, that I am having a good experience so far, with my newly-acquired 13.3″ Onyx BOOX Max2 e-Reader. And a detail which I mentioned was, an eventual need to USB this device to a PC or Laptop. As an alternative, what many users expect, is some way to use Wi-Fi to transfer files. Yet, ‘SAMBA’ is Linux-software, while “SMB Protocol” is Windows-based, so that Onyx does not step outside its boundaries, to try to offer either. However, they try to make up for this.

If the user has the firmware update from December in 2018 installed, then under ‘Apps -> Transfer’, there is a modest app, which will act as a minimal Web-server and which, in addition to displaying a QR-code, also displays a URL with an IP-address and a port-number, which exist on the LAN, and which the user is meant to point a PC- or Laptop-based Web-browser at. There is no reason why the functionality of this URL would be limited to one O/S, under which the Web-browser is running.

A Web-page displays on the PC browser, that can use the inherent functionality of browsers to choose files on the PC, and to Upload those to the server, which resides on the e-Reader as long as the user doesn’t close this app.

• This feature is mainly meant to allow e-Books to be transferred, and the choice of folders they appear in suggests, it wasn’t fully meant for other types of files, such as APK-Files.
• Onyx could have tried a little harder and made it possible to transfer files in the opposite direction, let’s say from a specific folder on the e-Reader, to the Web-browser of the PC… Some people might think that this is redundant for an e-Reader because Books can be given to the e-Reader and later deleted on it. However, because the Max2 can also be used to store sketches with its Stylus, such a feature might not have truly been redundant.

So, because of the two bulleted reasons above, the need will ultimately remain, to USB this device to a PC.

However…

## A Problem which can befall Dropbox under Linux (Unable to Access -Folder).

This is a problem which has happened to some of the Dropbox customers, who have the client installed under Linux:

The Dropbox Icon changes to a grayed-out icon, with a red cross, and when we click or right-click on the icon, it says it’s unable to access (its) Dropbox folder. It even asks us for our Linux Password (apparently Windows-gurus don’t understand Linux), in a bid to correct the permissions of the folder in question. Don’t enter any password. At the same time, if we have a very complex desktop-management system running, we may find that the Desktop and its management-software become laggy to almost non-functional, especially with ‘Baloo’ running etc..

In my case this was due to the combination of two factors:

1. I had added many, systematically-named files to my Dropbox folder from another synced computer, due to backing up newly-installed software.
2. Dropbox uses a feature called ‘INotify’, so that a program gets notified as soon as the contents of a file are changed, which that program has placed a watch on. In this case, Dropbox has a watch on thousands of files.

In my case, the following helped. On a Debian-based system, in a terminal-window, type:


dirk@Phoenix:~\$ su
root@Phoenix:/home/dirk# cd /etc
root@Phoenix:/etc# edit text/*:sysctl.conf



Then, edit the file in question, to contain the following two lines:


fs.inotify.max_user_watches = 262144
fs.inotify.max_user_instances = 256



Then, to make the changes take effect, type:


root@Phoenix:/etc# sysctl -p



What this does is set the kernel limits ‘very high’, as to how many INotify-watches it will support. For the moment, the Dropbox client on this machine is stable again.

(Updated 07/03/2018, 8h35 … )

(As of 07/02/2018, 11h25 : )

Actually, according to my own recent experience, after applying the above fix, if the limit already did run out, a reboot is nevertheless required.

And because of the needed reboot, my server was also down for about 10 minutes this morning…

As of an earlier posting, I had “Dropbox” v3.16.1 running on my KDE-4 Linux desktop. This version has updated itself to v3.18.1 . Additionally, I have this Dropbox client installed and idling, on the Linux laptop I name ‘Klystron’.

I see one significant new behavior. When I have left my laptop idle, with the screen turning off, the little Dropbox icon changes to show that it has dropped its connection to the Dropbox server. This is similar to behavior which my “Pidgin” IRC client has shown, and seems to suggest, that there are power-saving measures in place on up-to-date Linux desktop managers, which certain applications may opt to use.

The ‘KDE’ desktop manager has in common with ‘GNOME’, that both now use ‘DBUS’ as their inter-process communication system. So what works under GNOME, will frequently also work under KDE when properly set up.

But the fact that both Pidgin and Dropbox seem to do this on my laptop, means that I do not have to keep looking as hard as before, for causes within the kernel module of my laptop WiFi, for possible connection issues. In both cases, the software seems to reconnect to its server, as soon as I have unlocked my screensaver.

Unlocking the screensaver is an event, which a kernel module usually does not recognize.

(Edit 04/17/2016 : ) One way in which such a power-saving mode would make sense however, is that the Kernel can recognize it, and can give the software command to the Kernel Module, to turn off its antenna as well. However, according to This Posting, I have forbidden the KM from following such a command, such that the antenna does not switch off.

Depending on what software we have installed, simply having the WiFi turn off, can cause problems.

Dirk

## Possible Solution to ‘Dropbox Missing Systray Icon’ under KDE

Just yesterday I installed the proprietary version of “Dropbox” on my ‘Debian / Jessie’ computer named ‘Phoenix’. I had the extra HD space to spare, and also had an existing Dropbox account to link to. But what I soon noticed, was the fact that I was suffering from the same problem many other users of ‘KDE 4′ were having with the newest Dropbox for Linux.

It seems that the Linux versions of Dropbox are tuned to work best under ‘Ubuntu’, not ‘Debian’. And in General, Ubuntu uses either ‘GNOME’ or ‘Unity’ as its desktop manager, which leaves many KDE users having to use the official Command Line Interface for Dropbox.

Mind you, this CLI is not bad as those go, but missing the System Tray Icon was annoying me. I had to install ‘libappindicator…’ as well as ‘python-appindicator’ from the package manager, and even after having done that, and after having restarted Dropbox using the CLI, the systray icon did not appear for me, because in recent Dropbox versions, only the ‘Nautilus’ support is included. Nautilus is the Ubuntu / GNOME counterpart, for what ‘Dolphin’ does under KDE. Luckily, there is an open-source Dolphin plugins package named

‘kdesdk-dolphin-plugins’

But that package assumes we already have Dropbox installed, and does not affect the system tray.

Further, I was disappointed by the fact that most of the other complaints I could Google involved KDE 5, while I needed to solve this problem with KDE 4.

And so after doing some more reading, I wrote the following script:

(Edit 03/31/2016 : ) I would like to thank Darwin Silva, who suggested a solution below, which works better for me, than the solution which I had first posted. Specifically, the solution by Mr. Silva allows Dropbox to animate the icon correctly, to show its status. I apologize for taking so long to test Mr. Silva’s solution, but often have limited time to go after all the things I should be doing on my own computers:


#!/bin/bash
# "Restart Dropbox.sh"

# Allow Dropbox 3.14.7 to show a system-tray icon.
# Works under KDE 4.14...
# Only drawback: Icon has generic page as image.
# Systray Icon Context Menu fully functional.

#DROPBOX_USE_LIBAPPINDICATOR=1
#XDG_CURRENT_DESKTOP=Unity

dropbox stop

sleep 30

dbus-launch dropbox start



This seems to have done the trick for me. But be warned: This will serve us at best, Until the Next Reboot. Possibly, this script may need to be run more often. There is a workaround which fully automates that problem, but that workaround was not worth my while.

It may be possible to edit

~/.config/autostart/dropbox.desktop

But doing so is pointless, because Dropbox will overwrite that file, every time it updates itself…

Dirk