青阳龙野

您好，这一问题肯能是由于操作系统环境导致的，您可以尝试：1，重启程序；2，重新安装Java；3，调整屏幕分辨率；4，重新安装kiftd。希望可以帮助到您！

您好，问题已收到。kiftd的账户分组实际上是一个“身份标识”而非“归类选项”，也就是说，一个用户归为某一小组后，他可以自由访问所有由同小组成员创建的、权限约束为“仅小组”的文件夹，这时，他可以通过将文件上传至不同的小组文件夹里实现文件分类（比如，账户root同时属于A、B、C三个小组，那么如果他希望将某个文件分享给A组，就应该把这一文件上传至A组的“仅小组”文件夹中）。如果一个账户隶属于多个小组，那么他会同时属于所有小组，这一身份无法选择。您可以根据上述特性对账户的身份进行管理，从而贴合您希望的使用场景。

您好。该问题是由于kiftd内置的“FFMpeg”视频解码引擎无法兼容您所使用的平台（ARM）导致的——这是一个内置的二进制程序。您可以选择禁用FFMpeg解码功能，从而令kiftd屏蔽此差异正常启动（但是也将无法再播放非MP4格式的视频），或是自行提供一个适合您平台的FFMpeg引擎版本。相关内容可以参考《kiftd说明文档》中的【禁用“在线解码”功能】或【替换 ffmpeg 视频解码引擎】（p89）有关介绍。

您好。由于kiftd官方目前尚未对类似功能进行过尝试，因此，对于该功能的重构无法给出有价值的参考建议，深表遗憾。您可以根据kiftd源代码设计整合方案，并对其进行二次开发来实现所需功能。

您好，问题已收到。 对于大多数文件系统（包括操作系统本身的文件管理器）而言，一个页面（文件夹）的加载速度主要受单一文件夹的文件数量影响——kiftd也是如此。当一个文件夹内文件数量太多、加载太慢时，推荐您将内部文件分开放置来加快加载速度：例如某个文件夹下有10W个文件，那么不妨将其分为20个文件夹，每个文件夹2K个文件放置，这样不仅能大大提高每个文件夹的加载速度，而且对于查找也更为有利。当然，如果情况是每个文件夹内的文件数量不多，但总体数量确实很大（文件总数超过20W个），那么您也可以选择将一些零散且不常用的文件打包在一起存放，从而减少文件数量，提升整体效能。值得一提的是：kiftd的性能不受存储文件的体积影响，仅受文件数目的影响，即10个10GB的文件和1千万个1KB的文件相比（总大小都是100GB），后者的性能会远远差于前者。

非常感谢您的宝贵建议！您的建议已经仔细阅读并记录，它们将作为未来升级的重要参考建议。再次感谢您的反馈，这是kiftd不断进步的最佳动力！

您好，建议已收到。这个建议之前被其他用户提出过，但从实际体验来看，此设计会让使用者感觉更加“焦急”（如果用户在意上传速度的话，那么说明上传速度应该不理想。而上传速度一般是实时变化的，普通用户习惯以最大速度作为标准预估上传时间，但实际情况往往要更慢一些，所以才会产生这种感受），同时也很难找出一个能让上传速度显示得足够美观的设计，因此最终该设计并未能落实。目前决定仍维持原设计。

这个功能确实很有用，它也是研究列表中的重要构想之一。未来如果有可行方案会尝试加入这一功能。

您的新建议已经收到，在此为您逐一回复： 1、2、4建议已经记录，它们将被作为后续升级的重要参考。 3建议之前被其他用户提到过，但经过研究，认为该功能并非kiftd的设计初衷，同时已经有很多成熟的软件具备类似的功能，kiftd与之相比并不具备优势，因此目前暂无此计划。

@jerryyangboyu 是的。实际上，能否播放并不是取决于后缀，而是取决于视频的编码格式，只要是AVC H.264格式的视频，那么无论其后缀名为何（例如.mov），改为.mp4后都可以在大多数浏览器上播放。kiftd是出于对大多数浏览器的适配考虑，因此目前只允许mp4后缀的文件打开播放器。如果您确认您的视频格式是AVC H.264格式编码，那么确实可以通过修改其文件后缀名的方式进行在线播放，这一点也是官方支持的做法。