Emulator

Whoa, that sounds quite interesting...
So not only has r7318 increased the loading times too much in some games/situations (in Pokémon Colosseum, but not as dramatic as in Spartan Total Warrior, given the even longer loading times posted in issue 4427), but on top of that you say that this causes a freeze in ZTP?

Assuming that DISC_ACCESS_TIME is no longer evaluated to a zero integer (hence the variably-increased loading times), the other constants may need to be readjusted to match the real hardware...

Probably should simply remove the DISC_ACCESS_TIME variable. The Wii disc speed was also a rough guess. That should probably be zero'd out too.

With regards to r7318, I think an easier way to avoid integer division is to try to divide 128.0 by 1000.0 rather than 128 by 1000. I don't know for sure, but it works that way in Java.

Issue 4410 has been merged into this issue.

rakok, would you please try enabling the "Speed up disc transfer" option in the game properties for this game and report back if it fixes the problem or not?

Thanks, skidau! Enabling of an option "Speed up disc transfer" has solved this problem. It has been checked up on such versions: r7561, r7584, r7589.
But why there is such problem at the disabled option "Speed up disc transfer"?
Whether there will be other bugs, errors at enabled this option?
It is necessary to make so that people knew that at appearance of the given problem it is possible to try to enable an option "Speed up disc transfer". How they learn it?
Also these are probably similar to the given problem: issue 4508, issue 4328.

I have enabled this option by default in the build.

"Thanks, skidau! Enabling of an option "Speed up disc transfer" has solved this problem."

This makes sense.
The speed change caused by r7318 is only noticeable with the emulated "disc access time" behaviour (as in, with "Speed up disc transfer" disabled by default).
With the non-emulated, less-accurate behaviour (as in, with this option enabled), the disc transfers will still perform as fast as possible, and thus remain the same as before r7318.

DimitriP, I agree with you. You are right.

Isn't a bit "strange" that the safest option is the one speeding up loading times? I mean usually in emulators the slower the loading times are the safest they are and an option for speeding up is used "at your own risk", but here we have the opposite...

That is because the default is too slow. Dolphin's timing is approximate to the real thing in some places.

Just ran it from jit64 debugger. I see this when pressing A at howling stone. Newest builds don't crash with compiler message popup but now video and audio locks up with no error message. This is output when it locks in debugger:

First-chance exception at 0x134497f1 in DolphinD.exe: 0xC0000005: Access violation reading location 0x00000000b8200020.
First-chance exception at 0x13449b01 in DolphinD.exe: 0xC0000005: Access violation reading location 0x00000000b80303a0.

Possible invalid pointers?

To avoid the freeze in Zelda games avoid VPS overflows DO NOT use fps limiter

Well, this one looks interesting after all, even with a rev number, i'll play through from the start again up to this moment, to see if it's true or not on recent revs