Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] 支持自定义保存路径 #762

Open
akiakise opened this issue May 3, 2024 · 6 comments
Open

[RFC] 支持自定义保存路径 #762

akiakise opened this issue May 3, 2024 · 6 comments
Labels
RFC Request for Comments

Comments

@akiakise
Copy link

akiakise commented May 3, 2024

背景 or 问题

当前 Auto_Bangumi 默认将下载文件保存为下列格式:

有年份信息: /${download_path}/${official_title} (${year})/Season ${season}/${重命名方式}
无年份信息: /${download_path}/${official_title}/Season ${season}/${重命名方式}
示例: /downloads/孤独摇滚! (2022)/Season 1/S01E01.mkv

即,在 download_path 下是平铺式文件布局。

这样的文件布局在某些时候存在一些不便:

  1. 大量文件管理,例如 [Feature Request]: 希望引入更多的剧集解析自定义能力 #356 提到的长期使用后有大量文件平铺,不利于管理;
  2. 自由管理文件结构,例如我本人的食用方式是 NAS 下载,然后 SMB 挂载到 Windows/Linux 查看,不需要刮削,这种情况下 /${download_path}/${official_title} 最满足我的诉求。

同时我还在使用 JimHans/bgm.res 来自动同步播放记录到 bgm.tv,当前 bgm.res 也是直接解析 ${official_title}/S01E01.mkv 类似的文件结构,无法解析 ${official_title} (${year})/Season 1/S01E01.mkv${official_title}/Season 1/S01E01.mkv 格式的文件。

目标 & 方案简述

支持模板变量方式的保存路径,以便灵活定义保存路径:

image

自定义保存路径格式: /${download_path}/${official_title}

实际效果:

image

方案设计 & 实现步骤

在 _gen_save_path 时解析 BangumiBangumiUpdate 类的所有类属性,并将这部分字段作为模板变量,替换入用户输入的模板字符串中:

def _gen_save_path(data: Bangumi | BangumiUpdate):
folder = (
f"{data.official_title} ({data.year})" if data.year else data.official_title
)
save_path = Path(settings.downloader.path) / folder / f"Season {data.season}"
return str(save_path)

给定用户输入模板字符串: /${download_path}/${official_title}

首先通过 data.__dict__.items() 获取所有类属性(同时过滤 _ 开头的内部属性)

然后替换模板字符串中的 ${field_name}field_value

如果 field_value 为空,则跳过该字段处理(例如给定模板字符串 /${download_path}/${year}/${official_title},同时 data 中 year 为空,则最终只会解析 /${download_path}/${official_title}

PS 1:
由于调用 _gen_save_path 方法时 BangumiBangumiUpdate 类的 save_path 仍未可用,因此需要在处理完成后增加下 ${download_path} 模板变量的支持

PS 2:
本次改动后,自定义保存路径支持以下模板变量

  • official_title: 番剧中文名
  • year: 番剧年份(可能为空)
  • title_raw: 番剧原名
  • season: 番剧季度
  • season_raw: 番剧季度原名(可能为空)
  • group_name: 字幕组(可能为空)
  • download_path: 在下载设置中配置的【下载地址】

基于 __dict__ 的实现方式,本次也支持了 BangumiBangumiUpdate 类内部的其他字段,例如 dpisourcesubtitle 等,但是考虑到这些字段基本都为可能空且可以预见的使用频率低,后续在文档中就不做体现了。

同样因为是基于 __dict__ 来实现的,后续扩展 Bangumi 类字段也将自动支持新字段作为模板变量来使用,例如新增月份、制作人等元信息。

替代方案 & 对比

No response

@akiakise akiakise added the RFC Request for Comments label May 3, 2024
@timi137137
Copy link

支持该提案:

  1. 模板变量能提供更高的可自定义化,能涵盖到部分特殊的自定义的目录结构
  2. 可以对模板变量进行正则操作,能过滤一些特殊符号或用户不想要的词

@akiakise
Copy link
Author

akiakise commented May 9, 2024

支持该提案:

  1. 模板变量能提供更高的可自定义化,能涵盖到部分特殊的自定义的目录结构
  2. 可以对模板变量进行正则操作,能过滤一些特殊符号或用户不想要的词

正则操作在这个提案中没有涉及,关于模板变量的处理只是简单的替换,我个人也没有想到有什么可能需要使用正则处理保存路径的场景,可以留待后续有缘人提类似场景再评估 :)

@timi137137
Copy link

支持该提案:

  1. 模板变量能提供更高的可自定义化,能涵盖到部分特殊的自定义的目录结构
  2. 可以对模板变量进行正则操作,能过滤一些特殊符号或用户不想要的词

正则操作在这个提案中没有涉及,关于模板变量的处理只是简单的替换,我个人也没有想到有什么可能需要使用正则处理保存路径的场景,可以留待后续有缘人提类似场景再评估 :)

你是没讲,但这个场景的根需求有使用正则的场景

@akiakise
Copy link
Author

akiakise commented May 9, 2024

你是指 #356 中提到的 {year}年{month}月 吗?这个提案中确实没有考虑支持这种结构,不过这种也可以通过简单的字符串替换来实现。

正则的一个主要问题是需要多个入参,这会让配置的成本增加(理解成本、配置成本都会增加),我已经实现了这个提案所说的功能,也确实没有用到正则:

https://github.com/akiakise/Auto_Bangumi/blob/54e83418f5873e9842e69b6ac6485789422a9466/backend/src/module/downloader/path.py#L56-L88

@timi137137
Copy link

image
请注意重点,本来这个功能就不是普通用户要使用的,能使用的百分之90都是了解并清楚这是什么东西的。而且实际上在番剧过滤上也已经使用了正则。如果你有认真观察的话。因此有需要使用这个的属于低成本或零成本。没必要使用这个的又何必去看

@akiakise
Copy link
Author

akiakise commented May 9, 2024

嗯,使用正则与否只是一个技术实现上的问题,只是使用正则会提供正则带来的过滤、替换等能力,不过我比较怀疑是否有需要过滤保存路径中特殊符号或者关键词的场景。

就目前 AB 的两种使用方式来说:

  1. 订阅聚合 RSS,此时没有入口提前感知订阅的番剧的标题,即使标题中存在特殊符号,用户的感知也是后置的,他无法前置知道需要过滤哪些特殊符号;
  2. 订阅单个 RSS,此时用户可以自由修改标题,对应的保存路径也会修改。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request for Comments
Projects
None yet
Development

No branches or pull requests

2 participants