I've beat on this drum before, as have others, but the problem always seems to get pushed off or denied with claims that it's fixed when it's really not.

The problem is with the wallpaper random photo selection. Photos in my directories either show up more often than they should, while others never are shown at all.

I have DF v8.1.2 running on a computer (Win7 x64) that displays wallpaper images, one per minute. That's 1,440 images per 24-hours. The images are pulled from a network drive. A week ago the SSD in this box died, so I restored it on another SSD using an old image backup. Over the past year or so the number of images on the network drive increased from about 12,000 to about 16,000, so I increased "Days to Expire History Images" from 7 days to 10 days so it was just under the number of images available.

This time I decided to experiment and instead of using wallpaper decided to use the Photo Screen Saver to display images, with the refresh set to 6 or 10 hours or something. Yes, the images are pulled from the same networked drive.

Guess what? Over half the images I am seeing *now* I have never seen before!

This computer has been showing images for about a year so should have cycled through the image library dozens of times. Yet over half of what is showing are never-before-seen-"old"-images! What this means is that the current algorithm systematically excludes at least half the photo library so that the images are *never* displayed!

A few months ago I did delete the wallpaper image history file, thinking it might have become corrupt. Didn't make any difference. The only thing that seemed to trigger new images was when I added new pics to the network drive. It was as though an offset in an algorithm had changed so the selection of images displayed shifted.

Maybe the algorithm DF uses works fine with small directories. But other posters with large image libraries (>100,000) have complained about this before, as have I.

I don't know how difficult this problem will be to fix. But right now I know that DF is a huge resource drain (on the UI) about halfway through every wallpaper change interval. I presume that DF is enumerating directories and selecting files or something. This is wasteful and unnecessary. Like with the photo screen saver, the refresh interval should be user adjustable because the file list will not change very often for the way most people use personal photos as wallpaper. Selecting an image and comparing it the wallpaper history database to find a "new" image will be much much less CPU intensive than what DF is doing now.

For that matter, the Days to Expire History setting should not even be needed with a random image selection. DF should just work through the list until it is exhausted and then start over (stop timestamp comparison at the day level, or plus or minus X-days to see if the image should be shown again).

If you can't or won't fix this problem, so that ALL images are shown in something resembling a random order, I will have to start looking for another program that can. I do like DisplayFusion, but this problem is getting old and tiring and frustrating.

Thank you for listening.

Okay, thanks.

One thing to look at is the encoding you are using for the ImagePathHashMD5. Are you using the default? I have a lot of filenames with non-ASCII characters and I use a couple of programs that just ignore these files or cause hiccups. (For example, IrfanView won't permit drag-drop of these files but they can be opened directly with the File-Open command.) DF has no trouble using these non-ASCII files as wallpaper though.

The best way I've found to test this is to start with a clean history database, create a bunch of jpg files, then analyze the DB counting the number of distinct ImagePathHashMD5 values for each day.

On the machine I'm testing this on, somehow the DB got reset (not sure what I did), so I have only two complete days. The day totals look reasonable (assuming the hash is good), at least within the margin of error. I updated DF to v9.beta3 on this machine, deleted the DB, and restarted the test.

On my personal machine I run three 4k monitors off two video cards. The center monitor has no wallpaper and the outer two are split in half using monitor splits and show wallpaper in each half. Three of these have enough images to not have repeats for at least six months (at 1 change per minute). The fourth has only enough to last a week or two, yet only 80 percent of the images have been shown. To put numbers to these, the image history for the first three have 17,229 entries each, and the forth has 3,213. Each monitor draws from a separate directory and the fourth has about 4,000 images in its' directory structure.

I'll report back next week with the results from my test machine.

In my test during the past week I've been capturing multiple snapshots per day of the wallpaper history database and analyzing them. Based on my analysis, the program does appear to be working properly, so I will withdraw my complaint.

One thing I did figure out is that after the images are exhausted, the program resets the table (deletes all entries) and starts over. This could have led to confusion on my part if an image shown shortly after the table is reset was late-displayed in the "old" table. I'll make a separate feature request post to clarify this.