xochitl 2.5.0.27 No longer picking up the new image after download
Snowflake6 opened this issue · comments
Seems something may have changed with the 2.5.0.27 update that I received this morning. I use the Lorem option, but it seems the image, while it's being downloaded, will not change until the reMarkable is rebooted. Log showing correct download behaviour:
Dec 09 14:31:47 reMarkable systemd[1]: Stopping Picsum...
Dec 09 14:31:47 reMarkable systemd[1]: Stopped Picsum.
Dec 09 14:31:53 reMarkable systemd[1]: Started Picsum.
Dec 09 14:32:05 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"off"] []]]
Dec 09 14:32:13 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"no-carrier"] []]]
Dec 09 14:32:18 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"dormant"] []]]
Dec 09 14:32:18 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"carrier"] []]]
Dec 09 14:32:19 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"degraded"] []]]
Dec 09 14:32:24 reMarkable renews.arm[741]: [dbus message: [org.freedesktop.network1.Link map[OperationalState:"routable"] []]]
Dec 09 14:32:24 reMarkable renews.arm[741]: [Network online]
Dec 09 14:32:30 reMarkable renews.arm[741]: [Beginning download]
Dec 09 14:32:33 reMarkable renews.arm[741]: [Adjusting image]
Dec 09 14:32:37 reMarkable renews.arm[741]: [Image saved to /usr/share/remarkable/suspended.png]
But the suspended.png file downloaded is not the one displayed... The last one downloaded before a reboot is the one displayed.
seems like xochitl is caching suspended.png at load as of 2.5, which means that images don't register until the device is rebooted :-(
It is using it somewhere, as it picks the image up after a reboot. So it must be getting cached somewhere.
After a bit more testing (rM2), I'm seeing the same behaviour. The updated suspended.png is displaying in sleep after a reboot.
Likely the only solution here would involve copying the image contents into xochitl’s memory map, which is likely a massive PITA and would involve some seriously heavy lifting... or maybe reaching out to the remarkable team
Unless there's a way to force xochitl to re-cache the image.
As @lgnap noted in the other thread, systemctl restart xochitl.service works reliably well. Would there perhaps be a way to trigger an early morning scheduled restart of xochitl, after the image is refreshed?
i did a bit of fishing around using strace on xochitl to see what it does on suspend. You could potentially listen in on ~/home/root/.cache/remarkable/xochitl/telemetry/* for an 'end' file potentially, and push an image to the framebuffer... It seems theres a few seconds between the image going to the framebuffer, and /sys/power/state getting written to..
@AdeelK93 's solution might be more straightforward though
As @lgnap noted in the other thread,
systemctl restart xochitl.serviceworks reliably well. Would there perhaps be a way to trigger an early morning scheduled restart of xochitl, after the image is refreshed?
This isn't really much of a solution... remarkable_news triggers when you wake it from sleep and wifi connects. So you'd wake it up, renews runs and gets a new image, and then forces xochitl to reboot. And when it reboots it connects to wifi, and then tries to download again.
Also, systemctl restart xochitl.service kicks you out of toltec/oxide if you use it, which isn't ideal either.
Thanks for the clarification @Snowflake6, I was not aware that that is how remarkable_news works
I'm guessing this also breaks https://github.com/Neurone/reMarkable.
Relevant issue in remarkable-hacks: ddvk/remarkable-hacks#139
I encourage people to reach out to reMarkable: https://support.remarkable.com/hc/en-us/requests/new?ticket_form_id=360000010097
Use the subject suspended.png not being reloaded with xochitl 2.5.0.27, explain the problem and include a link to this issue.
There's no reason for reMarkable to address this however... They're not expected to support hacking the rM.
[edit] @Evidlo Do you know what the "Receiver Contact Name" field should be on the remarkable request form? It's got an asterisk next to it so it wants something there...
[edit] I put my own name in there, and it accepted it. If that's what they wanted, it's a poorly named field.
ddvk fixed this in patch 17.2.05 of rmhacks.
I guess we'll have to wait for that to make it to a release. It's in the rm2 patch folder, will that affect whether it rolls to rm1 users?
It would be great to have the image auto-update without having to install rmhacks. I've sent a support request to the rM team as outlined above. Hopefully there will be a resolution soon.
Looks like in software version 3.5, there is no cache anymore on the suspend.png file.
@Axenntio That's good news! I'll close this if someone else can confirm.
I can confirm that on 3.9 a xochitl restart is not required.