I recently updated to the v9.2.1 final release version. Lo and behold, I'm seeing a whole slew of new images that I have never seen before, I'm guessing between 5 percent and 10 percent. The image library hasn't changed in the past year and prior to this update I might see a new image once a week or so.

(I've seen this happen before, after a major update supposedly "new" images start appearing.)

Anyway, I looked at WallpaperHistoryV4.dB and I see a bunch of bad data in the ImageAddedDateTimeUTC field. Instead of a date and time I see "1899-12-30" over and over again. The value in the ImagePathHashMD5 field appears okay, so far as a casual examination can tell me.

Bug somewhere?

Okay. Thanks.

Also, I know I've bugged you about this before, but there is/was something off with the wallpaper history management. I'm STILL seeing lots of new images. Unfortunately the filename is hashed in the database so I can't see it. With the latest version (v9) did the devs change something? If sometimes the mixed case filename gets hashed that will be one entry, but an all caps or all lower case will be another, as will a trailing space, etc. Maybe it's working correctly now but wasn't in v8? I'm taking wild guesses here. Is library size an issue? This one is only ~20,000, but I have another that is 300,000 (a bit too many to remember.... Since the database just gets deleted/reset when DF thinks its shown all the images, what is the criteria for when this happens?

Copy of the database file attached. The corruption appears in all six tables. Due to size the file is RAR'd.

And I do have a strange little bug to tell you about. I copied the WallpaperHistoryV4.db file to WallpaperHistoryV4.asof21Jun2018.db. Opened WinRAR, selected it to RAR, then it disappeared!!

Strange.

This time I copied the WallpaperHistoryV4.db file to WallpaperHistoryV4asof21Jun2018.db (no dot). Opened WinRAR, selected it to RAR, then it disappeared too!!

It seems DF is truncating the database filename. Not sure what or if DF is updating though.

So I copied it again, this time giving the new name a different prefix. All went as expected.

So, is the wallpaper image filename getting truncated or RTrimmed to some length somewhere?

Jon,

I was using sqlite, albeit an old v3.1 x32 version. I looked at the file using sqlite v5.2 x64 and noticed something odd. For example, in the 201 table, record #2, the timestamp in v3 shows as "1899-12-30", but in v5 it shows as "2018-05-09 00:05:48.007Z". But in the hex and record editor they both look the same in both versions. So I'm guessing this must be an artifact of v3; strange one though.

In the same table, using v5, record 151 is 24 bytes, but record 152 is 28 bytes, at 01:25:32.908Z and 01:27:37.1712002Z respectively. These extra 4 bytes get appended to chunks of entries, then they return to 24 bytes, (2002 in this case, or 003, 4002, etc). The chunks/groups last for an hour to 15 hours or so. No obvious pattern, at least to my eyes. Is this just an artifact of sqlite? (Interestingly, in v3, both records display at 24 bytes, only in the hex editor are the extra 4 bytes seen.)

Sorry I seem to be grasping at straws here, but I know there is something wrong with the "random image" selection process, even though you keep telling me there isn't. I don't know whether it is in the DF code, or third-party code you use. Maybe my expectations are different from what you are coding for, e.g., I am expecting ~100 percent of the images to be used before the cycle starts over again, while DF says 50 percent is "good enough."

Keith,

I changed "Days to expire history images" to 99999 a long time ago. Info attached.

I have about 350,000 images presently.

Per your request I put 20 images into a new directory and changed one of the split-screen monitors to use this directory instead, changing on 1-minute intervals. I watched it for three cycles and noted the picture number (e.g., Stock.Photo.Waterfalls.01.jpg). I also kept open the wallpaper history database in sqlite and monitored it at the same time. I saved copies of the database as the testing went along.

After the first cycle of 20 images the database table reset, as expected, and no duplicates were shown.

After the second cycle of 19 images the database table reset, and no duplicates were shown.

What should have been the 20th entry in cycle #2 became the first entry in cycle #3. After 19 images the database table reset and no duplicates were shown.

And what should have been the 20th entry in cycle #3 became the first entry in cycle #4. I stopped monitoring before it finished.

I also checked a few of the filename hashes and they seemed be the same across testing cycles (as expected). These are simple filenames, and since DF supports multiple languages the character set of the filename should not be an issue (many of the wallpaper images I have use non-English characters).

But none of this should be a surprise to you as I am sure you perform just such a test in-house.

But what does DF do when it is confronted with a table with 300,000 entries? I know the filename hash is indexed but as you start reading through the enumerated directory file listing looking for a random image, it would be easy to hit 200,000 "faults" that already have an entry in the table. What does DF do? Is there a timer somewhere that expires and DF just grabs the last image it was checking? Or, if you have optimized the code between v8 and v9 so that this section is significantly faster, that might explain why I am seeing new images. Again, I know I'm grasping at straws.

Okay. Thanks.

I did a quick search through old forum posts and while 300k may be on the high end, there are certainly DF users with still larger image libraries. I vaguely recall a comment Keith made some years ago about DF supporting some of these (commercial?).

I'm sure you have lots of ideas about how to reduce the CPU load for wallpaper selection/management (and I'll happily chime in if you want more ideas

Any progress on this problem in the 9.4 beta 1 release?