一个群晖 Photo Station的替代品，采用VUE前端+Flask后端实现，数据库采用PostgreSQL。

如果你和我一样恰好有很多"人脸识别"的“素材”需要管理，恰好有很多"压缩包"形态或者文件夹形态的"图片集"需要管理查看，图片总数是百万级别的话，那么不妨继续看下去。

对于常规（100W）以下图片的“看图”需求，有以下几个项目建议使用：

1. PLEX/emby，商业版软件，NAS必备软件二选一，可以看图，看电影/视频，电视节目等。
2. Jellyfin，emby的开源版本，我最初的选择之一，也是写这个MyNAS项目时候的主要参考目标之一。
3. Lychee，非常漂亮的在线看图web界面，支持第三方直接导入在服务器存储的图片，如果没有“视频观看”的需求，而仅仅是“图片查看”的需求，这个软件足以满足，实际上如果不是找到这个项目的时间点太晚，我可能就不会写MyNAS这个项目了。

另外，对于其他家用/个人用服务部署需求，可以参考家用自部署系统部署的相关项目去找。

项目来源，是我(llzx373)在使用群晖NAS自带的Photo Station的过程中，遇到了很多问题，最开始修改了很多PhotoStation的php代码来满足我的需求，但后续维护中遇到很多无法很方便改写的问题，最终决定从头自己写一个项目，就是现在的项目MyNAS，数据库选用PostgreSQL，是因为群晖自带一个PostgreSQL，避免多余的数据库部署导致的其他问题，目前为止，主要为以下需求服务：

1. 图片，图片集,视频的查看
2. 带大纲视图，允许大纲调整，分节字数统计的写作环境
3. 统一的搜索和随机查看视图

目前为止实现的需求如下：

这个需求，主要是满足“图片集”查看，“图片查看”两个核心诉求，最终实现为：

所有图片，视频均认为是“视频+图片”的形态的库，库包括库名称，库路径，其中库路径为服务器的地址。

库支持手动的发起检查操作，发起检查时候： 1. 状态变为syncing 2. 后台通过python的walk逻辑，遍历整个目录，遍历操作包括： 1. 对于图片，视频文件，以及路径的文件夹进行入库 2. 对于压缩文件(zip,rar,cbz,cbr)，认为压缩文件是目录，内部的图片（压缩包内不支持视频文件，测试中性能表现太过糟糕）文件是文件 3. 入库完成后，对所有文件夹逐个级别设置文件夹封面为其下图片或者视频（这一步操作在绝大多数NAS系统会由于种种bug无法全部设置封面，也是我这边主要解决的问题之一）。 4. 逐个文件扫描时间以及区分文件类型（对于压缩文件内的文件不处理时间）

以目录的形态查看“图片集”，可以查看当前文件夹下的文件，以及文件夹，支持到子文件夹的跳转，以及回到多级父级的任一级别，对于图片，视频跳转到单独的图片查看或者视频观看视图。

其中封面为即时压缩的240*320图片。注：在绝大多数NAS或者图片查看软件中，图片压缩是预先压缩而非即时（典型代表群晖/plex，导致超大图片集合扫描速度非常慢，百万级别图片扫描时间周期为“周”级别），或者即时压缩没有持久化（典型代表是各路桌面图片查看器，导致重复查看相同文件或者文件夹会非常慢）。

查看图片：

1. 支持查看压缩后文件(高度1024的图片文件，主要应对不在内网而在公网的时候，网络速度过慢无法查看原图的情况)，或者原文件（如果网络状况很好）
2. 支持查看前一页，后一页，并且查看后一页支持图片文件的预缓存，由于必然存在的“查看下一页”的情况，预先请求下一页图片，点击下一页时候可以直接利用web本身的请求缓存做到。（最初实现采用web的localStorage，但localStorage大小太小，如果后续web缓存处理遇到其他问题，考虑直接使用indexDB）。这里原本实现了动画，但后续因为效率问题，废弃了相关逻辑。
3. 支持双页模式，以及调换双页模式的左右顺序，观看“图片集”的时候，保证阅读效率最大化，以及阅读顺序。
4. 支持跳转到前一个/下一个文件夹，观看”图片集“的时候，看一个到尽头之后，会有查看”下一个文件夹“的需求，因此实现。

支持网页视频观看，对于web无法支持的视频，支持ffmpeg的服务端解码后的观看，两种观看模式都支持无论任何时长视频的随机进度的跳转。

web视频观看直接引用html5的video标签，支持范围主要是h264/acc编码的视频，以及flv视频（通过flv.js支持），控制组件为原生组件。

ffmpeg观看，为服务端解码为HLS视频流后发送到页面，视频控制组件为自行开发。服务端

这个需求的原始来源，是因为用的一个云写作软件“墨者写作”频繁出现吞稿子的问题，而另外一个用着特别顺手的Scrivener又迟迟不能发布win下的稳定版本，于是就此来源，写了这么一个东西出来。

主要功能是，作品管理，写作模式，多个视角的大纲模式，单独的笔记和简介，自动的字数累计统计，章节拖动，以及附带的自动章节编号。

支持新建，删除，修改作品。支持修改作品封面。

左，中，右三栏。

左边是目录树，主要功能包括：无限级别的目录深度，自动的字数统计，以及章节字数向上自动刷新，自动的章节编号。

右边是字数任务，简介以及笔记栏目。设置章节预计字数用于统计写作进度。简介，笔记两个栏目中，简介可以在大纲视图中直接批量编辑，适合写作时候，必须先写大纲而后写内容的方式，笔记栏目用于临时记录的章节笔记。

中间是编辑，预览，大纲，任务四个视图。

编辑视图为自动着色的编辑器（CodeMirror），写作实时高亮，因此不需要单独的同步预览窗口（另外，目前不考虑单独的写作配图，以当前考虑，配图后续是在单独的word中处理）。

预览视图，是以当前章节为根目录，生成的所有下属章节内容的编号正文，写作时调整完成目录之后，自动生成所有的章节编号。

大纲视图，是编辑当前章节的下属章节的简介内容。

任务视图，主要是针对目标字数设定的目标是否完成等指标。

首页以及每个库下属的“资源视图”。

支持：随机查看/搜索指定条目，范围为所有条目/最近新增n条的目录（图包情况）/文件（视频情况），支持结果集合条目数量。

后端采用PostgreSQL的ilike忽略大小写，结合gin索引进行的匹配搜索，并未采用单独的全文索引。

1. 从文件或者目录跳回上级时候，无法回到对应页而是回到当前页。(2020-2-10 已经修正，不排除依然存在bug)

2. 不支持无效条目的删除，早前计划采用版本号管理，但后续修改时候，刷新版本号遇到bug，需要修改。

1. 对象tag功能，“图片集”、“视频”在名称之外，还需要有创作者，表演者等很多其他属性，目前虽然已经有独立的资源库支持，但并未集成到本项目，缘由主要是墙导致的相关网站无法连接以及相关网站对爬虫逻辑的封锁。
2. 扫描性能问题，目前是逐个条目insert on ON CONFLICT逻辑，后续需要重新考虑实现（目前每百万条数据入库时间在我个人环境下大约一个小时，已经是比较慢了）。
3. 对KODI的支持，目前实现的纯web形态，可以解决PC，移动端的相关需求，但是对于电视上看，目前无法直接解决，因此考虑单独开发KODI插件处理。
4. IOS原生解码的支持，目前web端支持服务端解码，但对服务端有解码性能要求，测试中目前看纯CPU解码性能不足，需要依赖单独的显卡（显卡级别最低建议Nvidia P600/1050，另外如果是linux的话，不支持AMD），在IOS端，后续考虑单独开发APP支持。

1. 编辑器跳转问题。当操作逻辑为：从编辑视图跳转到大纲视图-》跳转到别的章节的大纲视图-》跳转到编辑视图 的时候，编辑视图不会直接变为目标的文本，而还是显示之前的文本，必须手动点击编辑区域才会正常变化，已知是CodeMirror插件问题，原插件为jquery插件，在vue使用时候导致当前bug，如果有解决办法，希望告知。