Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Daydream]

Ok, this is a bit strange. Maybe I'm seeing things.

I've created a new database in MC14, starting from scratch and reindexing everything. Which would include some 50000+ images. Now MC started creating thumbnails and, while I can't say on what's working (feature request to replace the "building thumbnails" with more details), I'm guessing it's dealing with the pics since everything goes mighty fast. Even if not it doesn't really matter. After going for awhile, say anytime between 500 and 1000 thumbnails the whole system stalls. Not really frozen (can move mouse, move windows already opened), but can't do any new activity, open other programs, etc (task manager included).

This is Win7. So if I insist on clicking away inside MC, its whole window becomes white semi-opaque (you know the thing) and I'm offered to wait or kill the program. Well, that's not recommended, I know, but even if I try nothing will happen. Pretty much no new program can be run, no old program can be killed. After that I've started the resource manager on the side and waiting for the next time it happen. When it did, the "highest active time" for the disk (C:) shot to 100% and it stayed there. Usually it takes between 30 sec to 1 min to recover. BTW when it recovers everything keeps on going like nothing happened.

OK fine, this disk is about to die I'm telling myself. Run a test, run a second test, run a third test - nothing. Nevertheless I've reinstalled MC to another drive, with all its things (libraries, thumbnail folders, everything, they don't reside anymore in Program Files or in C:\Users\[insert craptastically long path here]; that was really *cough* easy BTW - subject for another discussion). Guess what, same thing happens with this drive too. Thumbnailing going OK for some time than stall, than another 1000 go OK, than stall, then... what the hell???

Then I go in an check the highlighted option in the screenshot below for the HDD in question (default is off like I'm showing).



And everything goes fine, no stalling anymore. Now. I expertly know what that option does. It's a... bug if you want, on short - the system functions better (faster) but less secure with the bug (option checked), and noticeably slower but secure with the bug fixed (option unchecked). Hence even the Windows devteam allowed for an option so the users can do whatever they want on their own risk.

But it never affected me before - although this "before" is unclear I can't pointed it in time. Before Win7 maybe. My question is - any recent changes in MC (threading, I don't know, the ways it writes to its database,etc) coupled with the "feature" I highlighted above, might lead to the described behavior? If that's not the case, then I have to wonder if MS modified the treatment for the flushing buffers thing between XP-Vista-Win7.

[JimH]

This is Win7. ... Then I go in an check the highlighted option in the screenshot below for the HDD in question (default is off like I'm showing).



And everything goes fine, no stalling anymore. Now. I expertly know what that option does. It's a... bug if you want, on short - the system functions better (faster) but less secure with the bug (option checked), and noticeably slower but secure with the bug fixed (option unchecked). Hence even the Windows devteam allowed for an option so the users can do whatever they want on their own risk.

But it never affected me before - although this "before" is unclear I can't pointed it in time. Before Win7 maybe. My question is - any recent changes in MC (threading, I don't know, the ways it writes to its database,etc) coupled with the "feature" I highlighted above, might lead to the described behavior? If that's not the case, then I have to wonder if MS modified the treatment for the flushing buffers thing between XP-Vista-Win7.

Interesting find.  Could be our problem but also could be a W7 bug.

Thanks for all the details.

[Dirhael]

You probably know this already, but you should never ever enable that setting if you value your data at all, or the integrity of your OS installation. It may not break today, tomorrow or even a week from now but unless your system is 100% stable and never, not even once, crashes it will eventually happen.

Don't know if you remember recent discussions regarding the ext4 file system, and data loss, on Linux? Well, this is essentially the exact same thing.

A couple of articles on the subject:
http://technet.microsoft.com/en-us/magazine/2007.04.windowsconfidential.aspx *
http://www.h-online.com/open/Possible-data-loss-in-Ext4--/news/112821

* "Enable Advanced Performance" and "Turn off Windows write-cache buffer..." is the same thing, only labeled differently.


Just a warning in case anyone feels the need to enable that setting after reading the OP

[MrHaugen]

From the Technet article:

It turned out that these programs constantly issued flush calls. The programmers noticed that flush calls were really fast on Windows 3.11, so they sprinkled them liberally throughout their program. Write a byte, flush. Write a string, flush. Since the flushes were so fast, the app could commit the data to disk after every operation with no noticeable performance degradation. But once Windows 95 fixed the bug, these programs started to run very slowly since the Commit calls were suddenly doing actual work.

It turned out that history repeated itself. In Windows ServerŪ 2003, the I/O folks found a bug where requests tagged as Forced Unit Access (FUA) would lose the FUA tag and be performed as normal I/O. It was the modern-day version of ignoring flush requests! They fixed the bug but left an option to return to the old buggy behavior. The Windows Server 2003 version of this checkbox is called "Enable Advanced Performance," but now you know it really just means "Restore old buggy behavior."

Could this be the problem? I have no idea really, but it does sound strangely familiar in this situation.

[Matt]

This is a weird one, especially since it's not happening to everyone.  I've been using Win7 for quite a while, and have had pretty good luck.

To MrHaugen's idea, JRiver does not use the API function FlushFileBuffers(...).  We experimented with it in the database because it seems like a safe thing to use, but it crippled performance and we switched to a different method of safe file replacement.

I wonder if a virus checker, first-generation SSD, or drive in PIO mode might be involved in this problem?

[Daydream]

MrHaugen quoted the right context of this issue (maybe I should have added that in my first post). Anyways, some more thoughts from my end.

I've never been faced with this issue since my library has been ported over / copied / etc., anytime I did some significant change/reinstall. However reindexing everything from scratch is a lot more work than, say, adding a season to a series.
There is no virus checker, and no SSD - the HDD where the library is stored it's a classic SATA drive; same as all the other drives. Of course there are particular components in every system and mine has them too (SATA port multipliers, etc). The only thing that comes to mind that is a bit different is that I have the SATA drives/controller set as AHCI in Bios, not IDE. However it's been like that for a very long while (I went from XP to Vista to Win7 with the same settings, same hardware).

I agree it's pretty strange. MC has been rock solid in this department since... forever. It may be a number of circumstances not just one that triggers this. I'll keep investigating, maybe I can find a better tool to report what's going on.