starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Search: Live photos and videos are not shown properly when searching by filename #1395

New issue

Closed

opened 2026-02-20 00:11:54 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-20 00:11:54 -05:00

Owner

Originally created by @kvalev on GitHub (Apr 10, 2022).

Originally assigned to: @lastzero on GitHub.

What does not work as described in the documentation?

When searching for photos by filename filename: in case the result contains live photos or videos they are not shown as such. Meaning the icon in the top left corner is not shown and the live photo/video does not play.

How can we reproduce it?

Steps to reproduce the behavior:

This is easily reproducible on the demo instance. For example:
This is a live photo, but is not shown as such: https://demo.photoprism.app/browse?view=cards&order=newest&q=filename%3A%2aGopher.mp4.jpg&public=true&quality=3
This is a video, but it's rendered as if it is a photo: https://demo.photoprism.app/browse?view=cards&order=newest&q=filename%3A%2anot-a-cat-1.mp4.jpg&public=true&quality=3

However if you look for live photos (filter type:live) then the live photos are shown correctly.

What behavior do you expect?

That live photos and videos are always shown, independent on the used filter. so far I have verified this happens when using the filename: filter, but other search terms might affect it as well.

What could be the cause of your problem?

🤷

Can you provide us with example files for testing, error logs, or screenshots?

No need, reproducible on the demo instance.

Which software versions do you use?

N/A

On what kind of device is PhotoPrism installed?

N/A

Originally created by @kvalev on GitHub (Apr 10, 2022). Originally assigned to: @lastzero on GitHub. **What does not work as described in the documentation?** When searching for photos by filename `filename:` in case the result contains live photos or videos they are not shown as such. Meaning the icon in the top left corner is not shown and the live photo/video does not play. **How can we reproduce it?** Steps to reproduce the behavior: This is easily reproducible on the demo instance. For example: This is a live photo, but is not shown as such: https://demo.photoprism.app/browse?view=cards&order=newest&q=filename%3A%2aGopher.mp4.jpg&public=true&quality=3 This is a video, but it's rendered as if it is a photo: https://demo.photoprism.app/browse?view=cards&order=newest&q=filename%3A%2anot-a-cat-1.mp4.jpg&public=true&quality=3 However if you look for live photos (filter `type:live`) then the live photos are shown correctly. **What behavior do you expect?** That live photos and videos are always shown, independent on the used filter. so far I have verified this happens when using the `filename:` filter, but other search terms might affect it as well. **What could be the cause of your problem?** 🤷 **Can you provide us with example files for testing, error logs, or screenshots?** No need, reproducible on the demo instance. **Which software versions do you use?** N/A **On what kind of device is PhotoPrism installed?** N/A

deekerman

2026-02-20 00:11:54 -05:00

closed this issue
added the
released

docs 📚
labels

deekerman commented

2026-02-20 00:11:55 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 10, 2022):

It's correct this way. You've been searching for jpegs, these are jpegs. Jpegs don't play.

@lastzero commented on GitHub (Apr 10, 2022): It's correct this way. You've been searching for jpegs, these are jpegs. Jpegs don't play.

deekerman commented

2026-02-20 00:11:55 -05:00

Author

Owner

@kvalev commented on GitHub (Apr 11, 2022):

I really dont see how this can be an intended behavior. If I search for filename:*Gopher.mp4.* then I am not searching for jpegs and I still get jpegs. Even worse, if I explicitly search for live photos (based on the name) filename:.MP.` I get plain photos, although in reality they are live photos. This is very confusing and I dont think this should be the correct behavior (intended or not).

@kvalev commented on GitHub (Apr 11, 2022): I really dont see how this can be an intended behavior. If I search for `filename:*Gopher.mp4.*` then I am **not** searching for jpegs and I still get jpegs. Even worse, if I explicitly search for live photos (based on the name) `filename:`*.MP.*` I get plain photos, although in reality they are live photos. This is very confusing and I dont think this should be the correct behavior (intended or not).

deekerman commented

2026-02-20 00:11:55 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 11, 2022):

Why don't you search for live instead?

@lastzero commented on GitHub (Apr 11, 2022): Why don't you search for live instead?

deekerman commented

2026-02-20 00:11:56 -05:00

Author

Owner

@kvalev commented on GitHub (Apr 11, 2022):

Why? I am looking for some specific media based on their filename and not specifically for videos/live photos.

@kvalev commented on GitHub (Apr 11, 2022): Why? I am looking for some specific media based on their filename and not specifically for videos/live photos.

deekerman commented

2026-02-20 00:11:56 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 11, 2022):

It seems appropriate to explain this in more detail and make sure it is better covered in our docs and FAQs:

The current API and user interface provide a file search.
This is intentional, as a "stack" may contain files of different types and properties, such as color.

For example, there may be color and monochrome versions of images. Now, when you search for them or sort them by color, the user interface must display individual files. Otherwise, the results showing a color image when you filter by monochrome would not make sense. Try it out for yourself.

Finding a JPEG - without video - is 100% correct if you search for .mp4. as the video extension is not .mp4.jpg but .mp4 (without an extra dot at the end).

I suggest using the path: and/or name: filters with wildcard, since searching for individual files with certain extensions seems to be too specific for your use case (actually, you want to find all related files so you can view them together, e.g. as live photos consisting of a video and an image).

You can combine these filters with the live filter if you want to make sure that the results contain only live photos. This is what I suggested above:

https://demo.photoprism.app/browse?view=cards&order=name&q=path%3Ademo%2a%20name%3Agopher%20live

Alternatively, you can avoid filtering search results by a specific filename extension by using a more permissive wildcard with the filename: filter as shown in this example:

@lastzero commented on GitHub (Apr 11, 2022): It seems appropriate to explain this in more detail and make sure it is better covered in our docs and FAQs: - The current API and user interface provide a file search. - This is intentional, as a "stack" may contain files of different types and properties, such as color. For example, there may be color and monochrome versions of images. Now, when you search for them or sort them by color, the user interface must display individual files. Otherwise, the results showing a color image when you filter by [monochrome](https://demo.photoprism.app/browse?q=mono%3Atrue%20quality%3A3%20photo%3Atrue) would not make sense. Try it out for yourself. Finding a JPEG - without video - is 100% correct if you search for *.mp4.* as the video extension is not `.mp4.jpg` but `.mp4` (without an extra dot at the end). I suggest using the `path:` and/or `name:` filters with wildcard, since searching for individual files with certain extensions seems to be too specific for your use case (actually, you want to find all related files so you can view them together, e.g. as live photos consisting of a video and an image). You can combine these filters with the `live` filter if you want to make sure that the results contain only live photos. This is what I suggested above: https://demo.photoprism.app/browse?view=cards&order=name&q=path%3Ademo%2a%20name%3Agopher%20live Alternatively, you can avoid filtering search results by a specific filename extension by using a more permissive wildcard with the `filename:` filter as shown in this example: <img width="785" alt="Screenshot 2022-04-11 at 12 42 09" src="https://user-images.githubusercontent.com/301686/162724064-cf541abf-09d0-4060-a668-48b81b688fd6.png">

deekerman commented

2026-02-20 00:11:56 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 11, 2022):

Updated our User Guide FAQs:

github.com/photoprism/photoprism-docs@2d535f8bb2

@lastzero commented on GitHub (Apr 11, 2022): Updated our User Guide FAQs: https://github.com/photoprism/photoprism-docs/commit/2d535f8bb201ec25f0179164b55221f207eef3de

deekerman commented

2026-02-20 00:11:56 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 11, 2022):

Updated for better readability and also added to the search page in the User Guide. Hope this helps!

@lastzero commented on GitHub (Apr 11, 2022): Updated for better readability and also added to the search page in the User Guide. Hope this helps!

deekerman commented

2026-02-20 00:11:56 -05:00

Author

Owner

@kvalev commented on GitHub (Apr 11, 2022):

Thanks for the detailed explanation! I haven't yet fully digested it yet, but the alternative solutions filename: without extension and name: work quite well for me, so I am not complaining.

@kvalev commented on GitHub (Apr 11, 2022): Thanks for the detailed explanation! I haven't yet fully digested it yet, but the alternative solutions `filename:` without extension and `name:` work quite well for me, so I am not complaining.

deekerman referenced this issue

2026-02-20 00:19:54 -05:00

Metadata: Option to remove existing location estimates #1723