Ubuntu 26.04 Dolphin/Nautilus 不显示 MP4 缩略图:NTFS 预览与处理器冲突排障

在 Ubuntu 26.04 上安装 Dolphin 后,我遇到了一个颇有迷惑性的故障:MP4 文件始终显示为蓝色的通用视频图标,没有画面缩略图。

最容易想到的两个开关其实都已经打开了:

Dolphin 工具栏的“显示预览”(Show Previews)已经启用;
设置里的视频缩略图插件也已经勾选。

视频本身能够正常播放,ffmpeg 也能成功解码。最后排查发现,这不是一个问题,而是两个条件叠加:NTFS 挂载盘被 KIO 走了“慢速设备”的预览限制,同时系统里启用的 GStreamer 视频缩略图处理器本身不能工作。

环境和现象

Ubuntu 26.04、GNOME/Wayland、Dolphin 25.12.3、ffmpegthumbs 25.12.3。视频位于通过 ntfs3 挂载到 /run/media/... 的数据盘。

先安装 Dolphin 使用的 FFmpeg 缩略图组件:

sudo apt update
sudo apt install dolphin ffmpegthumbs ffmpeg

这里容易混淆两个名字:

ffmpegthumbs 是 KDE/Dolphin 使用的缩略图插件;
ffmpegthumbnailer 常见于 Nautilus、Nemo 等遵循 Freedesktop 缩略图规范的文件管理器。

给 Dolphin 装错后一个包,不一定能让它生成视频缩略图。

第一层坑:本地 NTFS 盘也可能命中“远程文件”上限

当时 ~/.config/kdeglobals 中有如下配置:

[PreviewSettings]
EnableRemoteFolderThumbnail=false
MaximumRemoteSize=0

乍看之下,视频位于本地硬盘,MaximumRemoteSize 应该无关。但 KIO 的预览任务并不只看 URL 是否为本地文件:本地文件如果来自被判断为较慢的设备,也会使用这一上限。相关判断可以在 KDE KIO 的 PreviewJob 源码和 KIO::PreviewJob 文档中找到。

我的配置把上限设成了 0,于是挂载盘上的视频在真正进入解码阶段前就可能被跳过。

可以在 Dolphin 的“配置 Dolphin → 预览”里提高“远程存储上的文件”大小限制。比如允许最大 10 GiB 的文件生成预览,等价配置为:

[PreviewSettings]
MaximumRemoteSize=10737418240

这里是“单个文件允许生成预览的最大尺寸”,并不是缩略图缓存要一次占用 10 GiB。按自己的视频大小设一个合理值即可。

第二层坑:GStreamer 和 FFmpeg 处理器同时启用

提高大小限制后,缩略图仍然没有出现。继续检查发现,Dolphin 的视频预览列表里同时启用了:

gst-video-thumbnailer;
gsthumbnail;
ffmpegthumbs。

直接测试 GStreamer 处理器:

gst-video-thumbnailer \
  --input-path "/path/to/video.mp4" \
  --output /tmp/test-thumb.png \
  --size 256

本机返回:

Failed pre-rolling pipeline: Your GStreamer installation is missing a plug-in.

这给出了直接证据:GStreamer 这条缩略图链路不可用。只保留 ffmpegthumbs,关闭两个 GStreamer 视频缩略图项,再彻底退出并重新打开 Dolphin,预览立即恢复。

不能仅凭现象断言 Dolphin 内部永远以某个固定顺序选择处理器。不过本次可以确定的是:GStreamer 处理器单独测试失败,而隔离到 ffmpegthumbs 后,目标目录中的 81 个 MP4 全部成功写入缩略图缓存。

最终设置

在 Dolphin 中打开“配置 Dolphin → 预览”(不同版本可能位于“常规 → 预览”):

开启“视频文件(ffmpegthumbs)”;
暂时关闭名称含 GStreamer、gst-video-thumbnailer 或 gsthumbnail 的视频项;
把远程/慢速存储的文件大小上限调到能覆盖实际视频;
关闭所有 Dolphin 窗口,再重新打开。

如果刚安装的插件没有出现在设置列表中,可以重建 KDE 服务缓存:

kbuildsycoca6 --noincremental

然后再次退出并启动 Dolphin。

一组实用的诊断命令

确认软件包版本:

dpkg -l dolphin ffmpegthumbs ffmpeg

确认文件被识别成视频:

xdg-mime query filetype "/path/to/video.mp4"

查看编码信息:

ffprobe -v error \
  -show_entries stream=index,codec_name,codec_type,profile,width,height \
  -of default=noprint_wrappers=1 \
  "/path/to/video.mp4"

确认 FFmpeg 能真正抽出一帧:

ffmpeg -hide_banner -loglevel error \
  -ss 2 -i "/path/to/video.mp4" \
  -frames:v 1 -f null -

确认 ffmpegthumbs 插件没有缺少动态库:

ldd /usr/lib/x86_64-linux-gnu/qt6/plugins/kf6/thumbcreator/ffmpegthumbs.so \
  | grep 'not found'

最后一条没有输出通常是好事。也可以观察最近是否产生了缓存文件:

find ~/.cache/thumbnails -type f -mmin -2 | wc -l

补充:Nautilus 也能预览 MP4,但处理器要单独修

Nautilus 同样支持 MP4 缩略图,但它不读取 Dolphin 的插件选择。它通过 Freedesktop 缩略图描述文件调用系统中的处理器:

/usr/share/thumbnailers/*.thumbnailer

这台机器上的 Nautilus 50.0 原本只注册了 gst-video-thumbnailer,也就是前面已经单独测试失败的 GStreamer 处理器。Nautilus 的设置本身没有关闭预览:

gsettings get org.gnome.nautilus.preferences show-image-thumbnails
gsettings get org.gnome.nautilus.preferences thumbnail-limit

当时的结果为:

'local-only'
uint64 50

第二个值以 MB 为单位。目标目录中最大的视频约 27 MB,因此这次不是 50 MB 上限导致的。

先安装适用于 Nautilus 的 FFmpeg 处理器:

sudo apt install ffmpegthumbnailer

安装后可以看到两个 MP4 处理器同时存在:

rg -l 'video/mp4' /usr/share/thumbnailers/*.thumbnailer

/usr/share/thumbnailers/ffmpegthumbnailer.thumbnailer
/usr/share/thumbnailers/gst-video-thumbnailer.thumbnailer

这里又踩了一次相同类型的坑:仅仅安装 ffmpegthumbnailer 后,Nautilus 仍然选择了损坏的 GStreamer 处理器,并在失败缓存中写入一个 1×1 PNG 标记。之后它不会对同一文件立即反复尝试,所以看起来像新装的处理器完全没有生效。

先分别确认两条链路的结果:

gst-video-thumbnailer \
  --input-path "/path/to/video.mp4" \
  --output /tmp/gst-test.png \
  --size 256

ffmpegthumbnailer \
  -i "/path/to/video.mp4" \
  -o /tmp/ffmpegthumbnailer-test.png \
  -s 256 -f

本次前一条报缺少 GStreamer 插件,后一条成功生成 PNG。确定故障后,使用 Debian 的 diversion 机制把损坏的系统注册移开:

sudo dpkg-divert --local --rename --add \
  /usr/share/thumbnailers/gst-video-thumbnailer.thumbnailer

文件会被保留为 gst-video-thumbnailer.thumbnailer.distrib,并非删除;软件包升级也会尊重这个 diversion。如果以后修好了 GStreamer,可以恢复:

sudo dpkg-divert --rename --remove \
  /usr/share/thumbnailers/gst-video-thumbnailer.thumbnailer

接着移走旧的失败缓存并重启 Nautilus。这里保留备份,不需要删除正常缩略图:

mv ~/.cache/thumbnails/fail \
  ~/.cache/thumbnails/fail.before-ffmpegthumbnailer
nautilus -q

如果 fail 目录不存在,跳过 mv 即可。重新打开目录后,Nautilus 会使用 ffmpegthumbnailer 生成新缓存。

最终做了两次端到端验证:

普通 H.264 MP4 成功生成 288×512 PNG;
NTFS 数据盘上的实际 HEVC MP4 同样成功生成 288×512 PNG。

这说明修复的不只是命令行程序,Nautilus 从发现文件、选择处理器到写入 ~/.cache/thumbnails/x-large/ 的完整链路都已经恢复。

几个容易误判的地方

工具栏的“显示预览”和设置里的缩略图插件是两层开关,少一个都不行;
“远程存储”大小限制也可能影响本机挂载的可移动或慢速设备;
ffmpeg 命令行解码成功,只能证明编解码链路正常,不能证明 KIO 最终选中了哪个缩略图处理器;
同时勾选多个视频处理器,不等于前一个失败后一定会按预期回退;
Nautilus 会缓存缩略图生成失败的结果,安装新处理器后可能需要移走 ~/.cache/thumbnails/fail;
不必一上来就删除整个 ~/.cache/thumbnails。先调整处理器、完全重启 Dolphin,再观察新缓存是否生成。

小结

这次真正有效的修复不是反复开关“显示预览”,而是同时解决两层问题:

提高 KIO 对远程/慢速设备的预览文件大小限制;
禁用已经证实不可用的 GStreamer 处理器,只让 Dolphin 使用 ffmpegthumbs。

当“插件已安装、预览已打开、视频也能播放”却仍然没有缩略图时,优先沿着“文件是否在挂载盘 → 大小限制 → 实际处理器 → 单独解码测试”这条链路排查,会比清缓存和盲目补编解码包更快。

Nautilus 的最终思路相同,只是组件换成了 Freedesktop .thumbnailer 注册和 ffmpegthumbnailer:先证明具体处理器能否工作,再解决冲突和失败缓存,不要把“包已安装”等同于“文件管理器已经选中它”。