Problems with tearing and continously auto-refreshes in tiles mode after updating to 12.2.5

This worked perfectly fine in 12.2.4.

It's a bit hard to describe so I made a video for you guys. Because the video contains some project sensitive information, I just posted the url to Leo and Jon.

Thanks.

Thanks for the video! Definitely easier to see than describe.

Can you tell us your Tiles definitions for the PNG type? (The one that's making the ">32bit>>" strings appear, and also the status label icons.) It seems like that is probably part of what's happening.

Is anything modifying the files as the folder is being read, which might be causing them to be re-scanned? It looks like they are getting their extra metadata populated, but then sometimes it is being thrown away and re-calculated, for some reason.

Hi Leo,

Thanks for your reply. I don't think my view defintions are the reason for this, because I haven't changed them for months and they never caused any issues so far. Plus, it doesn't happen only on PNG files, it does happen in all views, regardless of the filetypes. (Although it's best to see in image dirs, because they are huge)

Anyway, here are the settings you've asked for:


My guess is, that is has something to do with the pre caching, related to this setting:


The feature is really awesome. Because I have the cache disabled, after starting dopus, all directories of open tabs are scanned which probably takes 1-2 minutes before everything is parsed and read. And that is exactly the time where these issues are visible. (On a off topic side note it would be nice if this option could be set for each folder format individually like the "get folder sizes" option.)

You can also see that parsing is active on the update-icon in bread crumb bar. I'm using this setting since I use dopus and in 12.2.4 there was no such effect visible even with this setting. From my point of view, the issues are definitely related to that icon though. I may be wrong but I think something has changed here, because in 12.2.4 this icon was visible only at the beginning when the folder was parsed and of course when files have changed. Now it seems, there is some kind of update, each time you change back into a tab.

Hope that helps.

Sorry, I messed up the screenshots, the last screenshot should replace the first one.

Thanks.

A small update on this, cause I got a new finding: If I clear the custom information, edited in file type editor:

{size}
{modified} {status}

{picdepth}>{keywords}>{label}

all the strange effects vanishes. Which proves your Theory was right Leo and mine was wrong.

Downgraded now to 12.2.4 because these displays are essential to me.

Thanks.

One more update:

It's the {picdepth} field that causes the issue. If I remove it, everything is smooth. Adding this field alone is sufficient to reproduce the issue.

Oh and one more thing, it also happens in 12.2.4 and even in 12.2, although the refreshes seems less frequently here.

Could you let me know if/when you can reproduce this?

Thanks.

Still happens in 12.2.6, a fix would be much appreciated. Can you guys reproduce this issue or do you need more info?

Can you post a screenshot of your Preferences / File Display Modes / Tiles settings?

Sure, you're welcome:


Just to keep you up to date, this still happens in 12.3.

Thanks.

If you set Preferences / Miscellaneous / Advanced: no_external_change_notify = True and click OK (then tell Opus to restart when prompted), does this still happen?

If that doesn't make a difference, what happens if you disable (clear the checkboxes of) everything under Preferences / Favorites and Recent / Label Assignments, then restart the program?

So far neither Jon nor myself have been able to reproduce what you're seeing, and I've been trying again today without luck, but I have a couple of ideas which each of those tests should check, to see if they're worth investigating in more detail.

Hi Leo,

Many thanks for getting back to me on this.

That's really hard to say. At first I thought it was definitely better, when settings this to true. But this might have been a coincidence. It's different each time. Sometimes there's a massive tearing effect and sometimes it's only at times. I tried it now 3 times in a row with the flag enabled and disabled. I would say it's slightly better when this is set true but this could also be completely coincidence.

This doesn't seem to have any effect. The parsing is faster, because files doesn't need to be checked for their bit depth, so the period where Dopus is reading all the stuff is shorter in general. As a result, the tearing ends earlier, but I think that's just because the parsing will be finished earlier.

Yeah, I already guessed that this is not an easy one to reproduce.

What might help is, if you create a similar setup I have:

  • Auto-Start dopus with a configuration with several tabs opened.
  • Some of the tabs should contain large picture libraries. (Several thousand files in different formats)
  • Start dopus and activate the tab, while the folders content is still read.

All other settings I've tried so far doesn't seem to have an reproducable impact on this. The only setting that elimates the problem for sure is when I remove the >{picdepth} tag from the TilesMode setup in the file types configuration. When I remove this tag, everything looks perfectly. No tearing, no redraw, no double and triple updates. But that tag is so darn useful;)

Just let me know if you want my configuration or if I can support you with any other info on this.

Many thanks is advance,
Kind Regards,
Skeeve

Just to clarify, the bug we're looking for from the video is where a file keeps changing what it displays, as if the information is invalidated and recalculated endlessly.

It's normal for the information for a file to appear in stages and move around slightly as the information is calculated. (In particular, when the status icons are calculated, that causes the other information to move up slightly, even if no icons are visible in the end, as the icon height is larger than the font height.) That part is OK/normal, but the information should eventually settle down and remain static once all the different parts are calculated.

Calculating bit depth is usually very fast, so if the filter labels are taking a long time to calculate but only based on that, it's potentially interesting. It looks like there are more filter labels involved, though, e.g. one which says files were changed today can be seen in the video.

These are the label filters I'm using:


I've send you my config via mail, so you can check all the attached conditions for further investigations.

I think we're talking about the difference between using the {picdepth} tag or not? Otherwise I would be confused:) When I use this tag, I get all the strange effects you can see in the video. If not, these effects are not there. Normal file updating is so fast and hardly visible, I wouldn't mention it at all.

If you're interested I can make a video without using the {picdepth} tag, but then you will see ... well basically nothing:) There is a very small 'flickering' when items are updated, but this is a one time event and as you've said that's probably the normal file refresh and I wouldn't complain because of that. But it's really a difference like like day and night.

The refreshing doesn't last endlessly, it's while all directories are read and thumbnails are created. (I have the thumbnail cache disabled, so thumbnails are generated each time I start Opus) This usually takes 2-3 minutes after dopus was started on my machine, because several thousand files have to be parsed and the tearing happens during that phase. After that point, it also happens when something was changed in a directory or when I scroll through large directories.

I've double checked both modes again and discovered some more fine differences, that might be relevant or not, but I want to mention them though:

  • When I quit and restart dopus and wait until everything was read and cached (the mentioned 2-3 minutes, when there is no more update indicator visible in the breadcrumb bar): When I now activate a preloaded tab for the first time, in "non {picdepth} mode" everything is rock solid and stable, you can see no updates and no tearing. When I activate a preloaded tab for the first time in "{picdepth} mode", there is often some kind of initial refresh operation running. This implies the same effects you can see in the video, although they stop usually after 2-3 seconds.

  • When scrolling through directories in "{picdepth} mode", the same tearing effects happen, although they usually stop after a few seconds. This also doesn't occur in "non {picdepth} mode".

  • In "{picdepth} mode" sometimes tabs that doesn't even contain thumbnail-files (excel files, or stuff like that) are refreshed again over and over during the preload phase, although there contents have already been updated.

  • I've also checked the time dopus needs to parse the data with and without using the >{picdepth} tag. It's more or less the same time, so this was a false alert, please ignore this.

This is really not easy to describe, because the effects vary each time. Sometimes it's really annoying, sometimes it's only a little bit ugly:) But I've double checked that this is definitely a huge difference to the normale file update you've mentioned.

I hope that helps. Let me know if you have more questions or if you need anything else.

Thanks,
Kind regards,
Skeeve

Hi guys,

I made two new videos regarding this issue.

Both videos have been created after Dopus was freshly started and left idle for 3 minutes, so all data could be parsed.

Although I'm not exactly doing the same stuff, you should clearly see the difference.

Especially when initially activating a pre loaded tab, in the Disabled version you see no refreshes at all, while the Enabled version is full of refreshes and updates, although the frequency differs.

I've send you the video links via mail.

Hope this helps. Thanks for your investigations.

Kind regards,
Skeeve

Hi Leo,

I've spent now countless days to improve the situation, but unfortunately couldn't ressolve this by myself. What I've tried so far:

  • Disabling windows defender
  • Uninstalling the corel thumbnail preview
  • Uninstalling other tools where I assumed a connection
  • Disabling windows file indexing
  • Disabling security and virus software, even switching to different virus software
  • Updating drivers
  • Playing around with dozens of windows option I thought they could be relevant in any way
  • Playing around with hundreds of Dopus option I thought they could be relevant

None of that ressolved the issue, but at least by now I have some additional insights:

The tearing just comes from the fact, that when no bit depth is available, Dopus skips the entire line in the tile. This way, the tile display switches between 3 and 4 lines very often which seems a bit like tearing. In fact it isn't and you probably already noted this:)

To reduce the busy redraw behaviour, I adjusted the tile display, so that 4 lines are always displayed, regardless if bitdepth is available or not. This change has improved the situation and I could face the core of the problem: That bitdepth is set and cleared multiple times within a single refresh operation. Sometimes up to 3-5 times. I don't think this is intended behaviour?

After recognizing that, I tried your suggestions again and this time it became clear that setting no_external_change_notify to TRUE ressolves the issue of multiple updates within one refresh operation. I didn't realize that at first, because it still was updated once and due to my previous setting this still created an effect similar to tearing as descrived above.

So, setting no_external_change_notify to TRUE ressolves the issue with multiple updates, yes. But it has a huge downside, I don't get any other automatic file updates any more:/

Is there anything I can do to ressolve this without loosing auto update for all my files?

Many thanks in advance,

Kind regards,
Skeeve

If no_external_change_notify stops it from happening then it's likely a property handler or thumbnail extractor are modifying the files (or at least their timestamps, or opening them for writing and then closing them) when asked to extract information from them. That's bad, since it means reading the files causes them to appear to have changed, which causes things to re-read them, and you get an endless cycle.

ShellExView can tell you all the shell extensions which are installed, which will include the property handlers and thumbnail extractors. Disabling any that look related to the file formats in question may be worth a try, to see if a particular component is causing the problem. If it is, it should be easy for the authors to fix, and they probably just don't know their code is doing it at the moment. (Although they'll need to be willing as well. One of Microsoft's own shell extensions for emails has this exact same problem and people have been complaining to them about it for years with no fix.)

Hi Leo,

Many thanks for your help.

As adviced, I started disabling all icon and image relating app and system stuff with the ShellExView tool. I was trying to do this one by one and testing at the same time, but ended up by disabling everything, including all MS windows and shell32.dll extensions, although the tool showed some warnings and didn't recommend this.

It was definitely disabled, the right click context menu was almost empty, beside some standard Dopus entries.

However, it didn't help at all. Even with all shell extensions disabled, this still happens. Do you have any other idea?

Are you sure this isn't a dopus issue? Could you reproduce the issue by using the config I've send you via mail?

Thanks,
Kind regards,
Skeeve

I still can't reproduce it so far.

You could use Process Monitor to see if the files are being modified, which would confirm that theory (it's always possible it's something else). If they are being modified, the Process Monitor log will record a stack dump which we should be able to see to see which process and DLL is causing it.

Hi Leo,

Many thanks again for your help.

As adviced I used the ProcessMonitor to track down the issue even further. Whoa, that's a lot of info this tool is generating :slight_smile:

I already filtered by file activity and only the time range when the refresh was active, but it's a million events for just a few seconds though.

From what I see it's mainly dopus that is writing in the files or tries to create (overwrite?) the files that are parsed. But I guess it makes more sense if you take a look at that log.

Should I send this in native ProcessMonitor format? Via forum or email?

Thanks,
Kind regards,
Skeeve