[Alpha] Kobo-UNCaGED - Calibre wireless connection

[sherman]

Hmm, for the meantime, I'm thinking of skipping the parse epub/kepub metadata step entirely, and just use whatever metadata is available in the Kobo database until I can find/create a more robust solution.

[NiLuJe]

@sherman: Well, -61 is ENODATA (as thrown by fbink_wait_for_usbms_processing), which *sorts of* makes sense ^^.

Now I see what you meant in the PR about dealing with Go Panics in a human-readable way, though :/.

[sherman]

I've attached a test version of KU to this post.

It bypasses the parsing epub/kepub stage, and added some more error checking to run-ku.sh, including logging to .adds/kobo-uncaged/error_log.txt

@church mouse could you try this one please?

Just extract the contents of the zip to the root of your kobo, and replace any existing files.

EDIT: The issues are resolved in v0.4.1 (in post #47). Test version removed.

[church mouse]

Originally Posted by sherman

I've attached a test version of KU to this post.

It bypasses the parsing epub/kepub stage, and added some more error checking to run-ku.sh, including logging to .adds/kobo-uncaged/error_log.txt

@church mouse could you try this one please?

Just extract the contents of the zip to the root of your kobo, and replace any existing files.

sherman, I can report some success.

If I run without a password on Calibre wireless it all seems to work. If I run with a password for Calibre, then I get one of two results:

1. Report of no password found (I am never asked for one, nor does putting my password in the ku.toml make any difference). OR

2. It reports that there is no instance of Calibre detected.

A secondary behaviour I have noted is that if I connect the Kobo to a computer by USB (for instance, to amend the ku.toml to add my Calibre password), when I eject the reader it seems to fire off part of KU resulting in a message "Failed to find/press the Connect button".

[sherman]

It should work via adding the password by the config file. That's the only way to do it, as I don't want to get into dealing with touch input (it's a PITA on Kobo's). I shall double check this, as I made changes, and could have broken it...

I sometimes get the no calibre found myself, not quite sure what causes it, but stopping/starting the wireless service in calibre usually fixes it.

As for the last item, that shouldn't happen. I'm not quite sure what might be causing that.

I would recommend restarting your kobo to make sure you are in a "clean" state. Simply hold the power button until it says it is powered off, wait a few seconds, press and hold again to turn back on.

[sherman]

Just tested with a password in ku.toml, connects fine. I suspect your issue is a more generic connection issue.

I may have to see if I can make that initiating connection more robust. It uses UDP, so there is no guarantee that Calibre 'sees' the hello packet I send, or that KU 'sees' the reply. I may have to try multiple attempts.

[church mouse]

Originally Posted by sherman

Just tested with a password in ku.toml, connects fine. I suspect your issue is a more generic connection issue.

I may have to see if I can make that initiating connection more robust. It uses UDP, so there is no guarantee that Calibre 'sees' the hello packet I send, or that KU 'sees' the reply. I may have to try multiple attempts.

I now have it working with or without a password.

I decided to remove and re-instal KU and the update. I then rebooted my Clara and have tested it successfully with and without a Calibre password.

I still get the "failed to find/press...." message if/when I eject my Clara on a USB connection, but that causes no issues.

Many thanks for your work.

[NiLuJe]

@church mouse: About the USB eject thing, does it happen on *every* USB eject?

(i.e., if you cold boot the device, and do a simple connect/eject session without having ever touched KU in that boot session)?

I assume you don't have anything else installed that would be messing with udev rules?

Mind posting the KFMon log *after* the next time that happens? (tap KFMon's "book", it'll flood your screen, and copy the log to .adds/kfmon/log/kfmon_dump.log).

[church mouse]

Originally Posted by NiLuJe

@church mouse: About the USB eject thing, does it happen on *every* USB eject?

(i.e., if you cold boot the device, and do a simple connect/eject session without having ever touched KU in that boot session)?

I assume you don't have anything else installed that would be messing with udev rules?

Mind posting the KFMon log *after* the next time that happens? (tap KFMon's "book", it'll flood your screen, and copy the log to .adds/kfmon/log/kfmon_dump.log).

1 I did not get the error when my Clara was connected and ejected on USB after a fresh reboot (tested several times). However, after I then ran KU, a USB connection/eject produced the error message. (It seemed to be looking to run the KU update metadata process - FYI, the laptop I connect to for testing does not have my Calibre installation to avoid any chance of a Calibre USB connection spooking it.)

2. Once KU has been run, then the error message pops up after each USB ejection.

3. I am not sure what could be impacting on udev rules. I do have my Kobo patched with some of the "standard" patch changes, but nothing that impacts on USB as far as I know. I also have Koreader installed to run via KFmon, but I have nothing set there to mess with USB.

4. I attach a txt file of tonight's data from the KFMon log, as per your request. I hope it may be of use.

Regards,

[church mouse]

I need to qualify point 2 above. On further testing I am getting the error message the first time I use USB after running KU. Subsequent USB use did not generate the message, unless/until I used KU again.

I can't test more tonight but will do so over the weekend.

[NiLuJe]

@church mouse: I can see a cold boot, two (apparently sane) ejects (a minute apart each), a sane KU run, and the log dump.

Does that track?

Is the KU run actually a spurious one here? Did one actually happen? (Ideally, I'd need a log *after* a spurious KU run on eject ).

(I mean, that one is sufficiently far apart from the eject that it *looks* user-triggered?).

[church mouse]

Originally Posted by NiLuJe

@church mouse: I can see a cold boot, two (apparently sane) ejects (a minute apart each), a sane KU run, and the log dump.

Does that track?

Is the KU run actually a spurious one here? Did one actually happen? (Ideally, I'd need a log *after* a spurious KU run on eject ).

(I mean, that one is sufficiently far apart from the eject that it *looks* user-triggered?).

After the sane KU run there was a short delay before I carried a USB connect/eject, followed by the spurious message, then I generated the log dump.

Over the weekend I will try the process a few more times with longer delays between each step. Tonight, I feel I kind of rushed everything, which isn't fair to you, or a real world scenario.

[sherman]

Ahh.. That might explain some of the weirdness, and it's something I might need to fix. @NiLuJe I use button_scan in wait for content mode to exit USBMS mode. If KU exits without requiring a restart, that means that BS could be potentially still running when the (physical) USB is inserted. I think BS will wait for around 10 seconds before deciding it hasn't found the importing content screen and exits.

That could confuse things...

Methinks that bit of the shell script could use a little reworking.

[NiLuJe]

That's entirely possible, we'll ideally need the matching syslog to cross-reference (ideally w/ BS logging to syslog, too), because what I can tell from the KFMon log is that the KU shell script ultimately exited sanely 2 minutes after it was started, but there was no actual unmount in that period of time .

(So something hanging around for a while seems likely).

[sherman]

I'm in the process of changing the shell script to only use button_scan for USBMS removal if it's actually needed. That should hopefully eliminate button_scan from silently lingering without the user realising it.