NickelMenu: An integrated launcher for Kobo eReaders

[DNSB]

I looked at that and it was easier just to reboot before connecting since the databases would normally show the -wal and -shm files when they were open and in use. There was no way to tell if the databases would be properly closed during the USB connect process. I did try closing the databases to write the information to the database clearing the -wal and -shm files but there was no way to guarantee they would not be re-opened before I triggered the USB connect.

[JSWolf]

Originally Posted by DNSB

I looked at that and it was easier just to reboot before connecting since the databases would normally show the -wal and -shm files when they were open and in use. There was no way to tell if the databases would be properly closed during the USB connect process. I did try closing the databases to write the information to the database clearing the -wal and -shm files but there was no way to guarantee they would not be re-opened before I triggered the USB connect.

My way of thinking is that you would do the check from the home screen. And if those wal and shm files are not there, go ahead and connect to the computer and if they are, have the Kobo reboot. That should work. The only way to know is to try it. I just am unable to write the code needed to do this with NickelMenu.

If this does get written, then we can recruit some using a Kobo Libra Colour and the latest firmware to test this.

[DNSB]

Jon, please read what I wrote! The -wal and -shm files are normally present when the databases are open since the database are opened in journaled mode. You would need to hook into the USB connection process after the database close code for information about the database close state to be meaningful. Looking at the .kobo directory using ssh or telnet will show the -wal and -shm files are present. The size of them is somewhat important since larger files will take longer to merge into the database during the database close which is why I suspect that the reboot keeps the database corruption error message from happening.

So you check from the home screen. The databases will be open in journaled mode. The -wal and -shm files will be present and your logic says to reboot.

Here's a look at the .kobo directory on my Sage over the network:

kobo login: admin
Password:
login: can't change directory to '/home/admin'

[root@kobo ~]# cd /mnt/onboard/.kobo
[root@kobo .kobo]# ls -al
total 283024
drwxr-xr-x   17 root     root         16384 Jan 24 20:58 .
drwxr-xr-x   13 root     root         16384 Dec 31  1969 ..
-rwxr-xr-x    1 root     root       1061888 Jan 24 20:57 BookReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:08 BookReader.sqlite-shm
-rwxr-xr-x    1 root     root         85968 Jan 25 15:08 BookReader.sqlite-wal

-rwxr-xr-x    1 root     root     287318016 Jan 24 12:57 KoboReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:08 KoboReader.sqlite-shm
-rwxr-xr-x    1 root     root        876160 Jan 25 15:08 KoboReader.sqlite-wal
[root@kobo .kobo]#

Database files after a restart:

-rwxr-xr-x    1 root     root       1062912 Jan 25  2025 BookReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:19 BookReader.sqlite-shm
-rwxr-xr-x    1 root     root             0 Jan 25 15:19 BookReader.sqlite-wal

-rwxr-xr-x    1 root     root     287362048 Jan 25  2025 KoboReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:19 KoboReader.sqlite-shm
-rwxr-xr-x    1 root     root          8416 Jan 25 15:19 KoboReader.sqlite-wal

[compurandom]

Originally Posted by JSWolf

I was thinking if a directory listing can be shown then those with a new Kobo and the newest firmware can see if the database is open or not before connecting to the computer to know if to reboot or not. The script could reboot automatically if the database is open or return that the database is not open.

I've tried that. As long as the kobo UI is open, the database is open, so your idea won't work.

[JSWolf]

Originally Posted by DNSB

Jon, please read what I wrote! The -wal and -shm files are normally present when the databases are open since the database are opened in journaled mode. You would need to hook into the USB connection process after the database close code for information about the database close state to be meaningful. Looking at the .kobo directory using ssh or telnet will show the -wal and -shm files are present. The size of them is somewhat important since larger files will take longer to merge into the database during the database close which is why I suspect that the reboot keeps the database corruption error message from happening.

So you check from the home screen. The databases will be open in journaled mode. The -wal and -shm files will be present and your logic says to reboot.

Here's a look at the .kobo directory on my Sage over the network:

kobo login: admin
Password:
login: can't change directory to '/home/admin'

[root@kobo ~]# cd /mnt/onboard/.kobo
[root@kobo .kobo]# ls -al
total 283024
drwxr-xr-x   17 root     root         16384 Jan 24 20:58 .
drwxr-xr-x   13 root     root         16384 Dec 31  1969 ..
-rwxr-xr-x    1 root     root       1061888 Jan 24 20:57 BookReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:08 BookReader.sqlite-shm
-rwxr-xr-x    1 root     root         85968 Jan 25 15:08 BookReader.sqlite-wal

-rwxr-xr-x    1 root     root     287318016 Jan 24 12:57 KoboReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:08 KoboReader.sqlite-shm
-rwxr-xr-x    1 root     root        876160 Jan 25 15:08 KoboReader.sqlite-wal
[root@kobo .kobo]#

Database files after a restart:

-rwxr-xr-x    1 root     root       1062912 Jan 25  2025 BookReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:19 BookReader.sqlite-shm
-rwxr-xr-x    1 root     root             0 Jan 25 15:19 BookReader.sqlite-wal

-rwxr-xr-x    1 root     root     287362048 Jan 25  2025 KoboReader.sqlite
-rwxr-xr-x    1 root     root         32768 Jan 25 15:19 KoboReader.sqlite-shm
-rwxr-xr-x    1 root     root          8416 Jan 25 15:19 KoboReader.sqlite-wal

Would the -wal file be 0 when the main database is not going to be corrupt on a USB connect or will it always be of some size after you've been using the Kobo?

[DNSB]

Originally Posted by JSWolf

Would the -wal file be 0 when the main database is not going to be corrupt on a USB connect or will it always be of some size after you've been using the Kobo?

The size of the -wal file depends on writing to the database. When it is first opened, the Write Ahead Logging file will start at 0 bytes. In contrast the SHared Memory file starts at 32KB and seldom grows larger. When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and SHM file, to clean up the disk. If you see those files when USB connected, it tells you the database was not properly closed. The -wal file will not grow endlessly, the default is 1000 pages or ~4MB though there are several situations in which the file will grow past that.

[JSWolf]

Originally Posted by DNSB

The size of the -wal file depends on writing to the database. When it is first opened, the Write Ahead Logging file will start at 0 bytes. In contrast the SHared Memory file starts at 32KB and seldom grows larger. When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and SHM file, to clean up the disk. If you see those files when USB connected, it tells you the database was not properly closed. The -wal file will not grow endlessly, the default is 1000 pages or ~4MB though there are several situations in which the file will grow past that.

Would you get a corrupt database if you plugged into the USB port without calibre running to have a look?

[DNSB]

Originally Posted by JSWolf

Would you get a corrupt database if you plugged into the USB port without calibre running to have a look?

I've never seen corruption from mounting the exposed storage but do it at your own risk.

[PeterT]

Originally Posted by JSWolf

Would you get a corrupt database if you plugged into the USB port without calibre running to have a look?

If the database has NOT been closed correctly on the Kobo then any USB connection will cause corruption.

If you look at the udev script on the Kobo that is launced when a USB connection is made, it does an unmount of both the file system that contains the Kobo database and the (no longer supported on new hardware) external SD card.

Simply put the ONLY option might be a modification to the udev script to perform some checking on the size of the wal and shm files, and if non-zero prevent the dismount.

[PeterT]

Originally Posted by DNSB

I've never seen corruption from mounting the exposed storage but do it at your own risk.

I experiened corruption the other week when I had done a connection, mirrored the storage, then a disconnect, followed by a wireless sync and a second connection.

As I mentioned I'm off the opinion that the post wireless sync of importing data had not completed before the second connection.

[remlap]

Anyone know where I can get the stock icons from so I can use three dots for NickleMenu?

Also is menu_main_15505_icon_active still disabled I wouldn't mind having that option to match the red used on colour Kobos

Cheers

[Jadehawk]

Hi everyone, I need some help getting this NickelMenu config working.

I can't get the "dbg_msg" to display after the menu_item command is executed.

The command works and makes the change to my test.conf, I just want a msg to appear to let you know that the kobo will reboot.

Currently it just reboots no message is shown but command is done properly

this are the 6 combination that I have tried.

Number 6 is what I think the closest.

If I remove the "reboot" from the chain, I see the message as intended, with "reboot" as part of the chain, it seems to ignore that "dbg_msg".

What am I missing?

TIA

#=================================================================================================================================================#
# TEST #1 -  Fails to display "dbg_msg" but Command is successful and Reboots
#=================================================================================================================================================#

menu_item	: main		: Sync "ON": cmd_spawn: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_success	: cmd_spawn	: dbg_msg: Sync with ********************** Enabled - Rebooting to complete.
chain_success	: power	: reboot
menu_item	: main		: Sync "OFF": cmd_spawn: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_success	: cmd_spawn	: dbg_msg: Sync with ********************** Disabled - Rebooting to complete.
chain_success	: power	: reboot
	
#=================================================================================================================================================#
# TEST #2 -  Fails to display "dbg_msg" but Command is successful and Reboots --- Used "chain_always"
#=================================================================================================================================================#

menu_item	: main		: Sync "ON"	: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: cmd_spawn	: dbg_msg : Sync with ********************** Enabled - Rebooting to complete.
chain_success	: power	: reboot
menu_item	: main		: Sync "OFF"	: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: cmd_spawn	: dbg_msg : Sync with ********************** - Rebooting to complete.
chain_success	: power	: reboot
	
#=================================================================================================================================================#
# TEST #3 -  Fails to display "dbg_msg" but Command is successful and Reboots --- Used "chain_always" -- Removed "cmd_spawn"
#=================================================================================================================================================#
menu_item	: main		: Sync "ON"		: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: dbg_msg : Sync with ********************** Enabled - Rebooting to complete.
chain_success	: power	: reboot
menu_item	: main		: Sync "OFF" : cmd_spawn: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: dbg_msg : Sync with ********************** Disabled - Rebooting to complete.
chain_success	: power	: reboot
#=================================================================================================================================================#
# TEST #4 -  Fails to display "dbg_msg" but Command is successful and Reboots  -- Used "chain_success" -- Removed "cmd_spawn"
#=================================================================================================================================================#
menu_item	: main		: Sync "ON"	: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_success	: dbg_msg	: Sync with ********************** Enabled - Rebooting to complete.
chain_success	: power		: reboot
menu_item	: main		: Sync "OFF": cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_success	: dbg_msg: Sync with ********************** Disabled - Rebooting to complete.
chain_success	: power	: reboot

#=================================================================================================================================================#
# TEST #5 -  Displays a PID msg instead of "dbg_msg" Command is successful --- Used "chain_always" -- used "cmd_spawn" -- Disabled "Reboot" chain
#=================================================================================================================================================#
menu_item	: main		: Sync "ON"		: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: cmd_spawn		: dbg_msg: Sync with ********************** Enabled - Rebooting to complete.
#chain_success	: power			: reboot
menu_item	: main		: Sync "OFF"	: cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: cmd_spawn		: dbg_msg: Sync with ********************** - Rebooting to complete.
#chain_success	: power			: reboot
#=================================================================================================================================================#
# TEST #6 -  Displays "dbg_msg" Command is successful --- Used "chain_always" -- Removed "cmd_spawn" -- Disabled "Reboot" chain
#=================================================================================================================================================#
menu_item	: main		: Sync "ON": cmd_spawn: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: dbg_msg: Sync with ********************** Enabled - Rebooting to complete.
#chain_success	: power	: reboot
menu_item	: main		: Sync "OFF": cmd_spawn	: quiet:/bin/sed -i 's|**********************|' '/mnt/onboard/Test/Test.conf'
chain_always	: dbg_msg: Sync with ********************** Disabled - Rebooting to complete.
#chain_success	: power	: reboot

[Rid]

Originally Posted by Jadehawk

If I remove the "reboot" from the chain, I see the message as intended, with "reboot" as part of the chain, it seems to ignore that "dbg_msg".

You can try this option to show a reboot message. But you may need to add a sleep step after the } in this script eg: sleep 3 (change the 3, it is in seconds - to how ever long you would like or what actually works... Test this.) to see the previous dbg_msg in your NickelMenu script.

Use notepad++ to create the script but from the menu bar select 'Edit' then 'EOL Conversion' and select the 'Unix (LF)' option.

The NickelMenu syntax might be;

chain_success :cmd_spawn :quiet :/mnt/onboard/.adds/ndbus/NDBus_Reboot.sh

[geek1011]

Originally Posted by remlap

Anyone know where I can get the stock icons from so I can use three dots for NickleMenu?

https://krc.storage.pgaskin.net/

[Jadehawk]

Originally Posted by Rid

You can try this option to show a reboot message. But you may need to add a sleep step after the } in this script eg: sleep 3 (change the 3, it is in seconds - to how ever long you would like or what actually works... Test this.) to see the previous dbg_msg in your NickelMenu script.

Use notepad++ to create the script but from the menu bar select 'Edit' then 'EOL Conversion' and select the 'Unix (LF)' option.

The NickelMenu syntax might be;

chain_success :cmd_spawn :quiet :/mnt/onboard/.adds/ndbus/NDBus_Reboot.sh

I see, so with the current NickelMenu "dbg_msg" & "dbg_toast", what I am aiming to do is not possible, and I will need to do it by running NickelDBus from which I can do it using a script like the one you provided.
I'll give that a shot, Thank you for the info and the script snippet, looks simple for someone like me to maybe figure out or else I'll be back for more help