https://www.displayfusion.com/Discussions/RSS/?TopicID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a DisplayFusion RSS: WallpaperHistoryV4.db corruption/bad data Sun, 19 Apr 2026 12:05:34 GMT en hourly 1 https://www.displayfusion.com/Discussions/RSS/?TopicID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#18 Tue, 28 Aug 2018 20:18:24 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#18 DisplayFusion Sorry, no progress on this issue yet. It's going to take some significant time to troubleshoot and rewrite the file selection code. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#17 Thu, 23 Aug 2018 19:09:13 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#17 DisplayFusion Any progress on this problem in the 9.4 beta 1 release? ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#16 Thu, 12 Jul 2018 19:46:31 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#16 DisplayFusion It's true, we've seen some massive libraries. We'll keep plugging away. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#15 Thu, 12 Jul 2018 17:31:55 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#15 DisplayFusion 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 ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#14 Wed, 11 Jul 2018 16:19:35 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#14 DisplayFusion Thanks for the follow-up, 300k images is a huge collection for sure. It could be a timing issue where it just takes too long to look through them all, we'll have to look into that. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#13 Tue, 10 Jul 2018 22:02:53 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#13 DisplayFusion 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. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#12 Tue, 10 Jul 2018 19:12:24 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#12 DisplayFusion How many images do you have in your collection that you're using DisplayFusion to load randomly? Can you try with a smaller collection size just for testing, with maybe 20 images? That might be easier to keep track of to make sure they're all being used. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#11 Thu, 05 Jul 2018 20:41:41 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#11 DisplayFusion Keith,

I changed "Days to expire history images" to 99999 a long time ago. Info attached. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#10 Thu, 05 Jul 2018 18:02:03 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#10 DisplayFusion It resets every 7 days by default, unless you've changed it in the Advanced Settings.

Could you send me a copy of your troubleshooting info? Here are the steps:

• Open the Settings > Troubleshooting tab
• Click the "Export Info to File" button
  
• Reply with the file attached

]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#9 Mon, 25 Jun 2018 22:32:59 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#9 DisplayFusion 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." ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#8 Mon, 25 Jun 2018 20:57:48 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#8 DisplayFusion Hello, for the issue of the copied file being removed, DisplayFusion was probably just cleaning up rogue .DB files, it likes to try and keep things clean so it will remove unexpected files.

As for the issue with corrupted data, the data in all 6 tables here looks fine. There are no null values for the date stamps, it looks pretty normal. What database tool are you using to read the file? I would recommend Navicat for Sqlite and see if you get the same results when looking at the file contents.

The image filename's aren't being truncated or anything, they're just being stored as base64 encoded strings to save space in the database.

I'm not sure what do look at next, there doesn't seem to be an issue with the .DB file itself here. I'll pass some notes along to Keith for further testing and we'll see what we can do. Thanks! ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#7 Fri, 22 Jun 2018 17:37:53 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#7 DisplayFusion Thanks! I'll pass this over to the devs and see what they can find out. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#6 Thu, 21 Jun 2018 20:06:23 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#6 DisplayFusion 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? ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#5 Thu, 21 Jun 2018 18:23:54 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#5 DisplayFusion Nothing's changed regarding the wallpaper history in 9.x, no. The history database gets reset when DisplayFusion sees that all of the files in the folder have an entry in the database.

The next time you run into the dates getting corrupted, could you send me a copy of your wallpaper history DB file? ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#4 Mon, 18 Jun 2018 20:51:55 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#4 DisplayFusion 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? ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#3 Mon, 18 Jun 2018 13:11:23 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#3 DisplayFusion I wasn't able to reproduce this here upon upgrading versions, unfortunately. I will put a ticket in with our devs to do a code review of the wallpaper history to see if they can spot anything that might be causing this to happen. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#2 Sun, 10 Jun 2018 01:20:19 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a#2 DisplayFusion Sounds like it! I'll do some testing here next week to see what I can find out. ]]> https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a Thu, 07 Jun 2018 18:45:39 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/wallpaperhistoryv4db-corruptionbad-data/?ID=47ad4ed7-3fb6-49f8-9d25-0be3aa8f778a DisplayFusion 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? ]]>