〖讨论〗探讨一下影片多类别分类的问题 #172
Replies: 6 comments 8 replies
-
|
awesome，我也喜欢这种风格，需要注意是否对软链接，移动，复制等这些管理方式有影响，如果能确认，版本你不用担心，我可以创建feature分支，docker发布feature tag，然后根据反馈去合入主分支 |
Beta Was this translation helpful? Give feedback.
-
|
我自己只用硬链接，因此目前尚未对软链接，移动，复制等做限制，如果要合公开版本，肯定还是要做限制的，最主要的担心也是是覆盖不完整导致软链接，移动，复制等受影响，因为转移目录改到了 filetransfer.py 里 transfer_media 这个有471行代码的方法，虽然只改了10来行，但是核心部分增加了按多类别循环的处置，影响比较大，况且 transfer_media 这个方法中处理的逻辑非常多，涉及路径判断和创建，各种目录、文件参数的处理，各种转移方法的实现，又涉及影片、电视、动漫的各种分支，还涉及前端进度的计算和消息、转移后字幕等的处理。 个人感觉这个transfer_media实在应该重构，将每一步的逻辑封装，便于后续的修改优化，最好是转移的过程也能支持事件，这样就可以插件化处理，类似于原作者在这个方法中对字幕的处理使用了插件机制，但是作者仅仅是在转移完成后才发了事件，不知何故未定义转移过程的事件并对转移过程进行拆解 |
Beta Was this translation helpful? Give feedback.
-
|
transfer_media重构主要担心影响现有逻辑，或者说nt本身作者在编写代码的时候早期没有考虑到，导致后续维护比较困难，加上使用的用户体量上升，改动影响太大，我这边抽空一点一点改动。 |
Beta Was this translation helpful? Give feedback.
-
|
还有就是二级分类的配置，直接扔到category.yaml进行编辑不友好，解析规则也比较单一，不支持相对复杂的“与或”分组条件或“排除”条件，如果把二级分类的配置从基础设置中分离出来，在“媒体库”下每种媒体增加独立的“多级类别”配置界面可能会更友好和可控，甚至可以在“媒体库”下支持插件的安装来适配不同的分类策略也许更加灵活。 |
Beta Was this translation helpful? Give feedback.
-
|
合理，对新手用户友好，就是编写设置的工作量有些大 |
Beta Was this translation helpful? Give feedback.
-
|
如果支持拖拉方式，应该用户的工作量不会太大，而且对于一般用户来说，这都是一次性的工作，配置好了基本上就不会改了，所以这个思路我也只是想想，交互本身不一定最重要，最重要的还是希望配置的规则能更灵活些，解析能更强大些，例如我在本地分支就实现了逆向匹配，满足条件的就排除掉 |
Beta Was this translation helpful? Give feedback.
-
是不是可以理解为一部影片会生成很多硬链接？这种方式我不建议。如果丢到emby或者jellyfin库里，那就会出现多部相同的电影了，而且硬链接想要完全删除，是需要把源文件和硬链接文件同时删除才可以，如果这样做，在数量多的时候，可能会漏掉，反倒更加不便了。现在我源文件和硬链接只删除一个目录，就可以确保删除完全，如果自动生成多个，我都不清楚要删除几个才能全部删除。 |
Beta Was this translation helpful? Give feedback.
-
|
比如我有时会核对数量，源文件有20个，对应的硬链接有20个，我就知道都已经链接完成了，如果出现20个源文件，对应30个硬链接，我就没法直观简单的排查问题了 |
Beta Was this translation helpful? Give feedback.
-
|
目前像emby或者jellyfin、plex好像都没有做类型的分类。类型的分类，应该由emby这类软件进行识别和筛选，而不是用文件去筛选。比如这种，在电视剧下面，再进行分类检索 |
Beta Was this translation helpful? Give feedback.
-
|
当然。大佬如果做出来，是有开关选择的，影响不大，毕竟萝卜青菜各有所爱。我可以选择老的分类方式，别人也可以选择这种分类方式 |
Beta Was this translation helpful? Give feedback.
-
|
所以说这是个性化需求，jellyfin支持分类和系列，只是由于包含太多英文的类别，对国内用户不是很友好，所以我还是经常会在jellyfin中使用目录方式查找影片 |
Beta Was this translation helpful? Give feedback.
-
事实上现在手工转移目录也是可以创建多个硬链接的，而且通过硬链接查询也是可以找到所有硬链接的文件，这个不是问题。原版nastools的问题是每次手工选择路径查找所有硬链接特别麻烦，所以我才改了目录树和文件区自动标识和查找硬链接，因为一来可以无需手动找到链接的来源和目标，二来因为识别出错或其他原因导致硬链接失败时，可以在原文件上快速的看到是否成功转移。 你说的问题倒是可以考虑在同步来源目录和下载目录的文件区中，增加一个完整删除的功能，这样在删除原始文件的时候，把硬链接的相关文件都一起删除 |
Beta Was this translation helpful? Give feedback.
-
|
通读了一下，大概理解了什么意思，首先不反对添加这个功能，但是建议可以通过开关来实现这一功能，毕竟萝卜青菜，各有所爱，作为我本身使用者而言，我也不太喜欢这种形式，会严重打乱现有管理文件的方式，造成一文件多硬连接或者软连接，对于我这种喜欢用jellyfin自动合集功能的简直是灾难 |
Beta Was this translation helpful? Give feedback.
-
|
对于直接转移的采用硬链接，对于之后细分类的是否可以启动软连接形式？不过软连接可能会发生文件转移缺失问题 |
Beta Was this translation helpful? Give feedback.
-
所有的影片都是具有多种分类属性的，且在TMDB的类别信息中这些类别的排序都是没有逻辑可言，完全取决于编辑者自己的排序，而TMDB API获取到的类别的排序既不是编辑者的排序，也不是按genre_ids排序，我尚未找到规律。因此同一系列的影片的类别会不尽相同，特别是TMDB API获取到的第一个类别会有不同。
原版nastools对影片二级分类只支持一个类别，且获取的是TMDB的第一个类别，就导致有些影片分到的二级分类有点莫名其妙，导致同一系列的影片也经常被转移到不同的目录里去，例如《雷神系列》的第1-3部第一类别都是“动作”，而第4部虽然也有“动作”类别，第一类别却是“喜剧”。
我在本地分支实现了一个版本支持影片的多类别和系列，也就是识别时TMDB所有的类别都拉取下来，不局限于第一个类别。
在硬链接转移目录时，所有的类别都创建对应的目录和文件，归属系列的也会在目标目录中建立系列目录后进行链接，多类别的硬链接会在多个类别目录中链接同一个影片，这既是优点也是缺点，因为会多出很多硬链接，所以非链接类的转移就不适合了，并且因为TMDB本身分类不完整不合理，仍然会导致类别缺失需要手工弥补。
这个分支个人特色较为明显，我本人不喜欢那么多影片都堆到一个目录下，没有用nastools前也是手工对各类影片分类整理的，因为不拘泥于二级分类，而是含系列的多级分类，因此在jellyfin中可以通过多级分类清晰的目录找到要看的影片，虽然nastools的自动分类解决了频繁手工整理的强度，但是由于不完善仍然免不了需要较多的操作去进行整理。
多类别的分支如果要提RP到master还需要做通用化处理，支持一些开关配置，甚至包含对category.yaml的改造和扩展，考虑到对不同用户习惯的支持，甚至nastools的二级分类策略或转移规则有可能需要插件化。
因此想看看大家的观点是怎样的，用二级分类的小伙伴多不多？使用的时候都有哪些疑问、意见或建议？
Beta Was this translation helpful? Give feedback.
All reactions