You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 31, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 31, 2021. It is now read-only.
repush.sh: Filetransfer broken due to new naming scheme #31
With version 2.5.0.27, repush.sh is no longer able to transfer files onto the remarkable. The reason for this is a change in the setting of teh visibleName in the metadata field. While before this was the filename including the extension, now the metadata is generated with the filename without the extension in the visibleName-field. This causes repush.sh to hang indefinitely as internal checks fail.
The fix for this has to be applied in two locations: This line has to be changed to placeholder_basename="$(basename "$1" .$extension)", as $extension is available from a couple of lines above.
The second location is this, in principle the same fix applies, however, $extension is not set. A quick test of mine using "$(basename "$f" | cut -f1 -d '.')" works like a charm, however, this will fail the moment the filename contains another . besides the one separating the extension. As I have just briefly investigated the problem, I am not sure what's the cleanest fix for this location, hence an issue describing the fix instead of pull requesting a fix. The hack with cut, while working, is certainly not the optimal solution.
Addendum: Due to the handling of directories (dropping a placeholder pdf and turning that into a directory), the aforementioned fix is likely not that straightforward. I currently settled for using basename twice at that very location to first remove a .pdf-extension and then removing a .epub-extension, which works well enough for me. However, this is likely breaking directory pushing, so it likely needs to be implemented a little more carefully, with consideration for the directory pushing implementation.
These fixes worked for me. The common Bash way to get the extension would make it "$(basename "$f" "${f##*.}")". (There's probably a way to simplify it even further, removing the basename, but I don't know it.)
Another issue is that the thumbnails did not show up for me -- they were all blank. This was quick to fix by deleting the thumbnails that were already there (.local/share/remarkable/xochitl/<uuid>.thumbnails/*.jpg) and running systemctl restart xochitl.service. My hypothesis is that when the thumbnails are rendered may have changed to be earlier, rendering the blank placeholder PDF by accident.
These changes aren't quite sufficient when the basename has a dot in it. For a file this.pdf, using a placeholder_basename of either this or this.pdf makes an entry called this. But for a file this.that.pdf, using this.that.pdf results in an entry this.that and using this.that results in an entry this.
There's also some wackiness with EPUBs; I'm not exactly sure why.
That last chunk - from +true to + '[' '!' -z '' ']' just repeats ad infinitum, filling over 20,000 lines in the log file in a matter of seconds before I hit Ctrl-C, and the file is never transferred - though an empty skeleton file appears on the Remarkable.
Clues welcomed, 'cos I have no idea what's broken here!
I'm running the script on an Ubuntu 20.04 64-bit installation, standard Bash shell, and connecting to a Remarkable 2 running 2.5.0.27.
Tell a lie, there's a new glitch: the file transferred correctly, but there's also an empty skeleton file with the same name on there. Tried it again with a second PDF, same thing happened: there's a working copy of the file, and an empty skeleton file which just opens up to a blank "Page 1 of 1".
Activity
mb64 commentedon Dec 27, 2020
These fixes worked for me. The common Bash way to get the extension would make it
"$(basename "$f" "${f##*.}")". (There's probably a way to simplify it even further, removing thebasename, but I don't know it.)Another issue is that the thumbnails did not show up for me -- they were all blank. This was quick to fix by deleting the thumbnails that were already there (
.local/share/remarkable/xochitl/<uuid>.thumbnails/*.jpg) and runningsystemctl restart xochitl.service. My hypothesis is that when the thumbnails are rendered may have changed to be earlier, rendering the blank placeholder PDF by accident.mb64 commentedon Jan 5, 2021
These changes aren't quite sufficient when the basename has a dot in it. For a file
this.pdf, using aplaceholder_basenameof eitherthisorthis.pdfmakes an entry calledthis. But for a filethis.that.pdf, usingthis.that.pdfresults in an entrythis.thatand usingthis.thatresults in an entrythis.There's also some wackiness with EPUBs; I'm not exactly sure why.
Fixes for reMarkable 2, from issue reHackable#31
trou commentedon Feb 10, 2021
I've included your fixes (among others) in this branch: https://github.com/trou/scripts/tree/remarkable_2
I'll do a PR if I get to work around the dots problem.
ghalfacree commentedon Feb 17, 2021
@trou I've run into this problem, and I'm trying to use your modified
repush.sh- but it seems to be hitting an infinite loop.That last chunk - from
+trueto+ '[' '!' -z '' ']'just repeats ad infinitum, filling over 20,000 lines in the log file in a matter of seconds before I hit Ctrl-C, and the file is never transferred - though an empty skeleton file appears on the Remarkable.Clues welcomed, 'cos I have no idea what's broken here!
I'm running the script on an Ubuntu 20.04 64-bit installation, standard Bash shell, and connecting to a Remarkable 2 running 2.5.0.27.
trou commentedon Feb 18, 2021
I had the same bug, which was related to the "." problem @mb64 mentioned.
I updated my branch with a fix. Can you check if it works ?
ghalfacree commentedon Feb 18, 2021
Seems to be working here - the file transferred correctly, no infinite loop. Many thanks!
ghalfacree commentedon Feb 18, 2021
Tell a lie, there's a new glitch: the file transferred correctly, but there's also an empty skeleton file with the same name on there. Tried it again with a second PDF, same thing happened: there's a working copy of the file, and an empty skeleton file which just opens up to a blank "Page 1 of 1".