UX: Improve workflow for hidden files about photoprism

[lastzero]

Since these typically involve unknown unknowns and usually not that many pictures are affected (in my case 7 out of 100k+), it can be difficult to provide specific information that would enable end users to resolve the underlying issue(s). Also note that whenever we learn of issues with specific file formats, we will, where possible, provide a fix for them in an upcoming release. In these (most common) cases, you simply need to re-index.

The 7 affected videos in my library are clearly missing a thumbnail. As far as I can tell, these are mostly older QuickTime files that may simply not be compatible with FFmpeg:

To find and fix the cause in this case, you would need to take a look at the following command, e.g. check the error returned by enabling trace log mode, and then check the manual for solutions (or follow any helpful advice displayed as part of the error message):

photoprism/internal/photoprism/convert_image_jpeg.go

Lines 29 to 33 in ee8de5e

	// Extract a still image to be used as preview.
	if f.IsAnimated() && !f.IsWebP() && c.conf.FFmpegEnabled() {
	// Use "ffmpeg" to extract a JPEG still image from the video.
	result = append(result, exec.Command(c.conf.FFmpegBin(), "-y", "-ss", ffmpeg.PreviewTimeOffset(f.Duration()), "-i", f.FileName(), "-vframes", "1", jpegName))
	}

In some cases, problems can also be caused by configuration mistakes (e.g. FFmpeg disabled) or problems with the file system permissions. Our docs therefore include the following checklist to help you find and resolve such issues:

• https://docs.photoprism.app/getting-started/troubleshooting/#missing-pictures

[causa-prima]

Thanks for the swift reply! I forgot about the checklist in my original feature request, so I updated it with my thoughts about it as an alternative that I considered.

Since these typically involve unknown unknowns and usually not that many pictures are affected (in my case 7 out of 100k+), it can be difficult to provide specific information that would enable end users to resolve the underlying issue(s).

I fully understand that. Still, the code encountered an issue somewhere, and it would be nice to know in which part of the indexing that happened to at least have some hint about what went wrong. To me, anything is better than nothing here, so I'd be much happier if I saw some error message for the cases of unknown unknowns somewhere in the hidden-files-ui without have to dive into logs.

Also note that whenever we learn of issues with specific file formats, we will, where possible, provide a fix for them in an upcoming release. In these (most common) cases, you simply need to re-index.

I'd argue that showing these issues in the hidden-files-ui would make it much easier for you to learn about these problems as well, as it could be much easier to report them for the average user.

To find and fix the cause in this case, you would need to take a look at the following command, e.g. check the error returned by enabling trace log mode

I don't think most users would be able to do that. How would I even know about that ffmpeg call and its parameters without diving into the source code?

To further add to my initial idea: As a programmer myself, I'd image it could be as easy as saving any error messages from indexing to some "error"-property for each file, and displaying that in the hidden-files-ui on each picture card. If possible, the message could be made user-friendly for known / common issues, possibly with a link to more info or steps to fix the problem. What would be the challenges with that?