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

new spaced repetition spams the lock screen with notifications #50

Closed
BenWestgate opened this issue Jul 24, 2023 · 14 comments · Fixed by #143
Closed

new spaced repetition spams the lock screen with notifications #50

BenWestgate opened this issue Jul 24, 2023 · 14 comments · Fixed by #143
Assignees
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed performance priority: high issues raised or encountered by 2 or more testers
Milestone

Comments

@BenWestgate
Copy link
Owner

these notifications should not reach the lock screen, spaced-repetition should clear it's own notifications after they display, it should not clear other notifications however.

@BenWestgate BenWestgate added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers priority: medium Issues raised by 1 tester labels Jul 24, 2023
@BenWestgate BenWestgate added priority: high issues raised or encountered by 2 or more testers and removed priority: medium Issues raised by 1 tester labels Aug 12, 2023
@BenWestgate
Copy link
Owner Author

Escalating priority to high because if you leave your computer long enough (24-72 hours) without restarting the notifications will make it run out of memory. This means spaced repetition trainer is slowing down IBD too!

@extrapockets
Copy link

I ran into this problem and had to abort the IBD process. Currently I am trying again. I'm having Bitcoin Core download blocks, but this time I am not creating/restoring a wallet - and keeping Bails closed. I'll check in 10 hours and see what happens. Using an older Lenovo Thinkpad and a SanDisk USB3.0 drive with 30GB storage.

@BenWestgate
Copy link
Owner Author

BenWestgate commented Aug 22, 2023 via email

@BenWestgate
Copy link
Owner Author

A related improvement:

In discussions with the codex32 authors, the spec for importing and confirming shares will require custom Gtk dialogs.

This means the spaced repetition can check if you're on a typing step and not bother you until you submit your string.

@extrapockets
Copy link

Came back to check in. Bitcoin Core has finished catching up after 3 weeks of nonstop block downloading (with a few restarts when it's seemed extra slow). Common block download rates I saw were from 0.2% to 0.05%. Everything is working now.

@BenWestgate
Copy link
Owner Author

Thanks for this report @extrapockets!

Would you mind sharing your system's Total RAM and the model of USB stick used?

Very slow synchronizations like this are unfortunately expected from 4 GB laptops using slow USB sticks it would be the same (or worse) to an internal HDD with low RAM.

Another tester with an 8GB laptop using a budget Kingston model synced in under 4 days. And with 16GB of RAM and fast enough internet you can sync in hours.

@BenWestgate
Copy link
Owner Author

BenWestgate commented Sep 9, 2023

You can significantly improve the sync time to just a few days, even with 4GB ram by choosing one of the SSD-like flash drives here:

https://github.com/BenWestgate/Bails/blob/master/FAQ.md#what-type-of-flash-drive-should-i-get

I personally synced a 2010 MacBook with 3.6GB RAM and a Core 2 Duo CPU in 2021 in 3.5 days using an external SSD (USB 2.0 of course).

A side benefit of a faster drive (vs more RAM) especially if you use Bails frequently is starting Tails is much quicker, and catching up will reach full speed faster, versus using a cheap USB and getting more RAM.

But the Samsung FIT is $11 and performs very well, likely 2-3 day syncs on 8GB ram and under 2 weeks on 4GB.

@extrapockets
Copy link

The RAM warnings during setup helped me to understand that it would take a while. I used a laptop that I was able to keep running without interruption: 4GB RAM, i5-4300U CPU, 128GB Disk Capacity. The Thumbdrive is a SanDisk 128GB, but I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

@extrapockets
Copy link

You can significantly improve the sync time to just a few days, even with 4GB ram by choosing one of the SSD-like flash drives here:

https://github.com/BenWestgate/Bails/blob/master/FAQ.md#what-type-of-flash-drive-should-i-get

I personally synced a 2010 MacBook with 3.6GB RAM and a Core 2 Duo CPU in 2021 in 3.5 days using an external SSD (USB 2.0 of course).

A side benefit of a faster drive (vs more RAM) especially if you use Bails frequently is starting Tails is much quicker, and catching up will reach full speed faster, versus using a cheap USB and getting more RAM.

But the Samsung FIT is $11 and performs very well, likely 2-3 day syncs on 8GB ram and under 2 weeks on 4GB.

I'm planning to clone BAILS next, so I'll get a SSD-style recommend drive to speed up that process and do more testing.

@BenWestgate
Copy link
Owner Author

The RAM warnings during setup helped me to understand that it would take a while.

By that you mean the notification that said:

Your computer is low on memory.
Additional RAM might significantly improve sync performance.

Or something I wrote in the FAQ?

I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

Tails doesn't touch the internal storage at all, so only the USB stored blockchain data. It may have run faster, even on 4G ram, if it had used more of your USB's capacity.

Can you type lsblk in terminal and tell me the SIZE of sda and sda2?
Then type df -h ~/Persistent/.bitcoin and give me Size, Used and Avail

@BenWestgate
Copy link
Owner Author

I'm planning to clone BAILS next

Clone has not been implemented into the alpha yet. Before you make any wallets, however, you can make clones safely:

Use tails-cloner (formerly Tails Installer if you're on an old Tails version), and a target USB of equal or greater size.

Roll dice or use head -c10 /dev/urandom | base32 to set a temporary passphrase for their new persistent storage. Have them change it to a more memorable diceware passphrase in the Persistent Storage application.

Making clones after you already have secrets on your Bails requires encrypting your data before tails-cloner runs, and it would be easier to have that temporary passphrase displayed without using terminal or even to get a suggestion like when creating persistent storages.

@extrapockets
Copy link

The RAM warnings during setup helped me to understand that it would take a while.

By that you mean the notification that said:

Your computer is low on memory.
Additional RAM might significantly improve sync performance.

Or something I wrote in the FAQ?

I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

Tails doesn't touch the internal storage at all, so only the USB stored blockchain data. It may have run faster, even on 4G ram, if it had used more of your USB's capacity.

Can you type lsblk in terminal and tell me the SIZE of sda and sda2? Then type df -h ~/Persistent/.bitcoin and give me Size, Used and Avail

Yes, the low memory warning pop-up, and also I had read the README.

$lsblk output:
sda 8:0 0 119.2G 0 disk
├─sda1 8:1 0 498M 0 part
├─sda2 8:2 0 4G 0 part
├─sda3 8:3 0 110.8G 0 part
└─sda4 8:4 0 4G 0 part
sdb 8:16 1 28.6G 0 disk
├─sdb1 8:17 1 8G 0 part /lib/live/mount/medium
└─sdb2 8:18 1 20.6G 0 part
└─TailsData_unlocked
253:0 0 20.6G 0 crypt /run/nosymfollow/live/persistence/TailsData_un
zram0 254:0 0 3.7G 0 disk [SWAP]

$df -h ~/Persistent/.bitcoin output:

size: 21G
used: 9.8G
avail: 9.4G
use: 51%

NOTE: I was incorrect on the thumbrive size in my earlier post. The thumbdrive I'm using for BAILS is 32GB, not 128.

@BenWestgate BenWestgate added bug Something isn't working performance labels Mar 27, 2024
@BenWestgate BenWestgate self-assigned this May 15, 2024
@BenWestgate BenWestgate added this to the L1 (BETA) milestone May 15, 2024
BenWestgate added a commit that referenced this issue May 15, 2024

Unverified

This user has not yet uploaded their public signing key.
Resolves #50
BenWestgate added a commit that referenced this issue May 16, 2024
* Fine tune environment variables

* nest bin,lib,share,state under .local, add environment variables

* nest dirs under .local and move config to .config

* fix spaced repetition spam

Resolves #50

* Remove unused files, & PR deps post, fix templates

* fix typo in ignore_paths for shell linter

* Update install-core

* remove .idea folders to fix codeQL bug

* more deleting .idea folders

* remove dot from folder names to fix codeql

* rename the non dot folders to dot in `b` script

This will allow default CodeQL to scan my library.
@BenWestgate
Copy link
Owner Author

Increasing timeout only somewhat helped the issue I have found the root cause:

Your suspicion is correct: when the screen is locked, pinentry-gnome3 is likely to cancel immediately rather than wait for the timeout period to elapse. This is because pinentry-gnome3 requires an active graphical environment to display its dialog and accept user input. If the screen is locked, the necessary environment for displaying the dialog is not available, causing the program to cancel the operation right away.

This immediate cancellation can lead to a large number of notifications because each attempt to prompt for the passphrase fails instantly, and the script may retry frequently, creating numerous notifications in quick succession.

To handle this, you might consider modifying your script to detect whether the screen is locked before invoking pinentry-gnome3. Here is a possible modification:

Checking if the Screen is Locked

You can use a utility like gnome-screensaver-command or xdg-screensaver to check if the screen is locked:

is_screen_locked() {
    if gnome-screensaver-command -q | grep -q "is active"; then
        return 0
    else
        return 1
    fi
}

get_passphrase() {
    # Check if the screen is locked
    if is_screen_locked; then
        echo "Screen is locked, postponing passphrase prompt."
        return 1
    fi

    passphrase="$(echo -e "SETPROMPT $enter Persistent Storage passphrase:\nGETPIN" | pinentry-gnome3 --timeout 99999 2>&1 | grep D | cut -c3-)"
    if [ -n "$passphrase" ]; then
        return 0  # Success: passphrase is not empty
    else
        return 1  # Failure: passphrase is empty
    fi
}

Example Script with Screen Lock Check

Here is how you can integrate the screen lock check into your script:

#!/bin/bash

min_interval=5
interval=30
exp=1
enter='Enter'
sleep $interval

is_screen_locked() {
    if gnome-screensaver-command -q | grep -q "is active"; then
        return 0
    else
        return 1
    fi
}

get_passphrase() {
    if is_screen_locked; then
        echo "Screen is locked, postponing passphrase prompt."
        return 1
    fi

    passphrase="$(echo -e "SETPROMPT $enter Persistent Storage passphrase:\nGETPIN" | pinentry-gnome3 --timeout 99999 2>&1 | grep D | cut -c3-)"
    if [ -n "$passphrase" ]; then
        return 0
    else
        return 1
    fi
}

while true; do
    get_passphrase
    if [ $? -eq 0 ]; then
        unset passphrase temp_passw
        interval=$((interval * (RANDOM % 2500 + 2000) / 2 ** exp / 1500))
        (( interval < min_interval )) && interval=$min_interval
        sleep $interval
        exp=0
        enter='Enter'
    else
        unset passphrase temp_pass
        zenity --notification --text="Passphrase does not match or screen is locked.\nTry again."
        sleep 2
        enter='Re-enter'
        ((exp = (exp == 0) ? 2 : exp + 1)) 
    fi
done

By including the is_screen_locked function, the script now checks if the screen is locked before attempting to prompt for the passphrase, thus avoiding immediate cancellations and excessive notifications when the screen is locked.

@BenWestgate BenWestgate reopened this May 17, 2024
@BenWestgate
Copy link
Owner Author

If the screen is locked. No notification should be generated and the current interval should simply continue looping until the screen is unlocked again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed performance priority: high issues raised or encountered by 2 or more testers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants