Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to save reading progress and highlights #19

Open
lz233 opened this issue Mar 24, 2022 · 9 comments
Open

Failed to save reading progress and highlights #19

lz233 opened this issue Mar 24, 2022 · 9 comments

Comments

@lz233
Copy link

lz233 commented Mar 24, 2022

After opening an epub file, setting some highlights and then restart Plato, it will be gone.

@lz233
Copy link
Author

lz233 commented Mar 24, 2022

Just found out that click "Quit" manually is needed, It's no problem now.
But is it possible to save progress automatically? I use remux as launcher, it provide "kill" button, so click "quit" is a unnatural behavior.

@LinusCDE
Copy link
Owner

I'll look into doing an autosave for this. I guess, for the Kobo, this is not a real issue, since using plato there would be more permanent afaik.

Wanted to fix a self-made bug I encountered today anyway (eraser side tapping twice, finger up == finger down?) in the next few days. So might as well fix this as well and make a new full release of it.

cc @baskerville

@LinusCDE
Copy link
Owner

Maybe a quick and easy fix would be to add a "Save" option to the main menu. So one can decide saving explicitly. Maybe also as a selectable interval.

@baskerville
Copy link

The reading states can already be manually saved with Database|Filesystem → Flush (in the library menu).

Properly solving the original problem would require changes in both Plato and remux:

  • Plato would need to handle SIGTERM.
  • remux would need to use SIGTERM instead of SIGKILL when killing apps.

@LinusCDE
Copy link
Owner

LinusCDE commented Mar 25, 2022

Didn't actually know about this option. That's nice to know.

And yeah, killing with remux isn't healthy for apps. While I really like the option to just get rid of apps, I kinda expected that it would just sigkill them since otherwise they might clutter up the screen (I know first hand that everything else doesn't work when SIGSTOP'ed since the app would run in order to react to other signals).

@raisjn The best case would probably be to be able to have remux do your proposed "nice killing" and have plato just handle SIGINT and/or SIGTERM which would be an easy fix. But this would complicate things more, make misbehaving possible as you said and would probably require some further meddling/alteration of the current draft launcher file format.

Proposed solution: How about remux sending to-be-paused apps a signal like USR1 and delay the pause for e.g. 100ms (or wait for the signal to be handled if possible). That way:

  • plato could flush the database always right before pause
  • a kill would not be a problem
  • apps/launchers not using this behaviour should not affect anything

@lz233
Copy link
Author

lz233 commented Mar 25, 2022

So it's a divergence on design, both Plato and remux are fine, no change should be taken from my perspective.

@raisjn
Copy link

raisjn commented Mar 25, 2022

iiuc, you can mmap the save progress file into memory and writes to it will be persisted even if the process is killed

@baskerville
Copy link

I didn't know about the aforementioned mmap behavior, thank you for the tip.

@raisjn
Copy link

raisjn commented Mar 26, 2022

Proposed solution: How about remux sending to-be-paused apps a signal like USR1 and delay the pause for e.g. 100ms (or wait for the signal to be handled if possible). That way:

yeah, i can do something like this, i'll look into it. i think i'll give 100ms or so then send SIGKILL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants