UX: Improve workflow for hidden files

[causa-prima]

Describe what problem this solves and why this would be valuable to many users

I see some hidden files, but I don't know why they are hidden or what to do about it. I also have a hard time telling whether there are new hidden files from the latest indexing, or if I already checked the hidden files.

Describe the solution you'd like

1. I would like to easily be able to know the reason why a file was hidden.
2. I would like to be told what I can do to handle this issue.
3. I would like to be able to mark a hidden file as "handled", i.e. I confirm that I've seen the issue. This could then hide the file from the hidden files, so I know which files I already tried to fix (of course with an option to show the files marked as handled again for later review.)

Describe alternatives you've considered

Following the checklist about why a file might be hidden (https://docs.photoprism.app/getting-started/troubleshooting/#missing-pictures). To me, this is not an alternative for the average user because of the these reasons:

1. I have to find this checklist.
2. I have to be able to identify which of the stated possible reasons applies for each file. Note that this is a task that requires certain expertise, which a lot of users do not have. Thus, I might miss the actual cause and not be able to actually figure out what's wrong.
3. Manually checking potentially takes a lot of time, as I have to check a lot of possible reasons.

Additional context
In my library, I have 27 hidden files. Mostly videos, but also some RAW files and one JPEG. The JPEG is the only file that shows an error ("image: unknown format"), but I have to go to the files tab of that picture to see that. For the other files, I have no idea what's wrong with them. The videos seem to play just fine, and for both the videos and RAW files, the extracted metadata looks fine. Only the missing picture indicates to me that something went wrong. But as there is no information shown about what is wrong with them, I don't know what I can do to fix the issues. Also, also have no way to tell which files I already tried to fix (which files I already "handled", but could fix).

[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?