Quote:
Originally Posted by davidfor
One thing that hasn't been mentioned is that downloading a book with the browser will get it added to the library. From memory, the browser is running as a separate process, so there has to be some communications between it and nickel. If you can work out what that is, it might be usable.
|
Working directly with the database is a possibility; I have installed sqlite3, but as nickel reads and writes to the database and keeps it open all the time -- there is a certain amount of danger in stopping nickel when it might happen to be accessing the database, and then corrupting it. Nickel does re-read the database before writing, so the odds of corruption are probably small -- but it would be nice to have a better solution.
The web browser is likely a safer approach....
I launched nickel with strace -t -o /mnt/home/ni.log /user/local/Kobo/nickel -platform kobo -skipFrontLoad to follow your advice.
Nickel runs, and then I launched the web browser to get a random book; eg:
http://azardi.infogridpacific.com/resources.html
the "recollections of war" book at the top, and then said view it.
And now the bad news: The first instance of "recoll" in the strace, is as a string already in memory:
Code:
20:38:18 stat64("/mnt/onboard/recollections-of-wartime.epub", 0x7ea1e300) = -1 ENOENT (No such file or directory)
20:38:18 open("/mnt/onboard/recollections-of-wartime.epub", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 26
20:38:18 fcntl64(26, F_SETFD, FD_CLOEXEC) = 0
20:38:18 brk(0x3066000) = 0x3066000
20:38:18 brk(0x30b2000) = 0x30b2000
20:38:18 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3b023000
20:38:18 mremap(0x3b023000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x3b023000
20:38:18 mremap(0x3b023000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x3b023000
20:38:18 mremap(0x3b023000, 4198400, 8392704, MREMAP_MAYMOVE) = 0x3b023000
20:38:18 mremap(0x3b023000, 8392704, 16781312, MREMAP_MAYMOVE) = 0x3b023000
20:38:18 mremap(0x3b023000, 16781312, 33558528, MREMAP_MAYMOVE) = 0x3b023000
20:38:18 brk(0x2392000) = 0x2392000
20:38:18 fstat64(26, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
20:38:18 write(26, "PK\3\4\24\0\0\0\0\0\362\n0Coa\253,\24\0\0\0\24\0\0\0\10\0\0\0mi"..., 29676824) = 29676824
20:38:18 munmap(0x3b023000, 33558528) = 0
20:38:18 close(26) = 0
The name wasn't passed in to nickel from outside, or read from a socket or anything.
I only see occasional netlink calls, and a continual polling of descriptors 6,11,12 via pselect6 before this point in the strace, but no reads from a file descriptor that supply a name....
So, I think there might be shared memory being used between nickel and the web-browser (I'm not very familiar with strace, but this looks like threaded operation or shared memory.)
Since this is a trace of an open for 'write', then I assume we are seeing the web browser save the file via. nickel using shared memory.
The next time the filename gets mentioned, it's being writev() to a file descriptor 35 which was never opened by nickel anywhere in the strace.
Code:
20:39:13 writev(35, [{"l\1\0\1\32\0\0\0\f\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\25\0\0\0com.kobo.adobe.Reader\0", 26}], 2) = 170
20:39:13 read(35, 0x163fa48, 2048) = -1 EAGAIN (Resource temporarily unavailable)
20:39:13 writev(35, [{"l\1\1\1\210\0\0\0\r\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\203\0\0\0type='signal',sender='org.fr"..., 136}], 2) = 280
...
20:39:14 writev(35, [{"l\1\0\0016\0\0\0\24\0\0\0g\0\0\0\1\1o\0\1\0\0\0/\0\0\0\0\0\0\0"..., 120}, {"1\0\0\0file:///mnt/onboard/recollec"..., 54}], 2) = 174
It's also notable that it's usrd as a url to the file, and several adobe style sheets open immediately after it, so this looks like the adobe reader opening the file. There were also several signals sent over a socket, with send(), so this looks like a GUI interface.
Unless the web browser's source code is in the respository, this looks pretty hopeless to me. It's doing it all internally, and not over kernel calls.
To be able to do something like that, will probably require me to to write a plugin that talked to nickel and passed it a file-name via shared memory. I think there are some poker plugins for nickel in the repository, so there might be enough information to trick it into looking for an epub that was supposedly 'downloaded' even if it wasn't. But what little I have found on writing plugins for nickel, basically says it's nearly impossible because its so badly documented.
But now the really good news:
I can see that after I download that random epub book using the web server, that nickel suddenly found my thinkpython.epub book that it had been stuboornly ignoring up and until now, especially with the USB cable plugged in and telnet running.
So, there is a fairly easy and reliable way to trick the kobo into finding new books; eg:
Put a file on / called getbooks.html that looks like:
Code:
<HTML>
<A href="file:///refresh.epub">refresh my booklist now</A>
</HTML>
and then just add a dummy epub book called refresh.epub, which I will simply delete every time I 'upload' it.... or write a shell script to generate the web page dynamically, with a link to the new book already on the hard drive, but under a different directory...
Code:
#!/bin/sh
echo "<HTML><A href=\"file:///$1\">refresh my booklist now</A></HTML>" > /getbook.html
#rm $1 # optionally remove original book as it will be copied to the /mnt/onboard
Just type, file:///getbook.html into the web browser's address bar... tap on refresh my booklist now -- and it works!
