https://xie-blog.pages.dev/学习笔记、技术折腾、影音娱乐与游戏生活。当前文章为示例内容。zh-CNhttps://xie-blog.pages.dev/#post/nas-cinemahttps://xie-blog.pages.dev/#post/nas-cinemaThu, 15 Oct 2026 00:00:00 GMT影音娱乐讨论 NAS 影音播放时，我习惯先把它想成一条链路：影片文件放在哪里，服务器怎样读取和整理，网络如何传送，播放器又怎样把画面交给电视或显示器。某一环节不匹配，最终看到的效果就可能和文件本身不同。 文件信息是起点。容器、视频编码、音轨、字幕和动态范围信息各自承担不同作用，文件名和媒体库里的海报则更多帮助人识别内容。整理资料时，把这些信息分开看，比只记一个“4K”标签更有用。 接下来要分辨服务器是在直接传送，还是需要实时转换。直接播放依赖播放端能够理解相应格式；发生转换时，服务器负担、字幕处理和目标设备能力都会参与结果。这个判断适合从媒体信息和播放状态里逐层观察，不宜只凭画面观感猜原因。 杜比视界也需要放在兼容链路里理解。文件所带的配置、服务器的处理方式、播放器的解码能力以及显示设备的支持情况都可能影响呈现。Emby 和 SenPlayer 在这里分别处于媒体管理与客户端播放等不同位置，具体组合能力应以实际设备和软件说明为准。 遇到色彩异常、画面变暗或字幕没有出现时，我会先记录同一影片在不同播放路径下的差别，再分别查看文件信息、服务器状态、客户端设置和显示设备模式。每次只改变一个条件，比较结果才有解释力。 这篇笔记是一份排查思路的草稿，不代表任何真实部署已经通过验收。真正搭建时，还要按自己的文件、网络和设备逐项核对；把链路画清楚，至少能让问题从“影音怎么坏了”变成一个可定位的小问题。 https://xie-blog.pages.dev/#post/fluid-noteshttps://xie-blog.pages.dev/#post/fluid-notesWed, 14 Oct 2026 00:00:00 GMT学习笔记伯努利方程把压力、速度和高度放在同一份机械能账本里。对稳态、不可压缩、黏性影响可忽略的流动，在一条流线上可以写成 p + ρv²/2 + ρgz = 常数。每一项都对应单位体积流体的机械能。 这个关系不是说流速一变，压力就一定按某个简单比例变化。它要求问题满足相应假设，也要沿流线比较。若泵、涡轮、明显黏性损失或复杂边界条件参与其中，完整分析还需要把这些影响纳入能量关系。 静止液体里，速度项消失，压力随深度增加。若自由液面上的压强作为参考，深度 h 处的表压可写作 p=ρgh。于是平板受到的压力不是处处相等，而是从浅处到深处逐渐增大。 把板面各处的微小压力累加，可以得到总压力；再计算这些压力对某条参考轴的力矩，就能找到等效合力的作用点，这个位置称为压力中心。它是分布载荷的等效描述，不表示液体只在那个点施压。 对于竖直平面，压力中心通常位于形心下方，因为较深位置的压力更大，对力矩贡献也更大。水平面上的深度一致，压力均匀，压力中心则与受压面积形心重合。倾斜面还要明确坐标和角度定义，避免套用不匹配的公式。 复习时我会分成两张图：一张画流线上的能量项，另一张画静水压力分布与力矩。先说清楚假设、参考面和坐标，再代数计算，往往比一开始背结论更不容易混淆。 https://xie-blog.pages.dev/#post/switch-noteshttps://xie-blog.pages.dev/#post/switch-notesSat, 10 Oct 2026 00:00:00 GMT游戏生活最近我给游戏清单做了一次小整理。以前买过或收藏过的游戏都挤在一起，打开列表时很难判断自己现在真正想玩什么。于是我只留下三个区块：正在玩、下一个想试、暂时搁置。 正在玩的游戏旁边，我记下最近一次停在哪里，例如“港口任务之后，回村里整理材料”。这比只写章节编号更容易重新进入状态，也不会把游戏变成一份需要追赶的进度表。 存档整理需要分清游戏本身、主机账户和设备提供的管理方式。不同游戏和服务对存档的处理并不完全相同，所以我会先查看当前设备与游戏的说明，再决定哪些资料能备份、如何迁移。 对自己来说，最重要的习惯是避免在没有弄清楚后果时覆盖旧进度。准备切换主机或账户之前，先确认想保留的存档属于哪个游戏和用户，再核对该游戏适用的官方流程。 清单里也有几款被我标成“以后再说”。这不是放弃，只是承认空闲时间有限。与其每晚对着一长串名字犹豫，不如选一款现在最想打开的，让游玩本身保持轻松。 整理完之后，屏幕上的图标没有变化，变化的是我更容易找到想继续的那一款。存档和进度仍以设备提供的正式管理方式为准，这份笔记只是个人规划的示例。 https://xie-blog.pages.dev/#post/nas-docker-backuphttps://xie-blog.pages.dev/#post/nas-docker-backupThu, 08 Oct 2026 00:00:00 GMT技术折腾提到容器备份时，容易把“保存镜像”“保存配置”和“保存应用数据”混成一件事。它们对应的内容不同，单独留下一份镜像并不自动意味着应用里的资料也能恢复。 我会先画出一个应用依赖图：哪些设置描述容器如何启动，哪些目录承载需要长期保留的数据，哪些外部服务或网络关系会影响应用可用。图不需要复杂，能把边界说清就有帮助。 再从恢复目标倒推备份范围。比如希望恢复的是配置、用户上传的文件，还是某个时间点的完整应用状态。目标越明确，越容易判断需要记录哪些版本信息、目录关系和依赖。 一致性也值得单独考虑。应用正在写入数据时复制文件，得到的内容未必代表同一个时刻。具体如何暂停写入或使用应用支持的导出方式，要依据服务自身的文档和运行情况设计。 备份存在不等于恢复可行。一个清晰的恢复说明应包含所需材料、依赖关系、预期结果和验证方式；演练应在可控的测试环境进行，避免把生产数据当作试验对象。 这是一份概念整理，没有对应某台 NAS 或某个容器的实测结论。真正采用前，还要逐项核对平台功能、应用说明和数据重要性，再选择合适的保留周期与恢复策略。 https://xie-blog.pages.dev/#post/python-noteshttps://xie-blog.pages.dev/#post/python-notesTue, 06 Oct 2026 00:00:00 GMT学习笔记刚学 Python 时，我常常急着把整段代码写出来，遇到结果不对就不知道从哪里找。后来我先在纸上写清楚程序拿到什么输入、要做什么处理、最后应该给出什么输出。 例如，一个整理购物清单的小练习，输入可以是几项名称和数量，处理是合并重复名称并计算总数，输出则是一份便于阅读的清单。先明确这三部分，变量和函数的名字也更容易取。 函数适合把一个有明确职责的步骤单独表达出来。输入通过参数传入，结果通过返回值交回调用处，这样阅读者不必同时记住很多隐藏状态。一个函数越容易用一句话说明，通常越容易检查。 错误信息也可以当作线索。与其一次改动很多地方，不如先确认报错指向哪一行、相关变量此时是什么，再提出一个小假设并验证它。这个过程比猜测整份程序更可控。 我还会保留一两个具体例子，手工推演预期结果。空列表、重复项目或数量为零这样的边界情况，能提醒自己程序不仅要处理最顺手的输入，也要清楚地面对不常见的输入。 这份学习记录不依赖某个特定 Python 版本或开发环境。练习时可以先选一个很小的问题，把输入和输出写在旁边，再逐步加入处理步骤；理解每一步，比堆出一长段代码更重要。 https://xie-blog.pages.dev/#post/minecraft-walkhttps://xie-blog.pages.dev/#post/minecraft-walkSat, 03 Oct 2026 00:00:00 GMT游戏生活进入世界后，我没有马上放下工作台，而是沿着河边走了一段。两侧的山坡高低不同，几棵树的影子落在水面上，河道在一块平地旁边转了个弯。 我先从远处观察轮廓，再走近看看地面起伏。平地足够放下主要结构，河道又能自然地形成入口方向，于是我把这里记作候选位置，没有立刻铺开大面积地基。 建筑草图只画了几个方块：靠山一侧留作储物空间，朝河的方向开窗，屋顶高度随着坡地稍作变化。简单的比例关系比一开始选很多装饰块更能决定整体是否协调。 材料也从周围环境出发挑选。木材和石块的颜色放在一起时，我会先做一小段墙面观察对比，再决定是否继续。小样可以快速看出质感和明暗是否合适。 建造中途我退后几步，从不同角度看了一遍。靠水的立面显得太整齐，就补了一段高低变化；屋顶和山坡的线条仍然有点冲突，我把它记进下一次修改清单。 这次漫游最后只留下了一个选址和一张草图。游戏里的工程可以慢慢长出来，先理解周围地形，再让建筑回应环境，比一口气填满每个空地更让我享受过程。