Feedback

[krakerz]

i dont know how lanreader listing works, but is it possible to make it save last fetched list into local storage? it also will help mitigate API request to the server (i think) like ichaival (Android app) did, it fetch once per day (can be configured) for all archive list in the server (helps a lot when you have 10k+ archive) then search it locally (in app) and it's faster that way, fetching the image cover seems still goes through the API, but scrolling in library is faster and easier

currently, scrolling the library was stuttering (v2.6.0, latest) because it's often to hit the API (especially if you're exposing your server to public, so it will access it via internet) i didn't encounter stuttering in v2.2.3 (i think it's only load until certain page, so it wont continue load until the last page) also i noticed, sometimes downloading feature is not working, it's stuck in 0% (my database cache is always 1mb) and i just noticed, when reading a boot, each page change, is it always hit an API ? (what ichaival did is, download it into local, then extract it, so the reader didnt hit any API anymore, instead it open the local files when navigating the page)

device : ipad pro m1 (256) lanraragi : 0.9.21 (latest) connection : internet (accessing the lanraragi server via internet) ichaival : https://github.com/Utazukin/Ichaival

[Doraemoe]

So during LANreader 1.x, the listing was working as you described here, it fetches all archives from server and save them in local db. However, that does not work very well for large archives on low end hardware. E.g. on my 2016 NAS with 10k archives, that request takes over 3 mins to finish. So since LANreader 2.x, it now works exactly like official LANraragi web client: it send a search request with empty keyword to get a paged result. By default, the page size is 100. So in theory, LANreader will only send request every 100 archives. For your stuttering issue, there are many reasons:

1. Although in theory, LANraragi should return 100 results per page, sometimes it may return less than that due to its database not in sync with files on disk. Causing more search request to be send from client. It can even return 0 result and cause LANreader unable to continue fetching all the archives (That maybe the problem you have in v2.2.3 where it only load until certain page but not all). To fix it, you could try go to LANraragi Settings ->Global Settings -> Clean Database, then you should no longer see unnecessary network request. Moreover, you could increase page size from Settings ->Global Settings -> Archives per page to whatever the number you like, e.g. if you want it to fetch all archives, set it to 99999999999 :p
2. The other issue of stuttering is unfortunately from SwiftUI itself. It is a known issue that scrolling in SwiftUI have performance issue and many bugs (the vertical reader in LANreader is pretty broken due to this). I cannot do anything about it other than hoping Apple will fix it in next iOS update, but don't get you hopes up. The only solution for this is me re-write the whole app in UIKit instead, but I have 0 knowledge on it and don't feel like learning it for now. I can continue complaining “what a shit show SwiftUI is and how bad Apple at fixing issues in it while at the same time claim SwiftUI is the way you should write iOS app” for another hour, but I will stop here.

The downloaded archive will be stored in App's Document folder, not in database, so it is normal you see the database is 1mb. It should not make any web request when you read from Cached view (After all, download feature is meant for offline read). I will have a look to see if I can find any issue. In the mean time, do you know what API it tries to hit when you read a downloaded archive? Also about the 0% issue, is that for all archives or only some of them? Will delete and retry works? Does it happens on local network?

[krakerz]

Sorry for the late reply,

ah i see, so it's already implemented in 1.x, for saving into local db, yes it might takes 3 ~ 5 mins (depending of how large is the archives), from what i've seen in ichaival, it did fetch it like that, but only once (can be set up to do daily fetch or never at all) then after it, no need to refetch it again (unless you trigger manual, by pull to reload or scheduled fetch) and since it's already in local, it's smooth sail from there, i might try the 1.x later for comparison purpose

as for the no.1, i've tried this already (the clean database is regularly done), and set to 2000 archieve/page, good to know the app itself is using SwiftUI👌, so RIP for the many bug its caused 🤣🤣

as for the cached view, yes it's happens everytime, any archive as well, tried in localnetwork (192.xx) and internet as well (public domain), tried to delete and retry, changed version (1 version behind, iirc it has already that feature), all of it is same result, stuck in 0% (idk if this is visual bug or not though tbh), i kinda noticed when it's cached, changing page didnt hit any API, while not cached is always hit API (so maybe it's working? but in the cached list, it's still 0% and cant be clicked/opened via there) and i found a way (i think) to fix this, i'm using sideloadly and i do change it's packagename to xxxv2, and it's working (the progress bar is running), and after that i've tried to back to original packagename, sadly still same result 🤣, so it leads me that by uninstalling the apps, probably ios didnt completely wipe the app config dir for example? so probably old version configuration made it stuck perhaps?

as for API hit for read downloaded archieve, i'm not sure, since i can't debug log nor i monitor the api request (i was hoping there was telescope things like laravel does ._.) so i can't help much for this

[Doraemoe]

I have checked the network request in the app and can confirm there is no network request in cached view, I also have exact same hardware as you (M1 iPad Pro) so yeah, the problem could be the faulty update with side load. I have personally had issue before and remove/reinstall should be able to fix it.

I have no intention of rollback to old 1.x behavior of getting all archives, as it will introduce many duplicate codes and make the app more complex/harder to maintenance.

Some more rant about SwiftUI, I have submitted many bug reports for it to Apple and get literally 0 response, XXXX Apple's best way of making iOS App

[krakerz]

yeah figured, it's fine if it's not implemented, that's just my feedback anyway as for the cached function, can you implement some options to completely wipe / reset settings (with hope to completely wipe leftover files from previous version) ?

[Doraemoe]

Delete the app will completely wipe all files related to this App

[krakerz]

Delete the app will completely wipe all files related to this App

already tried this, the only working solution (at least for me) is change the app package name to random

[Doraemoe]

That's strange, I have no idea then. Maybe you could try Settings -> General -> iPhone Storage -> LANreader and delete it there? Or do you have iCloud backup enabled? Not sure if it is related but you can disable this App for iCloud backup.

Could also related to Sideloadly, it may provide some "cleanup" method itself. Or you could try AltStore.

[krakerz]

That's strange, I have no idea then. Maybe you could try Settings -> General -> iPhone Storage -> LANreader and delete it there? Or do you have iCloud backup enabled? Not sure if it is related but you can disable this App for iCloud backup.

Could also related to Sideloadly, it may provide some "cleanup" method itself. Or you could try AltStore.

i already tried cleanup from storage, even from 3rd party that has access to document folder like imazing i might try with another sideload app later, either direct altstore or sidestore (broken atm), i'm not using altstore anymore since it wont support organization account (so only can use personal account, not my developer organization account ._. )

[krakerz]

i'll close this in meantime, will reopen if somethings happens again, and i'm kinda busy atm, so can't test much sadly