Settings.toml/plato.toml not parsed

[ozel]

While trying to get the article_fetcher hook working, I noticed that this fork of plato cannot read its own main settings file, linked from /opt/etc/plato.toml:

reMarkable: ~/ rm2fb-client plato     
Can't load settings: Cannot parse TOML content from Settings.toml.

Tested with the V0.9.13 release, shipped via toltec/entware.
Is it maybe related to this fix 4e720aa which came just after the package release? I haven't built this repo myself, yet.

It regularly even overwrites the settings file with defaults which made it very confusing to debug the article_fetcher hook. Is that a fallback feature of rust?
According to original plato docs, the main settings file should be only edited when plato is in 'shared mode', but I guess that is specific to Kobo readers. I also tried editing the settings file while plato was not running with the same behaviour.

This is probably unrelated, but could there be another issue with network access from this plato fork on the rm2? After putting the hook's setting file in the correct default place (/opt/lib/plato/bin/article_fetcher/ and not ~/bin/... as one could assume) the article_fetcher reports at least "Establishing a network connection." and sometimes "Waiting for the network to come up." but always returns with nothing.

Thanks for this port, btw, I really like Plato on the RM2!

[LinusCDE]

I honestly didn't use the article fetcher yet, so I have next-to-no knowledge on that. If the assumed location is indeed wrong, I would definitely need to fix that for the reMarkable as well.

The commit you mentioned was an unrelated issue if I'm not mistaken. Read 76344f5#r45951005 . I made this change because saving the file failed, but this was caused because I forgot to ensure that structs are at the bottom in the Settings struct that defines the toml file (new changes put primitive types below it and I didn't know the exact problem). I reverted it in the commit you mentioned to work as intended, but I don't think that releasing a new version with that commit has any urgency.

Maybe the article fetcher attempts to save the toml file somewhere else? That could explain the fail. Also not sure why loading is affected.

To be certain I made an impromptu recreation of the ipkg file for the newest commit. Can you confirm the same error with this one?

[baskerville]

This is probably unrelated, but could there be another issue with network access from this plato fork on the rm2? After putting the hook's setting file in the correct default place (/opt/lib/plato/bin/article_fetcher/ and not ~/bin/... as one could assume) the article_fetcher reports at least "Establishing a network connection." and sometimes "Waiting for the network to come up." but always returns with nothing.

What happens is that the fetcher is waiting for an event (of type network) that it never receives. As mentioned in doc/HOOKS.md, this event is sent to all the fetchers when the network becomes available. To do so, Plato relies on Event::Device(DeviceEvent::NetUp). This event is generated when the related message is read from /tmp/nickel-hardware-status, a FIFO created by /etc/init.d/rcS. This message is written by /etc/udhcpc.d/default.script.

[LinusCDE]

Thanks for the heads up! I'll look at the existing code and probably patch in a simple replacement for it then (which would likely just check for a default route or iwconfig).

[ozel]

To be certain I made an impromptu recreation of the ipkg file for the newest commit. Can you confirm the same error with this one?

Thanks! Unfortunately, it did not change anything. But could it be also related to how I am calling Plato from the command line in order to see the output?
Anyway, the main behaviour is unchanged, if I edit settings in /opt/etc/plato.toml they get reset to defaults after Plato is started from the oxide launcher once closed again.
Is Settings.toml expected to exist somewhere in /etc? I thought I've previously seen a link from there to /opt/lib/plato/ but it seems gone now.

Regarding the article fetcher, I found out the binary runs just fine (with its own local setting file configured) when started from the CLI with a folder and two times "true" as arguments. I tried to find out where those arguments are passed on to hooks in the main Plato code, but without luck so far.

If one of you cloud point me to more documentation about the Media & Library menus (yes, I've seen the doc folder) on the lover left that would be highly appreciated. For example, how to add a sub-folder? And there is often this mention about two modes, what are they exactly and is this relevant on an rM device? (c.f. my remarks about the 'shared mode' in my initial post, could be really related to this issue as well)

[LinusCDE]

Hi,

sorry for this late response. I think the fix I made did at least fix the parsing (even if it was not best fix to the problem I caused in this fork). If I'm mistaken and the most recent release/toltec-package doesn't work, I should really make a new release asap.

I think the two modes refer to how directories are handled (or how deep). As far as I can remember when I tested it a lot, "filesystem mode" was truer to displaying subdirectories where as "database mode" considers the files more the be a flattened list. I think folders are just treated as tags in both versions (which I'm personally not a fan of, but my usecase was not the typical ereader one).

My personal preference was to have one library entry for each subfolder to not get different mangas mixed up. I switched those from the context menu in the lower left of the home screen.

I think you can just test both modes by changing the type of a "[[library]]" (or similar) entry in the Settings.toml and probably also purging all metadata in that folder. (In toml, all "[[]]" entries basically turn into a list of whatever name was in the double brackets. So you can duplicate that entry as often as you like.)

[LinusCDE]

The newest update should use the old system again. If the error pops up again, feel free to reopen this.