fix: Incorrect episode number for Conan and reduce API calls on -c

[RaitaroH]

Pull Request Template

Type of change

• Bug fix
• Feature
• Documentation update

Description

Fixing sort -n

The anime "Detecitve Conan' has many episodes. The episodes_list() curl returns some strange numbers such as "348.349", which the current "sort -n" will put after latest ep "1201". This issue will also embed itself into the histfile.

To fix this, it is enough to use sort -g.

$ echo -e "348.349\n1201\n100\n800" | sort -n
100
800
1201
348.349

$ echo -e "348.349\n1201\n100\n800" | sort -g
100
348.349
800
1201

episodes_list is called many times

In the -c option we first call episodes_list() which processes all anime in histfile, then ep_list will call episodes_list again. We could instead have the episodes_list save the result in tmp so we don't curl again.

Checklist

• any anime playing
• bumped version

---

• next, prev and replay work
• -c history and continue work
• not using -c also works
• -q quality works

[RaitaroH]

This comment is not part of this PR, nor will it be. It is just a remark.

We could reduce curls further if we skipped processing entries that are finished. Is just that, currently, we do not know if a show has been completed or we simply caught up to the latest known episode (say we watched ep 4 out of 4 known last week, but now there is a 5th episode, yet the script will skip without curl-ing, thus never updating to 5).

process_hist_entry() {
    # skip if anime is completed
    last_known_ep_no=$(printf "%s" "$title" | grep -oP '\(\K[0-9.]+(?= episodes\))')
    # use bc to avoid errors when ep_no is a float number
    [ "$(echo "$ep_no >= $last_known_ep_no" | bc)" -eq 1 ] && exit 0
    ...
}

I suppose we could have another column in the histfile to say if show is finished or not.

For now deleting the histfile either with the -D or manually seems is sufficient.

[RaitaroH]

Apologies for the inconvenience in the original submission.

[port19x]

While your reasoning is sound, sort -g is not part of the posix spec and thus not desirable, as it would break BSD and MacOS platforms or, arguably worse, introduce the GNU Coreutils as a dependency.

What is desirable, in fact highly so, is reducing API calls.
If you can make the -c speedup work cross-platform, I'll happily merge it as a refactor.
/tmp/ does not exist on windows for example and on some platforms /tmp/ isn't actually cleared on reboot