[Idea] Detect when Nickel has "imported" content
shermp opened this issue · comments
So, hi, it's me again with another "Idea".
It would be great if we could determine when Nickel has finished adding content to the device, so one could perform further processing without the need for user interaction. The idea is basically an extended version of what FBInk does to determine a successful button press.
The process seems to be the following. (1)Connected screen[black] -> (2)Home screen[white] -> (3)Importing content screen[black] -> (4)Home screen[white]
With an appropriate timeout between (2) and (3) (to account for the fact that no new content may be added), do you think watching for this pattern would work as a basic method of determining when we can perform further processing?
Cheers,
Sherman
Hmm, I'm wondering if there may not be a less roundabout way to go about it, possibly database related?
Or a combination of both? Plus the state of the onboard mount point...
As far as I know, when the USB is disconnected, Nickel remounts /mnt/onboard, and then performs the import process, so I'm not sure if there is much info to be gleaned there.
As far as monitoring the database, how? Could inotify be used (I know nothing about that aspect) to monitor db accesses? The main sticking point is how to determine when Nickel is 'done' importing.
Actually, one wonders what Nickel does when one inserts a USB cable into ones device while Nickel is importing books...
Calls for a test one thinks.
EDIT: Nickel seems to ignore it
Hmm, I was pretty exhausted yesterday, so, mushy brain ;).
I had a vague notion that the DB keeps an activity log, and it could be useful, but that doesn't really help much in this instance: doesn't solve the issue of when to check, what exactly to check for, and how to figure out a sync is finished.
That indeed leaves us with screen scraping ;).
I had a vague idea of trying to figure out if there was a way to poll the framebuffer for screen updates, but that was a massive bust :/
So, relying on screen scraping:
Depending on exactly when onboard is remounted vs. the screen updated, waiting for the remount may allow us to switch to poll vs. a hard-timeout for the wait between 1 & 2.
As for 2 & 3, yeah, couldn't come up with anything better than a fixed timeout :/.
Right, now I remember, the DB approach was to try to figure out if there was a way to monitor the importing process so we wouldn't have to make it another hard-timeout between 3 & 4 ;).
Okay, so far, so good... (054481b & 9c56f9d)
I had to switch to ForceWifiOn in the [DeveloperSettings], because EnableDebugServices did not do the trick on my end ;).
But!
Pressing the Connect button . . .
Waiting for the 'USB Connected' screen . . .
On iteration nr. 0 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 1 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 2 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 3 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 4 of 20, pixel (540, 1439) was #000000
. . . appears to have been a success!
Waiting 10s for USB to settle down . . .
Checking fs rootfs mounted on /
Checking fs /dev/root mounted on /
Checking fs none mounted on /proc
Checking fs none mounted on /tmp
Checking fs none mounted on /dev
Checking fs none mounted on /var/lib
Checking fs none mounted on /var/log
Checking fs none mounted on /var/run
Checking fs none mounted on /sys
Checking fs devpts mounted on /dev/pts
Mountpoints changed (iteration nr. 0)
Checking fs rootfs mounted on /
Checking fs /dev/root mounted on /
Checking fs none mounted on /proc
Checking fs none mounted on /tmp
Checking fs none mounted on /dev
Checking fs none mounted on /var/lib
Checking fs none mounted on /var/log
Checking fs none mounted on /var/run
Checking fs none mounted on /sys
Checking fs devpts mounted on /dev/pts
Checking fs /dev/mmcblk0p3 mounted on /mnt/onboard
Yay, onboard is available!
Waiting for the 'Home' screen . . .
On iteration nr. 0 of 20, pixel (540, 1439) was #000000
On iteration nr. 1 of 20, pixel (540, 1439) was #000000
On iteration nr. 2 of 20, pixel (540, 1439) was #000000
On iteration nr. 3 of 20, pixel (540, 1439) was #000000
On iteration nr. 4 of 20, pixel (540, 1439) was #000000
On iteration nr. 5 of 20, pixel (540, 1439) was #000000
On iteration nr. 6 of 20, pixel (540, 1439) was #000000
On iteration nr. 7 of 20, pixel (540, 1439) was #000000
On iteration nr. 8 of 20, pixel (540, 1439) was #000000
On iteration nr. 9 of 20, pixel (540, 1439) was #000000
On iteration nr. 10 of 20, pixel (540, 1439) was #000000
On iteration nr. 11 of 20, pixel (540, 1439) was #000000
On iteration nr. 12 of 20, pixel (540, 1439) was #000000
On iteration nr. 13 of 20, pixel (540, 1439) was #FFFFFF
Waiting for the 'Content Import' screen . . .
On iteration nr. 0 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 1 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 2 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 3 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 4 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 5 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 6 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 7 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 8 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 9 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 10 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 11 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 12 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 13 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 14 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 15 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 16 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 17 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 18 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 19 of 20, pixel (540, 1439) was #FFFFFF
[FBInk] Couldn't detect the Import screen, maybe there was nothing to import?
Now let's see what happens if I actually add something to import ;).
Yay, onboard is available!
Waiting for the 'Home' screen . . .
On iteration nr. 0 of 20, pixel (540, 1439) was #000000
On iteration nr. 1 of 20, pixel (540, 1439) was #000000
On iteration nr. 2 of 20, pixel (540, 1439) was #000000
On iteration nr. 3 of 20, pixel (540, 1439) was #000000
On iteration nr. 4 of 20, pixel (540, 1439) was #000000
On iteration nr. 5 of 20, pixel (540, 1439) was #000000
On iteration nr. 6 of 20, pixel (540, 1439) was #000000
On iteration nr. 7 of 20, pixel (540, 1439) was #000000
On iteration nr. 8 of 20, pixel (540, 1439) was #000000
On iteration nr. 9 of 20, pixel (540, 1439) was #000000
On iteration nr. 10 of 20, pixel (540, 1439) was #FFFFFF
Waiting for the 'Content Import' screen . . .
On iteration nr. 0 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 1 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 2 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 3 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 4 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 5 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 6 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 7 of 20, pixel (540, 1439) was #FFFFFF
On iteration nr. 8 of 20, pixel (540, 1439) was #000000
Waiting for the 'Home' screen . . .
On iteration nr. 0 of 1200, pixel (540, 1439) was #000000
On iteration nr. 1 of 1200, pixel (540, 1439) was #000000
On iteration nr. 2 of 1200, pixel (540, 1439) was #000000
On iteration nr. 3 of 1200, pixel (540, 1439) was #FFFFFF
\o/
So, barring a better idea, there's currently a 5min timeout on the import process itself (every other check uses the same 5s timeout, which appears to do the job just fine)...
I may fiddle with things a bit to raise the granularity of the polling there, because 250ms might be a tad aggressive for that step...
(It was very very short in my log because that was a single tiny PNG ;p).
Just a question, have you made it so that it is possible to perform scan & press and then detect import later. As you know, my use case is to do naughty stuff behind Nickel's back while the fs is unmounted.
Maybe button_scan and detect_import (example name) need to be separate functions?
Another thought, if you're checking for import, can you add an option to simulate removing the usb plug?
@shermp: Since the "later" bit is essentially free (it's a poll on /proc/mounts waiting for onboard to come back up), it's currently an extra optional step in fbink_button_scan after a sucessful press.
I couldn't quite figure out a use-case where separating the two would make sense, but, again, mushy brain, so if something comes up, that's perfectly doable ;).
As for the usb unplug bit, that's probably trivial, but I'm not quite seeing the potential use, and where exactly it would fit?
Oh, hi, I'm stupid. If we're blocking and you're single-threaded, you can't actually do stuff, duh. :D.
My use case is to wait for button_scan to return telling me it has pressed the button (or not). I can then do stuff, and when I'm finished, I 'unplug' USB. The way it appears you currently have it means that there is no way of knowing when the connect button press occurs..
In go, being single threaded isn't such an issue, but I still need to know when it's safe to start doing stuff.
Right, the current state of affairs should make more sense ;).
And I got rid of another hard-timeout in the process (when waiting for onboard to first get unmounted, if need be). That should make the whole thing consistent and prevent spuriously waiting for mountpoint changes when that makes no sense (which would be bad, because there's no timeout on that poll).
I think leaving the fake USB unplug event to you makes more sense with the current design, but as you've noticed, I'm kinda slow tonight, so do elaborate if you have something to say on the subject ;).
The idea with getting fbink_wait_for_usbms_processing() to do the 'unplug' would be for safety, to ensure that things are in a known state before calling the function. Otherwise the time between 'unplugging' and calling the function could theoretically have some sort of state change.
Right now it's double-checking that the background is black (i.e., still on the "Connected" screen), and waiting for onboard to be unmounted if it isn't already (something which might already be a tiiiiiny bit race-y in itself, c.f., 4233144).
Can you think of anything else in terms of state change that might have an impact?
Not really I suppose.
Thank you very much for implementing this. It will be useful for both kobo-rclone (when I get back to it), and the new project I'm working on.
In case the tone wasn't clear, that wasn't intended as a shut-down, that was a genuine inquiry :).
If the need ever arises, hiding that behavior behind a switch is trivial enough ;).
Happy to help! As usual, if something feels weird or clunky to use, fire away!
Okay, after a good night's sleep, doing the unplug event from within wait_for_usbms makes much more sense ;).
Otherwise, if Nickel happens to be really snappy, we risk Nickel remounting onboard before the initial check in wait_for_usbms, which relies on onboard being unmounted ;).
That was my main concern, and why I suggested it.
Landed in v1.7.0 ;).