You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Series's chapter length varies a lot. Many of them are things like comic strips, with 1-2 pages at most. Sometimes chapters are split into smaller parts. Sometimes, these lengths even vary within a series.
This reduces the usefulness of "download ahead". If the series are each 1 image, then it is easy for an intermittent slowdown of the connection (eg, might be caused by other devices on the network) to cause the user to catch up. Yes, increasing the download ahead length may fix this, but now series with very long chapters are being downloaded much further ahead than necessary.
Therefore, I think it would be a nice QOL feature for users to able to change the length depending on the series. This will even help if it is within the same series, since the user can adjust it as they go, without worry of effecting other entries. The setting should be added on the entry download menu, ideally (DownloadDropdownMenu.kt. If this is infeasible for some reason, the filter menu would also work, but would make less sense (though it would make the UI nicer)
Alternatively, a 'smart download ahead' could be implemented, which uses several factors to download more or less ahead (such as how long it took the user to get through the last several chapters, how many pages there were, and how many pages are in the upcoming, download speed) It will have the page count, since it will always be downloading ahead by 1 (unless it is the last available, turned off, or other intentional features). Since it has the next chapter, it just needs to check if it can be done, or needs to download another.
Other details
Considerations on implementation:
If this is being considered, please also keep in mind Add ability to disable/enable ' Auto download while reading' per category. #85, which requests on/off based on category. Category-based settings are one of those long-time goals, but making it adaptive (eg, setting the download ahead amount to 0 for off) would potentially help.
If using smart downloads, it should be added to the main settings instead of a per-entry setting.
Acknowledgements
I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
Describe your suggested feature
Series's chapter length varies a lot. Many of them are things like comic strips, with 1-2 pages at most. Sometimes chapters are split into smaller parts. Sometimes, these lengths even vary within a series.
This reduces the usefulness of "download ahead". If the series are each 1 image, then it is easy for an intermittent slowdown of the connection (eg, might be caused by other devices on the network) to cause the user to catch up. Yes, increasing the download ahead length may fix this, but now series with very long chapters are being downloaded much further ahead than necessary.
Therefore, I think it would be a nice QOL feature for users to able to change the length depending on the series. This will even help if it is within the same series, since the user can adjust it as they go, without worry of effecting other entries. The setting should be added on the entry download menu, ideally (DownloadDropdownMenu.kt. If this is infeasible for some reason, the filter menu would also work, but would make less sense (though it would make the UI nicer)
Alternatively, a 'smart download ahead' could be implemented, which uses several factors to download more or less ahead (such as how long it took the user to get through the last several chapters, how many pages there were, and how many pages are in the upcoming, download speed) It will have the page count, since it will always be downloading ahead by 1 (unless it is the last available, turned off, or other intentional features). Since it has the next chapter, it just needs to check if it can be done, or needs to download another.
Other details
Considerations on implementation:
Acknowledgements
The text was updated successfully, but these errors were encountered: