Lamy stylus button very slow to respond since rm1: 2.14.1.861

[Tridens92]

trafficstars

I wasn't sure whether to post this here are in remarkable-stylus repository, but since my guess is that it's related to the hack in terms of solving, I'm posting here.

I'm noticing a significant slowdown in the responsiveness of the device when I'm using the lamy button to use the eraser, switch pens, etc. I've noticed this since installing rm1: 2.14.1.861, and it's still present in .866.

I find myself frequently pressing and holding the erase button and quickly correcting something, only to watch it write over top of what I thought I was erasing while also later seeing the selected tool toggle in the menu.

I know at one point, quite a long time ago, that the delay on the button press was tweaked so that the timing of the press and hold verses press to switch tools vs. double press for undo was in a sweet spot. Any chance that might be why? (reverted to an older delay value?)

Or is there some other reason this would be so delayed in response?

Thanks so much.

[dstango]

Just a shoot in the dark: is the response time the same when wifi is turned on or off? I noticed a kind of general slowness with recent updates, which seemed to be related to some excessive extra sync activity ... plus: seemingly superfluous cached images were kind of filling up the file system and making things slow. Cleaning up thoses and turning off wifi seems to help somewhat with that for me.

[Tridens92]

@dstango , thanks for the ideas. It happens regardless of WiFi status. I almost always run with WiFi off to conserve battery and CPU utilization, as well as minimize unnecessary mini-syncs (I hate that the device syncs every time you open and close a notebook just to update latest page opened).

I'd love to try the cached images cleaning thing. How do I do that? FYI, I'm null at Linux. Thanks

[dstango]

You don't need any Linux-knowledge :-) ... You can use some scp-client to browse the file system, e.g. WinSCP on windows.

In /home/root/.local/share/remarkable/xochitl/ you will find all your documents. Each document is identified by a UUID like "745b8c09-9483-4d14-95ad-1d60e6e65b08". A document can consist of several files, usually .metadata, plus .content .PDF, .epub, ... Usually there are also subdirectories belonging to the documents, especially:

• .thumbnails seems to contain some small-scale version of pages
• .cache (I think) used to be the directory with jpg-renderings of pages, but somehow they seem to have dropped those. Yet on my remarkable (and on my desktop) these directories with image-files remained and ate up space (and probably sync-time).

I found it safe to delete both .thumbnail and .cache-directories without affecting functionality. The .thumbnail will be re-created on demand, so I actually wouldn't delete it ;-) .... the .chache-directory used to be recreated on demand, but it seems to be of no importance any more. Thus I deleted all .cache-directories and got about 2 GB of extra space (I was running out of disk space).

Hope that helps somewhat. The remarkable-wiki might contain more details.

[Tridens92]

Thanks so much for the instructions. Yeah, I use my great file manager for those kind of operations (Directory Opus...amazing!). I'll give it a shot.

I'm a bit skeptical that this will solve the problem I'm seeing, but it seems like it can't hurt!

I'm hoping the slowdown I'm seeing is NOT related to rM-induced bloat or inefficient code, and therefore something @ddvk can solve. Thanks again!

[dstango]

I checked: I'm on the same software version as you on the rm1. And I don't see a difference in responsiveness of the lamy button. (I actually had to get a new lamy pen, as the button stopped working last week :-( ...) So the slowdown you're seeing isn't happening always. One thing I did notice last weekend though is a delay when moving a selection around: after selecting something, then moving it to some other place and releasing it there -- I could see in slow motion the moved lines disappear, have some nothingness for a second or two, and then see the lines appear again. When trying it again right now, it's not happening any more.

I'd guess the tardiness in the UI might be related to whatever background task the rm is doing at certain times. Maybe it'll sort out itself over time ...