koreader as default for every epub except those from .acsm

[EastEriq]

I like koreader, so my /mnt/ext1/system/config/extensions.cfg is very partial to it. However I also borrow DRM books from libraries, so I get .acsm. When I tap the acsm file icon on the home screen, or the entry in the librarian, the content is downloaded, the acsm file is deleted and the reader goes on opening the resulting epub. As expected, but since extensions.cfg says

epub:@EPUB_file:1:koreader.app,eink-reader.app:ICON_EPUB

then koreader is immediately called up for opening the book, and it complains that it cannot read the encrypted content. Also this is expected. So I have to close the book, go to the librarian, search for the book again, long press on it, and choose Open with PB Reader. This is firmware 5.2, long press does not even offer the choice on the home screen, and it's a bit of a PITA. True that then the preferred program for opening the book is remembered (stored in handlers.cfg), but still a nuisance.

Is anyone aware of any trick I could play for triggering pbreader only on epubs coming from acsm downloads, while leaving koreader as preferred default for all others?

[dmalinovsky]

I have the same issue, so I simply unassigned KOReader from ePubs and open them from the KOReader itself. You can assign a key to switch between the applications — it's helpful after downloading new books via Send to Pocketbook feature.

[JSWolf]

Thread belongs in the KOReader forum.

[EastEriq]

Originally Posted by dmalinovsky

I have the same issue, so I simply unassigned KOReader from ePubs and open them from the KOReader itself. You can assign a key to switch between the applications — it's helpful after downloading new books via Send to Pocketbook feature.

Thanks, but I think that this won't cut it for me - I still like that all the public domain epubs which I download open by default with KOR. If there was another solution, I'd prefer.

[EastEriq]

Originally Posted by JSWolf

Thread belongs in the KOReader forum.

Don't think so. It's not about KOReader in particular, rather it's about the steps in which Pocketbook processes acsm, and if it is possible to change that sequence.

[neil_swann80]

Originally Posted by EastEriq

When I tap the acsm file icon on the home screen, or the entry in the librarian, the content is downloaded, the acsm file is deleted and the reader goes on opening the resulting epub.

Interesting problem. What directory is the epub file that the acsm generates downloaded to?

[EastEriq]

The final epub goes in the same directory where the acsm file is, before it's deleted. IIRC sometimes you can see the librarian updating the percentage of the download in progress on the icon of the newly created epub, which would give the impression that no intermediate temporary file is involved, but I can't really tell, it may be just an animation. Then you see the librarian changing the file name with the book title and rendering the cover image, before the default reading program opens.

[neil_swann80]

Originally Posted by EastEriq

The final epub goes in the same directory where the acsm file is, before it's deleted. IIRC sometimes you can see the librarian updating the percentage of the download in progress on the icon of the newly created epub, which would give the impression that no intermediate temporary file is involved, but I can't really tell, it may be just an animation. Then you see the librarian changing the file name with the book title and rendering the cover image, before the default reading program opens.

If you long-press on the item on the home screen or library do you have an option for "Book Info"? As this should list the filename which contains the directory path of the file. Can you do that for the acsm and epub files to confirm what directories they are? If it's a unique directory that could provide a means of distinguishing/separating the epubs.

What is the process for acquiring the acsm files on your pocketbook?

[EastEriq]

Originally Posted by neil_swann80

If you long-press on the item on the home screen or library do you have an option for "Book Info"? As this should list the filename which contains the directory path of the file. Can you do that for the acsm and epub files to confirm what directories they are? If it's a unique directory that could provide a means of distinguishing/separating the epubs.

I am sure that it is the same directory, [ETA: not true, the resulting epub gets always written in /mnt/ext1/Digital Editions] because normally I use the librarian to browse by folder, and because I know where I copy the acsm to and where the resulting epub file sits in the tree. And well, yes, I could from now on take the habit of copying the acsms and only them in a specific dir rather than all over the place according to some other criterium of mine. But still, how could the extensions.cfg mechanism discriminate by dir?

What is the process for acquiring the acsm files on your pocketbook?

I do not have a fixed way which I would be satisfied intercepting. Most conveniently I get the acsm with a computer and transfer it via samba/wifi, but sometimes I use sync Dropbox Pocketbook and some other I copy via usb. I would be looking at what is happening on the reader after the file is there and I tap on it. If the process was handled by a shell script sitting in some secret directory, we could see about tampering (I have root).

[neil_swann80]

Originally Posted by EastEriq

I could from now on take the habit of copying the acsms and only them in a specific dir rather than all over the place according to some other criterium of mine. But still, how could the extensions.cfg mechanism discriminate by dir?

We could leave extensions.cfg as-is, the default for epubs remaining as Koreader. But we could run a check for the directory the epub is in and (if the check matches the dedicated directory) create a entry for that specific epub in handlers.cfg with PBReader as the default.

I was thinking a few lines of code at the start of the koreader launcher file in /mnt/ext1/system/bin/koreader.app may suffice.
Run the check, if the check matches the dedicated directory we write to handlers.cfg and exit without launching koreader. You'd then have to click on the book a second time for it to launch with PBreader. If the check does not match the dedicated directory, no writing to handlers.cfg and Koreader launches the epub as usual.

[neil_swann80]

Try using this custom version of /mnt/ext1/system/bin/koreader.app:

#!/bin/sh

bookDir=$(dirname "$1")
openWith="/mnt/ext1/system/config/handlers.cfg"

if [ "$bookDir" == "/mnt/ext1/Digital Editions" ]; then
  echo "${1}:eink-reader.app" >> $openWith
  exec /ebrmain/cramfs/bin/eink-reader.app "$1"
else
  exec /mnt/ext1/applications/koreader.app "$@"
fi
exit

[EastEriq]

Thanks, I will check it in due time, I'm on the move today.

Another idea I had is that if there was a small application capable of determining whether the epub is DRMed or not, that one could be set as the default opener, in a script which then calls either eink-reader or koreader depending on the result.

Still another one is that koreader does detect that an epub is DRMd (because it reports it), so a user patch cold be that it closes itself launching eink-reader instead.

[neil_swann80]

Originally Posted by EastEriq

Another idea I had is that if there was a small application capable of determining whether the epub is DRMed or not, that one could be set as the default opener, in a script which then calls either eink-reader or koreader depending on the result.

You could try testing for the presence of rights.xml or encryption.xml within the epub container. I think epub3 files are trickier and can contain these files anyway even if there's no DRM.

Originally Posted by EastEriq

Still another one is that koreader does detect that an epub is DRMd (because it reports it), so a user patch cold be that it closes itself launching eink-reader instead.

That would require a dedicated koreader plugin, would be plenty of work.

If you make any progress please post it here, I'd be interested to see your approach.

[EastEriq]

I've not forgotten this one, but I haven't advanced much either.

In principle I would have staid away form patching /mnt/ext1/applications/koreader.app or /mnt/ext1/system/bin/koreader.app, on the ground that OTA might overwrite them, so I thought of finding out what happens when the system deals with an .acsm. On my device there is no hope anymore that the firmware gets an OTA update, so in a way that would be more permanent.

In a crude way, I tried to identify what is launched when clicking on a .acsm by ssh'ing into the device, typing

P=""; while [ 1 ]; do P1=$P; P="`ps | tail -6 | head -1`"; if [ "$P" != "$P1" ]; then echo "$P"; fi; done

on the shell and looking at the output. I got essentially:

17385 sreader  62912 S <  /ebrmain/bin/acsm_fulfill.app
19319 sreader      0 Z <  [acsm_fulfill.ap]
19320 sreader  53176 R <  /ebrmain/bin/adobescanner.app /mnt/ext1/Digital Editions/Thirteen Moons.epub  0 0 -metadata
19496 reader   46060 S <  /ebrmain/bin/new_task.app /mnt/ext1/system/bin/koreader.app koreader.app Thirteen Moons.epub 128 /mnt/ext1/system/bin/koreader.app /mnt/ext1/Digit
19512 reader    1568 S <  {koreader.app} /bin/sh /mnt/ext1/system/bin/koreader.app /mnt/ext1/Digital Editions/Thirteen Moons.epub
19544 reader    4288 R <  {reader.lua} ./luajit ./reader.lua /mnt/ext1/Digital Editions/Thirteen Moons.epub

(I have omitted lines which are repeated multiple times due to the process changing state between R, S, D and Z), and sync, and sleep 30 and the like which seem to be running in the background anyway. The file in question here was one of the samples downloadable from https://www.adobe.com/solutions/eboo...k-library.html .

Having seen that, though, I'm a bit out of ideas. /ebrmain/bin/acsm_fulfill.app, /ebrmain/bin/adobescanner.app and /ebrmain/bin/new_task.app are all compiled binaries. `strings` can show interesting things about them, but nothing which gave me clues. Only the latter called without arguments says

# /ebrmain/bin/new_task.app
Usage: new_task.app path appname name flags

but I don't understand what decides to pass koreader.app as argument in this callchain. extensions.cfg is apparently looked into just before that, but not transparently. If I found out how, I thought I could plug in there...

[EastEriq]

Miscellaneous observations:

1. there are alsto DRMd pdfs to be considered;
   
2. /ebrmain/config/extensions.cfg contains this line:
   

   acsm:@ACSM_file:1:eink-reader.app:ICON_ACSM

3. for f in `ls /ebrmain/cramfs/bin/*.app`; do strings  $f | grep extensions.cfg  ; done

   tells me that the string extensions.cfg is in none of the .app files (which contain anyway many global.cfg, as well as other .cfg files)