Edit Diaries.

Signed-off-by: SilverAg.L <caclx@outlook.com>

README.md

@@ -1,17 +1,20 @@
 ## SilverAg.L 的玩具城
-说人话就是咱的个人博客。不考虑英翻，NO ENGLISH VERSION!
+基于 [vuepress-theme-hope](https://theme-hope.vuejs.press/zh/) 滴[个人博客](https://agxcoy.shimakaze.org/)。没有英文版本。
 
 ---
 
-<p align="center">
-    <img src="https://img.shields.io/badge/license-MIT-blue" alt="license - MIT">
-    <img src="https://img.shields.io/badge/license-CC--BY--NC--SA--4.0-lightgrey" alt="license - CC-BY-NC-SA-4.0">
-</p>
+![MIT License](https://img.shields.io/badge/license-MIT-blue)
+![CC-BY-NC-SA-4.0](https://img.shields.io/badge/license-CC--BY--NC--SA--4.0-lightgrey)
 
 本博客收纳的文章统一采用 CC BY-NC-SA 4.0 协议共享。
 
-**欢迎就本博客上传的「随记」「综述」中的错误、不足之处提出 Issue 批评指正；或者看不顺眼了，丢个 Pull Request，也是极好的。**
+如有想法，还请移步 [GitHub 讨论区](https://github.com/AgxCOy/AgxCOy/discussions)。
+如有疑问、友链需求，还请移步 [Issues](https://github.com/AgxCOy/AgxCOy/issues)。
+如欲改进，也欢迎起号提 Pull Request。
+
+「冇嘢猴肛，我係傻居居。」
 
 ### 特别鸣谢
-- [神羽 @SnowyKami](https://github.com/snowykami)
 - [岛风 @frg2089](https://github.com/frg2089)
+- [神羽 @SnowyKami](https://github.com/snowykami)
+- [苏阳 @Twisuki](https://github.com/Twisuki)

docs/diaries/wbsy/about-me.md

@@ -85,8 +85,28 @@ date: 2025-05-16
 
 银这个设定实际上直到去年才给她勾个轮廓——**白丝魅魔猫娘少女**。乍一听这四个词组合在一起很违和。说实话我也觉得（
 
-首先说说“魅魔”吧。既然银这个字有着一层谐音关系（所谓“银梦”嘛），那么我就往涩涩的方向去考虑了。所以给她的定型是魅魔元素。  
-但一来我说话做不到大多数黄油的魅魔那么“诱人”，二来我养成的猫娘口癖根深蒂固，这就决定了**立绘主体仍然是猫娘**。那么怎么办呢？那就把猫尾巴替换成魅魔尾巴罢。“猫娘身上”的“魅魔尾巴”，很奇特的组合对吧（  
-剩下来的要素就很简单了：白丝一般显得清纯（相对地黑丝会显得诱惑一些），穿在“摇着魅魔尾巴的猫娘”身上增添些反差感；少女嘛……可以保留一些卡哇伊的感觉。（但实际想象起来好像更偏雌小鬼一点）
+相比前面两个反映我不同时期的、特点鲜明的自设，“银”这一形象就相对一以贯之，同时又很随性了。大约在初中我就误入当时流传的所谓“本子库”[^benziku]，所以涩涩也算是我一直以来的隐藏属性，如今启用这个自设也有种借谐音梗的题发挥的意思。
+
+[^benziku]: 具体的经过已经淡忘了，我的博客对涩涩的话题也比较含蓄。可以确定的是，“本子库”、“兔纱子”、“魔法少女”这些关键词是我早期的朦胧印象，后来形成的题材偏好（或者说 xp）也是基于这个印象所做的建构。
+
+至于这个轮廓为什么这么左右脑互搏，只能说是基于自身经历导致的历史惯性吧。钙设是猫少年嘛，加上我认识的老朋友们普遍爱发猫猫表情包，所以我的口癖不可避免地也倾向于喵来喵去，忽然摘掉“猫”这个元素反倒不知道怎么表达了（毕竟我做不到真像魅魔那样妩媚）。但我又希望能够突出涩涩的要素，所以最终形象就是点缀上白丝、魅魔尾巴、猫耳猫爪的少女啦。~~但自己想象的时候感觉更像雌小鬼一点（）~~
 
 设定上魅魔尾巴非常敏感，只是碰触就会浑身战栗的程度。若是摸上那么一两下说不定就开始发情了吧。
+
+> “诶嘿嘿…身体绵软被搂在怀里什么的……嘿嘿…  
+> “可是……为什么呢？光是咀嚼着文字想象，身体就酥酥麻麻的……  
+> “好羡慕……好烦躁……  
+> “你是怎么看我的呢，氯喵？你会要我吗？  
+> “好想再被你抱着……抱在怀里，就像…就像……”
+> ::: right
+> ——Ag
+> :::
+
+---
+
+## 后记
+事实上我确实没想过它们之间会有什么社会关系，毕竟本质上都是我在网络上的皮套而已，它们都是我，却又不完全是。但真的做出决定，“既然我本来就没活，索性把身为创作者的我，叫做‘氯’的我给埋葬了吧”，这么做的时候，我的内心还是会觉得痛苦，仿佛真的失去了重要的人一般。
+
+基于这样的感情，我才决定写下这一篇随笔，完善这几个自设的形象。至于每个设定底下的自白，更多地是对[友链 PR](https://github.com/Twisuki/blog/pull/4) 里的小对话做一个扩写，很抱歉我并不擅长写一个完整的故事，只能像这样侧面地刻画 CaCl~2~ 和 AgCl 这两对之间的亲密关系。
+
+不论钙、氯还是银，都是我精神世界的投射，也都寄托了我的愿望或是欲求。也许我就是很享受被人家说可爱、就是会为喜欢的事情不顾一切、就是会代入本子里的女孩子、就是想要“身体绵软被搂在怀里”呢？哪怕只是想象，只是在被窝里小声呢喃着“想要”，只是在博客里发癫、写一篇篇的碎碎念。

docs/diaries/wbsy/nas-media.md

@@ -1,26 +1,164 @@
-# 元数据刮削就是一笔糊涂账
+# Jellyfin 真的好用吗？
 
-> [!warning]
-> 本文所抛出的观点**并未经过严谨的论证，且容易引起争论**。读者们看个乐就是，文中的论述莫要当真。换句话说，**“这家伙叽里咕噜说什么呢？”**
+我的结论是：实则不然。但 DIY 这一块本就是矮个子拔高个，也没那么多平替可以挑。
 
-虽然主要差异在于思维方式——毕竟我还是更习惯基于文件和目录的树形资源管理，但在讨论之前我不得不承认：**元数据的收集整理（即刮削）相对来说很有必要**。听起来就……左右脑互搏，对吧？~~本文之所以是篇"无病呻吟"，正因为犯这个病的大抵只有我一个。~~
+> [!important]
+> - 本文字里行间夹带着作者的私货，行文并不严谨，谨慎阅读。
+> - 本文有关的折腾流程时间跨度较长，经验之谈不说没有，也只能说碎得跟渣一样。~~所以不是笔记而是大作文。~~
 
-我的观点很简单：元数据有用，但并不好用。要说什么方案更好？对不起，我也不知道。
+## 硬件加速，硬件呢
 
-首先还是说说为什么值得肯定。不说别的，至少分类的角度多了。同是音乐，我可以看专辑、看艺术家，当然也可以直接随便 roll 一些单曲来听。从用户体验上说，图像就是比冷冰冰的文字更抓眼球，一排排专辑封面、电影海报总要好过全是文件夹图标、甚至只有一排排文件名、文件路径的。
+我是 Linux Docker 部署的。由于因特耳的核显驱动闭源，**官版 Docker 容器搞起来后还需要`exec -it`进去装 Intel 驱动**；即便是`nyanmisaka`版开箱即用 Jellyfin 镜像，也需要**手动映射渲染节点**[^renderD128]。
 
-但……为什么我又要攻击它呢？因为用户体验好了，管理体验就要折磨。
+[^renderD128]: 非要映射整个`/dev/dri`也可以，那样后续仍然**可能**需要进入容器里创建`render`组。并且由于`nyanmisaka`版镜像并没有对用户组做特别设置，如需映射渲染节点做硬件解码，就**不允许指定用户（组）运行**。
 
-现如今的媒体库，基本上按影视、图像、音乐、文档分类，工具选用上属于没什么平替。论及私人图书馆总绕不开 Calibre，论音像库讨论比较多的就 Jellyfin、Emby、Plex（姑且不讨论品牌家的原生工具，毕竟我没钱）。这些工具对于传统的音像、图书资源支持非常好，**只要刮削得当**，通常能得到比较干净的媒体库。是的，《只要刮削得当》。
+::: details docker-compose.yml
+以下是最简配置。如果预计暴露到公网上，建议再加上额外的安全措施，**尤其注意收紧容器的执行权限和性能分配**。
+```yaml
+services:
+  jellyfin:
+    image: nyanmisaka/jellyfin:latest
+    container_name: jellyfin
+    network_mode: 'host'
+    volumes:
+      - jellyfin-config:/config
+      - jellyfin-cache:/cache
+      - /home/http/media:/media:ro,nosuid,nodev  # recursive 'rx'
+      # - /dev/dri/renderD128:/dev/dri/renderD128
+      - type: bind
+        source: /usr/share/fonts/opentype
+        target: /usr/local/share/fonts/custom
+        read_only: true
+    devices:
+      - /dev/dri/renderD128:/dev/dri/renderD128:rw
+      #- /dev/dri/card0:/dev/dri/card0
+    restart: 'unless-stopped'
+    # environment:
+    #   - JELLYFIN_PublishedServerUrl=
+    extra_hosts:
+      - 'host.docker.internal:host-gateway'
+volumes:
+  jellyfin-cache:
+    driver: local
+  jellyfin-config:
+    driver: local
+```
+:::
 
-然鹅事实上，光是音乐专辑的刮削就足以令我恼火。国内**原生**对音乐元数据的刻写做得比较好的可能就网易云，何况网易云也并不全对；有些音乐平台下载的歌曲文件甚至莫得元数据，需要手动刮削。那么刮削用什么呢？有[文章](https://sspai.com/post/90896)推荐 MusicTag，然鹅同是从网易云那刮削，下载下来本是《紫罗兰永恒花园 OST》的曲目能给它识别成《凹凸世界五周年》，也是看笑了。
+## 媒体库组织
+
+我还是更习惯树形文件系统，媒体库还是太难为我了。那样的话，事情或许也很简单——许多成品 NAS 都有自带视频、相册之类的浏览功能。但很遗憾，自己装的 Ubuntu Server 自然什么都没有。
+
+我针对的还是 Jellyfin “神奇”的资源组织方式。就像[这篇《基于 Jellyfin 和音流的 nas 影音库搭建及踩坑》](https://sspai.com/post/90896)所说，“为什么不直接读取音乐标签进行专辑聚合”呢？
+
+### 元数据刮削：一笔糊涂账
+
+然而事实上，即使真的能做到自动专辑聚合，元数据本身的刻录和查询也是一片混乱。上面援引的博文推荐 MusicTag 这个工具，但同是从网易云那刮削，下载下来本是《紫罗兰永恒花园 OST》的曲目能给它识别成《凹凸世界五周年》，也是给我看笑了。更别说国外的 MusicBrainZ 数据库有相当一部分冷门曲目并没有收录（尽管 Spotify 等平台能够找到）。
 
 ![误刮削](./musictag-misfetch.webp)
 
-那国外平台呢？更是有相当一部分扫不出来。有些作者也不过是兴趣使然、随便做做，别说全平台了，能当专辑、EP 发到某一个平台上都已经烧高香了。这种叫冷门资源。还有一些歌曲能在 Spotify、SoundCloud 找到，但数据库网站就是没有收录。可不要认为比例不多，musicbrainz 扫不出来的歌占我歌库的 $\frac{1}{3}$。手动录入又十分繁琐，不就只能凑合用了，好用吗？实则不然。
+::: tip 音乐库最简方案
+文档这么说：我管你怎么整理，我只知道**是同一张专辑就该塞在同一个文件夹**。
 
-另一方面，影视、音乐、图书的分类并不能兼顾新兴媒体类型，比如音声，比如网文。豆瓣或许能够一定程度上打打辅助，那我问你，NSFW 资源呢？遗憾的是，我维护的大部分媒体都是 NSFW 的。这类资源刮削没有门路、媒体类型不好界定，组织起来尤其折磨。DLsite 上的同人音声尚有`dvtag`，国内作者通过订阅、打赏分发的音声又要如何应对？视频网站上薅下来的视频是可以有元数据，那些通过网盘分发的 MMD 呢？就很烦，哥们。
+那么事情也好办，就按专辑名来呗。好比如：`music/{album or "[standalone]"}/{artist1,artist2} - {title}`。
 
-总而言之，私以为媒体资源的元数据就是一笔糊涂账，很大程度上资源组织依然仰赖人工，对我个人而言体验并没有多少质的提升，反倒因为刮削需要解决的种种问题而身心俱疲。
+- 为什么要`or "[standalone]"`？
+  - 不单独收纳**没有专辑**的单曲，结果就会被淹没在大几百首、好几页的“歌曲”页面。
 
-> 话又说回来，我看多数的资源网站，基本采取论坛体、博客体、挂 Alist 这几种形式，或许也表明刮削比起长痛、短痛，更像是持续的剧痛（规模较大、源源不断、出处难辨）。
+- 要是有专辑重名了（比如两张专都叫`Fragrance`）？
+  - 没招，默认合并（甚至可以看到重复的曲号，都是第六首）。只能手工分离（`Fragrance - SoundzImage`和`Fragrance - Hatsune Miku`）。
+:::
+
+但比起前面所述的国内外两桌草台班子，更令我恼火的当属大把大把的、查无此人的“黑户”。怎么来的？音声、网文、3D 动画。
+
+> 我的整理方式和 acgdb 类似：3D 区、音声区（作者分发、油管录播、DLsite 正作）、书目区（漫画和文集）、写真区、插画区，此外新增音乐区。
+
+3D 区无论玩恋活还是 MMD，既有图集又有视频，无法按媒体类型区分。即便真要分，它算电视节目？电影？MV？分不明白。
+
+音声区大量的音频资源，摆烂一点直接用电子书库、按文件夹访查也不是不行，但显示出来反倒是专辑名（或者说 DLsite、系列作品名）更显眼，而非每一集的标题；若要用音乐库收纳，就得改造一番目录树适配它那个“一个专辑只有一个目录”的原则，工作量也不小。
+
+至于书目区，正经出版物想获取元数据并不难。相对的，“不正经”读物呢？网文可以依靠豆瓣之流；同人文只要作者有公开发布，留心寻找也是能记下元数据的（同人圈子对打 Tag 这件事很看重）；那么只剩下来源不正经、题材也不正经的“那种”作品了。它们流通的地方通常都是论坛这种早期网络社区，只知道个标题（很难说发帖人就是作者，万一是二道贩子呢？甚至文件名也不一定就是完整标题）。What can I say?
+
+偏偏这种不在台面上的“资源”我收纳了不少，哪怕有自动化工具，后续校对也是个体力活，何况很多资源只能一件件手工入库。饶了我吧。
+
+### 电子书：吃力不讨好
+
+小说漫画，或者说书籍媒体库，只能说真搭一个私人图书馆大概也和 Jellyfin 别无二致——满满的工作量。可能甚至有过之而不及。
+
+> 不禁想到米哈游创始人蔡浩宇的“快乐守恒定律”：你做的过程中如果很轻松快乐，那么你做出来的结果未必能给人带来快乐。  
+> 媒体库编排是不是也要“苦其心志、劳其筋骨”，才能有好的观影体验呢？但话又说回来，这种家庭影院通常都是自己管理自己用，费那么大功夫组织这些文件，观赏的体验又能改善多少呢？
+
+我相信大多数\*并不在乎资源来源\*的读者去找网络上流通的小说肯定优先去找 txt、doc(x) 这种容易打开的格式。但现有的私人图书馆，无论 Jellyfin 这种顺手实现的，还是 Kavita 这种专用的，**都不支持这些格式**。Calibre 也许可以，但**书目的元数据就成了另一桩麻烦事**。
+
+::: tip 最简方案
+那当然是通通转换成 pdf，单纯当作文件管理器那样访问文件夹、文件最简单。**但 pdf 对移动端并不友好，文字内容并不能自适应，更多还是用于漫画**。
+:::
+
+进阶一点的方案主要围绕 epub 电子书，毕竟漫画这块 pdf、epub、`.cb*`压缩包三者的页面版式不可能差太多，翻页起来其实没什么区别。
+
+::: info 压缩包漫画
+漫画本质上就是一页页的画嘛。许多网站本就提供试阅，给这些图片打个包也就是顺手的事。像我这样存储空间拮据的（主要还是[协议不通用](recents-11172025.md#硬件购置)），只能是哪种最节省空间就选哪种咯。
+
+Jellyfin 本身支持`.zip` `.rar` `.7z`。如果你打算另起炉灶，但选配的服务不支持这样通用的后缀名，也可以改变后缀：
+`.cbz`即 zip、`.cbr`即 rar、`.cb7`即 7z、`.cbt`即 tar。
+
+至于元数据，Jellyfin 文档指出**只有 epub 书籍才允许元数据集成在文件里**，对于这种漫画压缩包，需要另写`ComicInfo.xml`。也就是说，**每一本、系列的每一话，都需要单独的文件夹放置元数据和本体**。
+:::
+
+现有的 epub 编辑器并没有像写哔哩哔哩专栏（或者像 Word 文档）那样自动编纂页面的能力，操作起来更像是手搓 Web 三剑客（HTML、CSS、JavaScript）。所以，**图方便的话更建议在线转换**`.txt` `.doc(x)`文档。
+
+::: details EPUB 内容物
+epub 的 mimetype 通常标`application/epub+zip`，说明其本质是压缩包。解压出来通常分这么几块：
+- `mimetype`：资源类型标识，内容如上。
+- `META-INF/container.xml`：标明电子书（OEBPS 包）的根目录。
+- `OEBPS/`
+  - `Images/cover.*`：封面
+  - `Styles/*.css`：网页排版
+  - `Text/*.*htm*`：反正必须是 HTML。
+  - `content.opf`：电子书的元数据、内容物信息。
+  - `nav.*htm*` `nav.opf`：电子书的目录。前者为 epub3 标准，后者为 epub2 标准，通常在`content.opf`里特别标注。
+  - `Fonts/` `Audio/` ...：其他内容。
+
+所以我称编辑 epub 这件事为“手搓网站”，因为本来就需要按章回编排 Web 内容，这 OEBPS 的目录树也很有网站的味。
+:::
+
+::: warning 书目目录索引
+和 Calibre 等阅读器不同，Jellyfin 对目录的跳转**以 OEBPS 包为基准**，而不是以目录文件为基准。如果发现 Jellyfin 里**点目录里的章标题没有反应**，你需要用 Sigil 等编辑器将`nav.*`移动到`OEBPS/`目录下。
+:::
+
+::: note 文件组织
+实测结论是：可以不像漫画那样遵循官方文档“一书一目录”的要求，但**应尽量避免“一目录只有一 epub”的情形**。像以下情形 Jellyfin 会误判：
+
+- Books
+  - 正经的
+    - 《时间简史》.epub
+    - 毛泽东
+      - 《实践论》.pdf
+      - 《矛盾论》.pdf
+    - 《葬送的芙莉莲》.pdf
+  - 不正经的
+
+扫描结果是：“不正经的”和《时间简史》。其余读物无法直接访问（可能仍能搜索到）。
+:::
+
+## 穿透与反向代理
+
+如今连网易云也改得不知为何物了，于是我随身听的需求便也转向 Jellyfin。最简单的方法可以是 ZeroTier，但安卓有“同一时间只允许一个 VPN”的限制，所以在群友指导下搞了内网穿透（FRP）。
+
+此后，我遇到了子网划分的问题。起初这个问题并不起眼，直到我在户外同时尝试走 ZeroTier 和穿透，我才发现 frp 连上之后似乎更像是在本地回环，而 Jellyfin 似乎**对本地回环不设限速**。
+
+> ~~写着写着总会变成报流水账。~~
+
+AI 对此的解法是在 frp 这里记录下真实 IP。我选配的服务商支持 Proxy Protocol，也更推荐这么实现。但在实地测试后，发现 Jellyfin 并不直接支持 Proxy Protocol，那么就只能在 frpc 跟 Jellyfin 之间多加一层 nginx 做反向代理了（frps 显然我是动不了的）。
+
+方法很简单，frp 侧仍旧启用 Proxy Protocol，在 nginx 里剥离真实 ip。参见[官方文档](https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/nginx)。
+
+后来考虑到挂 web 的静态资源安全（防止意外删改），就顺势收紧 Jellyfin 容器的权限和性能分配。其中桥接网络让我想起最初的小巧思：我把 frp 挂在中间机器上，流量物理上不走内网不就好了。最终搭起来看了一眼日志，貌似连`nginx`都不需要了：
+```log
+[2026-03-09 10:08:57.650 +00:00] [INF] [23] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "172.17.0.1" closed
+[2026-03-09 10:08:58.280 +00:00] [INF] [28] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "172.17.0.1" request
+[2026-03-09 10:09:00.493 +00:00] [INF] [24] Jellyfin.Api.Controllers.UniversalAudioController: ...
+[2026-03-09 10:09:00.495 +00:00] [INF] [24] Jellyfin.Api.Helpers.MediaInfoHelper: ...
+[2026-03-09 10:09:00.495 +00:00] [INF] [24] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIP: "172.17.0.1", IsInLocalNetwork: False
+```
+注意到最后一句`IsInLocalNetwork: False`，它似乎并不认为 Docker 容器的桥接网段是内网网段。这样一来连 frp 隧道都不需要动，天然就完成了我的小巧思。

docs/diaries/wbsy/recents-11172025.md

@@ -1,4 +1,4 @@
-# 碎碎念（25 年末版）
+# 碎碎念#1
 最近折腾了不少东西，心情也起起伏伏。《如我所书》取自崩铁的同名词条，个人也倾向于记录那些“能成篇的”专栏；咱这主题又没动态功能，思来想去还是写到这充当《记忆的质料》吧。
 
 ## 可爱一点的博客主题

package.json

@@ -11,14 +11,14 @@
   },
   "devDependencies": {
     "@vuepress/bundler-vite": "2.0.0-rc.26",
-    "@vuepress/plugin-docsearch": "2.0.0-rc.121",
-    "@vuepress/plugin-remove-pwa": "2.0.0-rc.118",
-    "katex": "^0.16.28",
-    "mermaid": "^11.12.2",
+    "@vuepress/plugin-docsearch": "2.0.0-rc.124",
+    "@vuepress/plugin-remove-pwa": "2.0.0-rc.124",
+    "katex": "^0.16.35",
+    "mermaid": "^11.12.3",
     "sass-embedded": "^1.97.3",
-    "vue": "^3.5.27",
+    "vue": "^3.5.29",
     "vuepress": "2.0.0-rc.26",
-    "vuepress-theme-hope": "2.0.0-rc.102"
+    "vuepress-theme-hope": "2.0.0-rc.103"
   },
   "packageManager": "pnpm@9.15.3+sha512.1f79bc245a66eb0b07c5d4d83131240774642caaa86ef7d0434ab47c0d16f66b04e21e0c086eb61e62c77efc4d7f7ec071afad3796af64892fae66509173893a"
 }