Bionus
commented
4 years ago I put this as 7.4.0 because this will need a lot of re-work on how the favorites searches are currently implemented, as well as "feature discovery" on sources' model files.
Currently, the way searches are done is quite simple: when you click a favorite, it simply performs a search with the favorite tag, then post-filters the results using the date information provided by the source. This is why if you click the "last page" button, you'd go to the actual last page of all results, and all images will be post-filtered for being too old.
Knowing the "realy" last page would be impossible, as it would mean parsing all pages (or doing a binary search) until you find the one containing the last seen image. That would cause many unnecessary requests to the server and could be very slow depending on the number of results.
I see two possible alternatives to this, and the real solution would be to implement both, and use whichever best option is available for the current source:
- Use "ID paging", i.e. return all results before ID X if available. For example on Danbooru, that means instead of doing
?page=10, do?page=a123456(see Common Search Parameters). This also means Grabber will have to remember the ID of the last image seen (issue #1058). - Use actual date filters in the search, i.e. search
my_favorite_tag date:>2020-06-02for example. The downside being that some source limit the maximum number of terms in your search, so that could cause issues. - Fallback to post-filtering if nothing is available, with a warning.
FichteFoll
Is your feature request related to a problem? Please describe
As described in https://github.com/Bionus/imgbrd-grabber/issues/1970, it currently makes the most sense to browse a favorite from the oldest to the newest post, since you can only filter out images "older than x", but the UX doesn't really support this kind of workflow.
When clicking on the
>>button to open the last page, you will most likely be met with a "No image since …" message and then have to go back the pages manually (<) until you can see images again. This may take a significant amount of time depending on your search results.It appears that the UI expects you to be "done" with a favorite if you reached the last page with results, since it changes the UI to have the list of images on the bottom and the list of favorites back on top, which is the reverse of how I would use the feature.
Describe the solution you'd like
Because I just started using this feature, I don't know how it was used previously or what the expected workflow would look like, but to me the current situation just doesn't work. It seems an option to sort your favorites in reverse order and otherwise keep the current workflow would satisfy my request, but I don't know if the current system is worth keeping or whether it should be replaced.
Describe alternatives you've considered
Other ways to filter the follow list of images for a tag, e.g. by maintaining a list of viewed IDs/md5 hashes (#1416). Using a "only show images older than" filter doesn't work well with new additions, which is why it is not an option.