Hey @Clay , we just released a new Testflight with some fixes in the OPDS integration. Could you try it and let us know if you can download files as expected?
I tested the integration with your test account and could download several files without a problem.
We are kind of at a dead end with this, folks. I’ve tested the downloads using @Clay 's testing account, and I can download many comics at once without a problem. I just tested it again and could download 54 files in one go.
Could you find some diagnostic logs in your device(s) and send them to us? Sending App Diagnostics
Maybe we find something that helps us understand what’s going on.
We found something in your logs, and we have made some changes. We weren’t getting any crash reports because the app wasn’t crashing, but iOS was killing it. It looks like Panels was locking the main thread on your device for a few seconds, and that caused the system to kill the app.
Hopefully, the new Testflight works better. Let us know if it made any difference.
I’m starting to think the problem has nothing to do with the OPDS download but maybe with something in your local library. The last 2% of the download process corresponds to indexing the file locally. If it reaches 98%, the download is completed correctly, and it is tracking it in the local database.
There is additional information you can send to us. If you go to the app settings/profile, there is an Email Us button in the Contact Us section. If you tap and hold for a few seconds, the app will attach additional debug information to the email. Could you please send it to us? The debug data includes statistics about your local library.
We can try reproducing a similar scenario on our end and see if the app gets stuck.
recording of seeing it happen with the 01/22 build
debug output after clean install
debug output after adding the OPDS source and creating a folder to download into
debug output after failed downloads. Whatever impacts the menus seems to prevent generating the debug email, so i had to kill the stuck files and deleted the queued ones, as well as restarting. Not sure if that will still give you useful details, but it was the only option I’ve got.
Not at all. We re-implemented it using different APIs.
For those interested in technical details:
Until now, we have been using the open-source library Checksum to calculate them.
Looking at the implementation Checksum/Extensions.swift at develop · rnine/Checksum · GitHub, we noticed that, even though checksums are returned synchronously, it uses DispatchGroups that internally use thread locks.
This is unnecessary in our use case because we already have our own thread model and can wait for long-lasting tasks if needed.
I assume that those thread locks are causing deadlocks on some devices.
On top of that, Checksum uses CommonCrypto, an open-source cryptographic library by Apple that has been deprecated in favor of a more modern CryptoKit library.
We used Checksum for a long time because CommonCrypto is not very ergonomic in Swift, and we preferred using an open-source wrapper that many people would use, to make sure our usage of CommonCrypto was correct and safe. CommonCrypto provides a C API which is more finicky in terms of memory management and things like that.
The last build we released today contains our own implementation for calculating the file checksums using CryptoKit, which provides a nice Swift API.
Our new implementation doesn’t use thread locks; hopefully works the problem around.
I will wait for @Clay 's feedback before assuming this issue is fixed. But it makes sense and matches what I saw in one of Clay’s logs.
I downloaded the app for the first time today
I just sent a refund request for the $20 since I thought it must be a scam. Glad I googled it but yeah I see exactly this latest problem of everything getting stuck at 98% progress and all the buttons starting to misbehave and be unresponsive, only I’m not doing it over OPDS but over SMB connection
Otherwise exactly as described here