Thoughts on PictureFrame2020 refactor and possible SQLite-based cache

[jgodfrey]

I've had a few discussions recently with @paddywwoof regarding an upcoming refactor of the PictureFrame2020 code base and the possible introduction of a SQLite-based caching / storage mechanism. I've been giving this some thought recently and wanted to record some of that here.

In my (admittedly limited) experience with PictureFrame2020, one of the biggest misses I see is the lack of any persistent storage of image information. Because nothing is stored, it needs to be recollected each time the software is started. Since the data collection is (potentially) slow, the code is complicated by the fact that it needs to sometimes contend with missing information.

For example, there's an option to pre-load or not all EXIF information (--delay-exif) due to the time it takes to load that information at startup. Then, other parts of the code are required to do different things depending on whether the EXIF info has been preloaded. The recent "portrait pairs" feature I introduced was complicated by this option.

In my view, a persistent image cache would help to normalize some of these issues, as the code could just expect the info to exist at the time of image presentation and not need varying code paths to deal with missing info.

In that regard, I see SQLite as a perfect mechanism to support such a cache. It's light-weight, incredibly fast, and requires no installation. And, once it's in place, it's just so useful as the underpinnings of future features and enhancements.

For a first, simple use, I see it working something like this:

• On first startup, a complete cache would be built, containing everything necessary for the application to function as a slideshow. That'd include things like image id, image name, orientation, date, location, and aspect ratio (for the pairing feature). While this could take some time on first-run, the beauty is that it'd only have to happen once. From that point on, it'd just have to be maintained based on delta changes - which should be much lighter weight.
• With the info available in the db right from the beginning, it'd be trivial to generate a structure to drive the slideshow (either as a SQLite table/view or as a Python data structure). I'll call that structure the "slideshow script" (script as in Hollywood, not as in code).
• Simplistically , the script could just be a list of the image db id's, in the order of presentation. This should make MQTT navigation simple (get the next id, SELECT its info from the db, build the slide)
• For the new "image pairing" feature, the script could contain both the image id and the paired image id (so, two fields like id and paired_id). Here, the image that appears as paired_id would simply be removed from the original script so it only appears once.

To better explain that, let's say we have 10 images in our slideshow - and we're simply going to show them "in order". The script would be a list of id's such as (horizontal for brevity):

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

Now, during the "script preparation" phase, we'd make a pass through the collection and attempt to "pair images together" as necessary (to display portrait images in pairs, for example). That could create a script that looks like this:

id=1, paired_id=3
id=2, paired_id=null
id=4, paired_id=7
id=5, paired_id=null
id=6, paired_id=null
id=8, paired_id=9
id=10, paired_id=null

After this pairing pass, the script only contains instructions for 7 slides (3 of which are now pairs).

• With the script prepared, the slide show could just iterate through it as necessary, building/displaying slides singly or in pairs as described in the script. Additionally, the same images would be guaranteed to be paired again during ad hoc MQTT navigation of the same script (which is a problem in the current implementation).

So, to recap...

• On startup, build the initial image cache containing everything required for the slideshow in the db. Yeah, this might take some time, but it should only be on initial startup, or when the the images in the folders have been completely changed. We could even display a "Building Cache..." image on the frame during this time.
• On each successive restart (or image refresh), just "maintain" the stored info. That involve adding new images (and their information) to the db and removing now-missing images. I'd expect this to be a relatively quick step as it'd only be delta changes to files on disk.
• Build a slideshow script to drive the next show, including any image pairs necessary.
• Run through the script to display the show
• At the end, based on user-configuration, update the image cache, rebuild the script in a different (shuffled) order, and show it again.

Here, all the magic (whatever we deem that to be) happens in the script preparation. The slideshow just faithfully follows a pre-prepared script...

Granted, this is an intentionally simplistic view of the current system, but I hope to spark some discussion.

[jgodfrey]

Additionally, this makes the issue of displaying the correct text overlay on paired images (problematic in the current implementation) easy to handle. The script contains the id's of the images that are on the slide. Just collect the info from the db for the displayed image(s) and build the overlay info...

[paddywwoof]

Jeff, this system makes a lot of sense. I've managed to get helgeerbe's picture frame running on my laptop so I will check out how that system works then maybe add some more specific ideas.

I think getting a savable list (probably as sqlite db) makes a lot of sense rather than constructing it from scratch each time the program runs, especially as we are already doing that for the geo location description. We would need to address questions like: how to copy with files being deleted, moved or directories being renamed as well as pairs where one image fell within a selection criterion and the other one outside. Though none of those are too tricky to solve.

Splitting the code to build the textblock into its own function (as well as other parts of the main display loop) would make the handling of a lot of the problematic areas, such as displaying two images at once, much simpler.

Another thing that has cropped up that might (or might not!) be worth thinking about at this stage is enabling animated (probably only GIF, not 'live photos' as taken on phones which are basically just 1.5s mp4 videos)

[jgodfrey]

We would need to address questions like: how to copy with files being deleted, moved or directories being renamed as well as pairs where one image fell within a selection criterion and the other one outside.

My initial thoughts on some of the above...

For deleted files... If the deletion were via the app (so MQTT), that seems easy enough to handle gracefully. If it were deleted "outside" the app, it could be as easy as just skipping images that are 1) in the current script and 2) missing from disk. That'd all shake out in the wash the next time the cache was updated as the missing files would be removed and would no longer appear in future scripts.

I guess moved files or renamed directories could be handled the same way. If files are in the current script, but are found to be missing, they'd just be skipped by the current slideshow and cleaned up when the cache is refreshed.

For pairs that fall inside/outside a selection range (date, for instance)... In that case, I'd expect that a change in date range (via MQTT) would require the slide-show "script" to be recreated using the current set of images. That pass would naturally rebuild the pairs from the current set of images, so I don't see an issue here.

[paddywwoof]

Jeff, some more thought on helgeerb's hit helgeerbe/picframe#5

[jgodfrey]

Interesting read, thanks...

While I absolutely agree that the existing code is in desperate need of a refactor, my initial impression of the diagram in the mentioned thread is that it feels over-architected for such a simple application. To me, the refactoring sweet-spot is somewhere between the current state and that diagram. Really, I'd be perfectly happy with the existing script being reorganized and refactored as necessary - but still being just a single, simple script file. I think too much architecture for something that's relatively simple (in the grand scheme of software systems) just serves to confuse rather than to clarify.

However, I'm perfectly willing to accept that I may be alone in that view.

Regarding the usage of SQLite... For this use-case, I just see it as a highly-functional caching mechanism. A way to organize, store, and easily retrieve a set of image records, sliced and filtered as necessary. Additionally, I see its contents as persistent, but disposable. That is, the db file could be removed and, other than the time required to rebuild it, nothing would be lost.

With that view of the cache, I don't see the inability of a user to easily edit the stored data as a drawback. In fact, it might be thought of as a plus. If a user can't edit it, they can't break it.

For purposes of this app, I see a set of useful (and maybe ever-growing) queries to return data based on appropriate subsets (all, by date range, by folder, by location, by orientation, by color tone(?), by ??). That's what SQLite is great at.

I don't see it being very useful for actually driving the slide show. For that, I keep going back to the "script" idea I proposed above - which really just needs to somehow indicate an ordered (and possibly paired) set of images (retrieved via a db query) to present to the viewer. I'd think that'd be a simple Python data structure containing image ID's (and possibly paired ID's as mentioned above) which could be used to retrieve the info necessary to build the next slide for display.

That way, you'd use SQLite solely for its excellent storage and retrieval abilities, but drive the show from an easier-to-navigate Python structure.

Certainly one could make an argument for NOT using SQLite at all and instead storing the same cache info in some other format (CSV, JSON, XML, ...), but then you'd have to write code to manage the cache and build custom functions for each and every interesting selection. Certainly, none of that's very hard, but it's extra work and I think you'd end up with more code and a less-flexible system than the one you already get for free with SQLite.

Anyway, just some rambling thoughts. As I really have almost no skin in the game, I'm happy to let those who do make the big decisions.. ;^)

[jgodfrey]

In case there's any interest, I knocked up a first pass at storing basic image info in a SQLite db. The source can be found here.

To test it, tweak the defined picture_dir near the top if necessary (intended to be the same root that drives PictureFrame2020.py) and then just run it like python3 imageData2SQLite.py.

That should load the data for all files found in the defined folder structure into a SQLite db (pictureframe.db3 for now). Each additional run should only update (add, modify, delete) any changes found on disk since the last run. In my case, it takes about 3-4 seconds to build the initial db from scratch, for about 500 images (RPi4). Related, while it is loading EXIF data ATM, it is NOT loading location data.

Further runs (with no changes to the file system) are nearly instantaneous.

Currently, the code is very methodical, and does things in a step-by-step fashion. While I'm sure there are more clever ways to approach this, the current method is easy to follow and seems quite performant.

Anyway, it's really just an experiment and not production code by any stretch. But, I think it should give some idea of what might be possible here, and provide some metric on the performance of such a cache system...

[paddywwoof]

Jeff, that looks really good, thanks - I will have a more thorough look later but having the path split out and in anther table is sensible. I've now brought the version at github.com/helgeerbe/picture_frame nearly up to the same functionality as PictureFrame. I've used a very simple txt file storage which would be easy to swap over to sqlite as per your code or something similar.

The two issues we probably have to think about (neither insoluble but probably possible to do well v. badly) a) the location descriptions from nominatim/OSM need to be obtained at an absolute maximum rate of 1 request per second, so this would either need to be filled in as each image is shown or else as a paced background job. The info isn't needed for any selection etc so could be done when the images show. b) getting the show to run from a db SELECT would be nice but I can't see how to do that and allow the cursor to move back so we probably have to run the show from a python list of index values to db tables and read each record as it's shown. It's still much better than doing the current way of getting the full os file list then filtering at each next_image.

Thanks again.

Paddy

[jgodfrey]

Hi Paddy,

I haven't looked at all at the location code, but I understand the dilemma. As you said, either a background task or retrieved at display time could work. Either way, once retrieved, it should be shoved in the cache for further use (db, txt, ...) Though, I guess you're already doing that today. If retrieved at display time, we might need to be careful that the API doesn't get spammed too quickly if someone is navigating over a bunch of images via MQTT...

Regarding driving the show. I agree that it'd be easier to drive from a Python list. Minimally, I think you'd retrieve a list of "id's" (the PK for the file table), from the db, filtered and ordered however is necessary. Then, maybe make a pairing pass on that list, and then just run with it. For each image, we could just select its record (based on the "id" we have) from the db, which should already contain the most interesting data (obviously, we could add more as necessary). Really, it could be as simple as get_image_info(id) or some such, which could return one of your new Pic objects (or similar).

[jgodfrey]

@paddywwoof - A quick update on my SQLite caching experiments...

First, I've broken the data storage down into a more normalized set of tables and a single view. ATM, those look like this...

Table: folder
Fields: folder_id, name, last_modified

Table: file
Fields: file_id, folder_id, basename, extension, last_modified

Table: meta
Fields: file_id, orientation, exif_datetime, location, width, height

View: all_data
Fields: file (a fully qualified file name), last_modified, exif_datetime, orientation, width, height, is_portrait, location

So, the tables each contain minimal, raw data about each "thing" and the single view pulls all that data together into one place for easy access. With this setup, the view can easily be augmented with additional columns that are deemed helpful. For example, the above is_portrait column is simply the result of meta.height > meta.width as is_portrait.

Related, I've read through the discussions associated with this recent PR (really interesting stuff BTW). I don't envy you (@paddywwoof) having to deal with all the recent submissions to the code-base as well as your own, on-going rewrite. That's a tough balancing act...

Anyway, related to some of those discussions, I wanted to pass along some additional performance metrics of my current SQLite cache.

Data: 6325 images in 58 folders / subfolders

- Initial cache build from scratch: 1 minute, 7 seconds (collecting EXIF data, but _not_ collecting location data)
- Scan for any new changes and update (with no changes): Less than 1 second
- Add 1 file deep in the folder structure and rescan: 3 seconds
- Remove the newly added file and rescan: 3 seconds
- Add new subfolder containing 145 new items and rescan: 5 seconds
- Remove newly added subfolder with 145 items and rescan: 1 second

Also, I'm confident that some additional speed can be squeezed out of the cache-build process. I'm currently experimenting with that.

Anyway, I feel the above is likely performant enough that complicating the application with threaded updates, or a build-as-you-go cache, or other complex mechanisms might not be worth the trouble, though YMMV...

I'm curious what others think?

I'll try to post my code updates soon in case they're interesting to someone.

[helgeerbe]

Jeff you are right. But separating mqtt from the controller is just the first step. Next, I want to implement the keyboard interface. But later on, I could think of a web interface, to do the general configuration. Changes will appear appear live, without restarting.

[jgodfrey]

Your two lists idea could be done by keeping track of the position in the second list.

Here's another variation that's short and sweet (though, not sure on performance)...

inlist = [(1,), (2,), ('<pair>',), (4,), (5,), ('<pair>',), ('<pair>',), (8,)]
prlist = [(3,), (6,), (7,)]
newlist = []
for i in range(len(inlist)):
  if inlist[i] != ('<pair>',):
    newlist.append(inlist[i])
  else:
    if len(prlist):
        elem = prlist.pop(0)
        if len(prlist):
            elem += prlist.pop(0)
        newlist.append(elem)

Could be improved by tracking the number of elements in prlist instead of checking it each time, but you get the idea... And, could probably save a few cycles by having the query return an INT rather than a string for post-processing. So, maybe -1 instead of <pair>...

[paddywwoof]

Jeff, not only is that more elegant but it's actually faster. For a list of 10,000 images of which 1,000 are portrait, running on an RPi3 it takes 16ms and the other two 18ms. So speed is academic really and we should just choose your design as it looks nicer - like Harold Ableson said: programs are essentially for people to read not computers to run.

Though there is cost of calling each function in python the len() is pretty cheap as the list has it's length as an integer ready to be read. The only thing I might change is to if len(prlist) > 0: using different types that happen to evaluate to True or False reminds me too much of the bad old days of completely opaque C and javascript!!

[paddywwoof]

PS tomorrow I will have a go at putting all the sqlite code into the refactored repository. I don't think it will be too hard really.
Famous last words!

[jgodfrey]

Jeff, not only is that more elegant but it's actually faster. For a list of 10,000 images of which 1,000 are portrait, running on an RPi3 it takes 16ms and the other two 18ms.

Nice!

So speed is academic really and we should just choose your design as it looks nicer - like Harold Ableson said: programs are essentially for people to read not computers to run.

100% agree. Readability is paramount, as long as its fast enough.

The only thing I might change is to if len(prlist) > 0: using different types that happen to evaluate to True or False reminds me too much of the bad old days of completely opaque C and javascript!!

The shorter syntax doesn't actually bother me here, but I also have no issue with being more explicit. ;^)

PS tomorrow I will have a go at putting all the sqlite code into the refactored repository. I don't think it will be too hard really.
Famous last words!

That's great. Best of luck. Keep us posted.

[rec]

On Mon, Feb 1, 2021 at 11:49 PM paddywwoof ***@***.***> wrote: Jeff, not only is that more elegant but it's actually faster. For a list of 10,000 images of which 1,000 are portrait, running on an RPi3 it takes 16ms and the other two 18ms. So speed is academic really and we should just choose your design as it looks nicer - like Harold Ableson said: programs are essentially for people to read not computers to run. Though there is cost of calling each function in python the len() is pretty cheap as the list has it's length as an integer ready to be read. The only thing I might change is to if len(prlist) > 0: using different types that happen to evaluate to True or False reminds me too much of the bad old days of completely opaque C and javascript!!

Another quibble: neither is Pythonic! If one were Guido one would write it this way: if inlist[i] != ('<pair>',): newlist.append(inlist[i]) elif prlist: elem = prlist.pop(0) if prlist: elem += prlist.pop(0) newlist.append(elem) where you just say if prlist - it's a little faster, but also, more idiomatic Python. Going back to lurk here. :-D

…

-- /t PGP Key: https://flowcrypt.com/pub/[email protected] *https://tom.ritchford.com <https://tom.ritchford.com>* *https://tom.swirly.com <https://tom.swirly.com>*

[paddywwoof]

Tom, You're right, and it uses less ink. In this case it's in a tight loop so micro seconds might matter, and it's obvious from the next line that if prlist implements pop() it's going to work. But I always think that "being pythonic" equates in some respects to being happy to accept major breaking changes such as python2->python3 so it's not always a good thing!

(Pythonistas might claim that using things like if len(x) > 0: is bad because it's distracting for an experienced python user reading the code. However, to me it indicates the writer prefers typescript to javascript, or rust to C!)

[paddywwoof]

First version of the system with ImageCache system. see comment on helgeerbe repo. And changes on mine

[jgodfrey]

@paddywwoof - I see you've merged my above-mentioned PR. Incidentally, I have another minor PR in the queue with a small bug-fix to the original changes.

Thinking about it now though... Assuming we like the basic approach I took here, I'm now asking myself what the "time limit" on each call to the update_cache() is gaining us? Since I'm building a full cache (except for location data) on a per-image basis (so some set of images should be nearly instantly available), I no longer see any advantage to the time limit. Originally, it was to ensure that the caching process didn't run too long at startup, requiring the image display process to wait for it to complete. But, I really don't think that applies any more, since each image is fully cached, one at a time.

So, I'm thinking about removing the time constraint - if for no other reason than to simplify the code slightly (though, really, not by much). With that change, it'd just run to completion with each call from the thread loop.

Do you have any particular thoughts here?

[paddywwoof]

Jeff, The only thing is being able to stop the caching process while image transitions are taking place. If someone has thousands of images (and why wouldn't you put all your pictures up there when a 64GB SD card only costs a few quid?) then it will take quite a while to do all the exif look-up (the SQL is probably less efficient doing it this way too, if that makes any difference). Maybe it's something that people will accept as a first time only problem... and simpler code is always better (everything else being equal)!

Anyway I've tried it a few times now with a clean start on a relatively small (few hundred) set of images and it seems to work great.

[jgodfrey]

Ah, yes - that makes sense. I've been concentrating on the SQL stuff in a vacuum and forgot that you do indeed pause/unpause the process from elsewhere. So, it probably does make sense to keep the time controls. Though, when you request a pause from the controller (due to an image transition), you might not get an actual pause until (worst case) the full duration of a single image_cache() call. For that reason, I guess we should keep the time limit for each call relatively short...

[paddywwoof]

It's been running nicely for a while now and the reaction to changing selections from controller is pretty instantaneous (w.r.t. which I did fix a bug in the date_from, date_to functions which I pushed up to the repo Yesterday).

As you say it's just the pausing during transition so we could probably simplify it and take out max_runtime_seconds completely if we change it to

        # While we have files to process and available time, process the next file
        while self.__modified_files and not self.__pause_looping:
            file = self.__modified_files.pop(0)
            ...

EDIT - I will do that now and if it works OK push the changes up to github

[jgodfrey]

Yes! I had exactly the same thought last night. Seems like we're on the same page here.

[helgeerbe]

OK, I did a little research on starting startx/xinit in systemd as non root requires:
apt-get install xserver-xorg-legacy
This allows you to run X as non console user.

Change /etc/X11/Xwrapper.config

allowed_users=anybody
needs_root_rights=yes

[Unit]
Description=Pi3D on Pi4
After=multi-user.target

[Service]
Type=idle

User=pi
WorkingDirectory=/home/pi/dev/picture_frame
ExecStart=xinit /usr/bin/python3 /home/pi/dev/picture_frame/picture_frame.py /home/pi/dev/picture_frame/config/configuration.yaml -- -s off -dpms -s noblank

#Restart=always

[Install]
WantedBy=multi-user.target

ps axu shows

pi        1121  0.0  0.0   3872   764 ?        Ss   15:43   0:00 /usr/bin/xinit /usr/bin/python3 /home/pi/dev/picture_frame/picture_frame.py /home/pi/dev/picture_frame/config/configuration.yaml -- -s off
root      1122  2.6  3.8 192948 34196 tty5     Ssl+ 15:43   0:00 /usr/lib/xorg/Xorg :0 -s off -dpms -s noblank
pi        1140 18.1  4.3  99692 38636 ?        Sl   15:43   0:04 /usr/bin/python3 /home/pi/dev/picture_frame/picture_frame.py /home/pi/dev/picture_frame/config/configuration.yaml

On my pi3 I will never get the images diplayed when starting with startx or xinit

[paddywwoof]

Helge, well done for finding that. I will try it on my RPi4

[helgeerbe]

Paddy, first I thought I corrupted my setup. I can't see any image when I start picframe from systemd. The process starts and ich can see the logging (Pi3D version 2.42. with Display size is w=1920, h=1080). Everything seems to be OK, but no image is displayed.
Starting it from the command-line and the images are there.
I tested it on my "real" picture frame. And I have the same behavior.
Actual I start it now as a systemd user service with ExecStart=xterm -e "user/bin/python3 ...."

I'm wandering if this happens only on my systems. Maybe it's time for a fresh installation.

[paddywwoof]

Helge, A couple of times when I've sudo reboot the picture frame via ssh no images have appeared so I've logged in again and checked with top - to see that python3 is running. Then when I turn around to look at the screen the slides have started showing! So I'm not sure it it's something I set up wrongly with systemd or something else trigger the clearing of something... or just a random thing. Presumably "user/bin..." is just a typo in your post.

I've always been doing

WorkingDirectory=/home/pi/picture_frame
ExecStart=/usr/bin/python3 -m picframe.picture_frame /home/pi/picture_frame/configuration.yaml

So I would have thought that was the first thing to test.

[helgeerbe]

Paddy, just found it. I tested it with Picframe2020. If keyboard is true, it's crashing. If I comment keboard out everything is back to normal. So that's why it works in xterm. Keboard is handled in this environment correctly.
So on systemd, never use the keyboard!!

[helgeerbe]

By the way, I learned a lot of systemd. I use now systemd user services.
They are located at ~/.config/systemd/user and you don't need to have root rights.
picframe.service

[Unit]
Description=Pi3D on Pi3

[Service]
ExecStart=/home/pi/dev/picture_frame/picture_frame /home/pi/dev/picture_frame/config/configuration.yaml

#Restart=always

[Install]
WantedBy=default.target

systemctl --user enable picframe.service

If you want to run it without autologin: loginctl enable-linger pi. So it's starting at boot time.

picture_frame is my small script, so you don't have to bother, with copying one level higher (and maybe forget some changes).

#!/usr/bin/python3
# -*- coding: utf-8 -*-
import re
import sys
from picframe.picture_frame import main
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

[helgeerbe]

Time for some eye candy. My actual Homeassistant integration.

What's missing is the location_filter.

@paddywwoof I pulled your development branch and merged it. So it should be easy to re-merge with my changes.

• Fix MQTT interface (switches and sensors)
• changed GPS image attribute to work with homeassistant
• Add PICFRAME LOCATION attribute to see geo reverse lookup
• try to fix brightness rounding error
• make loglevel and keyboard a config item
• add minimal keyboard interface (issue with pi3d.keyboard when started as systemd process. This is not handled in pi3d.)

[helgeerbe]

Just added one more fix for mqqt directory handling.
Found 2 more issues (marked in code with # TODO:

• when sending a non existing subdir, this is not handled correctly
• deleting the last image in directory throws a Zero Devision Error

[helgeerbe]

Wolfgang asked me, if I could change the date picker in homeassistant to allow exif dates before 1970. He has old scanned images and set the data to something like year 1929. I see that you set in this case the date in the database to creation date.
Datepicker in homeassistant also don't allow to go before 1970.

I have to think about it.

[paddywwoof]

I haven't checked but I think sqlite holds dates as unix style numbers where 0.0 is 1970/1/1 so 1929/2/15 is -1289952000.0 (seconds before then) I think the exif 'standard' specifies the date in YYYY:MM:DD HH:MM:SS format so that should be capable of tagging old photos.

For the SQL selection I exclude a constraint in the where clause if it's blank i.e. it should include photos from 1929 no problem, however I left the max and min values set for the __date_from and __date_to properties in controller as you had them before.

[helgeerbe]

Wolfgang send me the image. Exiftool can read it.

Date/Time Created               : 1957:07:01 22:27:25
Digital Creation Date/Time      : 2016:12:21 22:27:25
Date/Time Original              : 1957:07:01 22:27:25

But our python module exifread run into an error:

except IndexError:
                raise InvalidExif("Unexpected/unhandled segment type or file content.")

And does not return any exif tag.

I will prepare my own image. Don't know if something else is wrong with Wolfgang's image.

[helgeerbe]

OK, I created a file in lightroom. This is handled correctly by exifread. I think Wolfgang's image might be corrupted.

My image works fine. Except I can't use datepicker in homeassistant.

[helgeerbe]

Paddy, I added IPCT tags: titel, caption, tags (this requires IPTCInfo3 to be installed).
Titel and caption could be displayed in the textblock. I also implemented the tags_filter. Works pretty good.

In Homeassistant I show title, if not available the filename. But this is more logic for the picture_frame. I personally don't use the textblock on the screen. Just the pur image :)
For the tags_filter some And/or logic would be great.