Enhance practicality (Feature Request)

[yuioto]

Some feature requests, I don't know if he's worth creating an issue, and these features may be difficult to implement, so raising it here.

• aid support

Warn the user if the target input is not aid/bid/list_id, as the user may not want these videos to be tracked.

References:

• Colerar/abv
• SocialSisterYi/bilibili-API-collect Documentation

Other issues besides:

• Batch select a subset of videos from the list
• There are always multiple download tasks downloading at the same time, instead of waiting for the current download task to end before opening a new download task.
• Don't use a table view if the terminal is not wide enough
• Daemon mode supports synchronization (automatically deletes videos that are no longer favorites)
• Supports rollback (automatically creates commits when remote changes occur)
• When downloading the entire list of videos (fav pull), it is allowed to press Ctrl-C only once to cancel all tasks in the download list (terminate the program)

[kingwingfly]

Thank you for your suggestion.

• Aid support: I feel this is too hard now as discussed here [Feature Request] shell completions enhanced #1, this should be a long term work. And the crate we use (clap) is not ready for such a dynamic completion.
• avid, bvid, list_id: list_ids and avids are pure numbers while bvids are BV1XXX. When track an id, fav will find it in list_ids first, then bvids, if not exists, it will be marked as a new tracked bvid. This makes fav track universal enough. The only problem I encounter is that one may track a pure number id that not in fetched list_ids, fav wrongly treated it as a bvid. The solution is to untrack it and run fav fetch -p to clean untracked but recorded resources and fetch again. To conclude, this problem is because there are 3 kinds of resources: bvid, avid and list_id, the list_id is actually a set of bvids. However, avid and list_id conflicts each other since they are both pure number. My suggestion is to not consider avid at all, because all videos have bvid, and it is much easier to get bvid while it's hard for avid.
• batch track and pull: You can always run fav track BV1XXX BV1YYY, track pull modify and so on always accept multi args.
• Table is too wide: kubectl has the same problem, maybe I can add a --short flag to show tables.
• Auto delete non-fav but saved videos: I initially want fav is operated like git, so it is good that pull should sync local and remote. However, fav is actually a downloader, all downloaders I used only remove records, not files, by default. Another problem is what saved flag should be after auto delete? If it's true, this conflicts the fact. If it's false, then next pull will download it again (since fetch without --prune flag will never remove any local record), we don't expect that. What's your opinion about this?
• Rollback: fav now can only receive remote and manage local, but cannot push local to remote. So it's questionable whether we need rollback functionality. Why we cannot push local to remote? For two reasons, the first is that it is convenient enough to manage your fav lists on bilibili website, bilibili officially provides rename move batch delete operations. The second is it's not safe to provide such a command to user, user may lose data if they wrong operate while I make a mistake coding. From my personal perspective, it's just a normal user action to use a 3rd-party downloader, but a control, fake or attack behavior for bilibili if providing remote managing function.
• Ctrl-C only cancel one batch(10) of jobs: I will fixed it on v0.1.11.

The sync between local and remote is one of the subjects of git, but for a downloader, not just sync, the core difference is that users like more addition (download) and less reduce (remove). From addition side, fav does well, but from reduce side, it needs more consideration to judge if it acts too conservatively(保守).

[yuioto]

Thank you for your response.

Regarding the automatic deletion of non-favorited but saved videos

I apologize for any misunderstanding.

What I meant is that when the user's favorites on bilibili change, those changes should be synchronized locally, even if it involves deleting videos.

However, despite this, the issue you raised might still persist, wherein fav may exhibit behavior that the user does not anticipate.

To address this, perhaps we could introduce a new command, such as gc or clean, which would enable users to remove videos that are no longer present in their favorites on bilibili.

For the fav daemon, we can options，like fav daemon clean.

As for manually tracked videos (e.g., fav track BV1?????????), we could either add them to the source of origin or, considering that fav isn't meant to modify the source directly, we could add them to a local favorites list (similar to git's remote and local, but confined to the local environment).

Regarding rollback functionality

Occasionally, videos on bilibili may be updated, especially if they violate the platform's rules. In such cases, users might wish to view previous versions of the video.

However, since we can't determine when a video has been updated on bilibili, so this function may be difficult to implement unless bilibili adds an API.

aid

We can focus solely on handling av* (i.e., those starting with av).

Internally within fav, it might be beneficial to convert all aid to bvid.

[kingwingfly]

To implement these, I think there should be some refactoring to make the code more rusty.

I'll try making some traits like Resource Resources API Remote Local and so on, so that making it more easy to enhance.