Emulog.txt file growing over 1Gb+ while playing Onimusha Dawn of Dreams

[GoogleCodeExporter]

I tested revisions 5725 (one i currentlly using), 5691, 5350 and 5363, all the 
same.

2) What steps will reproduce the problem?
1.Run Onimusha Dawn of Dreams
2. Play for a while
3.Go check "emulog.txt" inside logs folder to find is "huge"

With recent versions of PCSX2 in the console windows i get "libdma: sync 
timeout" a lot if not all the time while playing. With older ones "IPU Invalid 
Intra DC Precision, switching to 9 bits
".The game runs ok with is known graphical glitches, nonetheless.
Log attached is from revision 5725.

Original issue reported on code.google.com by CJodi...@gmail.com on 6 Sep 2013 at 7:52

Attachments:

• log.txt

[GoogleCodeExporter]

Are you using the skipmpeg hack? also have to got auto gamefixes enabled?

Original comment by refraction on 8 Sep 2013 at 12:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tried something that worked pretty well for my logs, and might help in this 
cases.

Basically just compare the new message string with the previous, and if it's 
the same, just count it.

When there's a new message, print that previous message with the count. So that 
log might look like "libdma: sync timeout (x51614651984798321)"

Original comment by KrossX3 on 8 Sep 2013 at 3:24

[GoogleCodeExporter]

It would be possible to do that, however it's handy when debugging to see how 
often and when it's happening. If it happens once then doesn't happen for ages 
again, but does happen, we won't see what change in the game state would have 
triggered it :)

Original comment by refraction on 8 Sep 2013 at 3:31

[GoogleCodeExporter]

There's probably a next message. Even that log sample shows different 
messsages, so a fraction of that log would end up looking like:

libdma: sync timeout (x232165)
IPU Invalid Intra DC Precision, switching to 9 bits
libdma: sync timeout (x32158)
IPU Invalid Intra DC Precision, switching to 9 bits
libdma: sync timeout (x1155)

... and on and on. And when stopping:

Closing plugins...
Closing DEV9
Closing FW
Closing USB
Closing CDVD
Closing SPU2
Closing PAD
Closing GS
Plugins closed successfully.
Decommitting host memory for virtual systems...
EE/iR5900-32 Recompiler Reset (last message on cache)
----- (a good point to flush that last message)

In my test, rather than loosing "accuracy" in log timing it just avoided flood. 
Maybe it can be implemented differently from the log console to what it's 
written on the file.

Original comment by KrossX3 on 8 Sep 2013 at 4:22

[GoogleCodeExporter]

@ refraction
I do have auto gamefixes enabled, no skipmpeg hack. The only manual gamefix i 
have enabled is switch GSdx to software renderer to play FMVs.

I just tried with r5726, default settings, more or less the same. "libdma: sync 
timeout" appears in the log screen as soon as the game starts, it stops while 
in game but starts again if enter to any game menu (hit start, save spheres). 
The log file gets big fast but not as before.
But as soon as i enable "switch GSdx to software renderer to play FMVs"  all 
the same again.

Original comment by CJodi...@gmail.com on 8 Sep 2013 at 7:00

[GoogleCodeExporter]

Yes can you try using the manual gamefixes other than the software mode one to 
see if any of them help?

thanks

Original comment by refraction on 8 Sep 2013 at 7:40

[GoogleCodeExporter]

OK, i tried r5726 with EE timing hack and Ignore DMCA when busy individualy. 
Same result as and i quote myself :
"libdma: sync timeout" appears in the log screen as soon as the game starts, it 
stops while in game but starts again if enter to any game menu (hit start, save 
spheres)"

I noticed another thing "umulog" does not get deleted/reset when i close and 
reopen pcsx2. Everything that gets logged into it gets saved in there forever, 
which along with whatever is causing the massive log of
"libdma: sync timeout (x232165)
IPU Invalid Intra DC Precision, switching to 9 bits
libdma: sync timeout (x32158)
IPU Invalid Intra DC Precision, switching to 9 bits
libdma: sync timeout (x1155)"
makes the file grow exponentially.

Original comment by CJodi...@gmail.com on 8 Sep 2013 at 9:46

[GoogleCodeExporter]

It should reset.. have you tried running PCSX2 as admin? It might not let you 
delete files unless you are, which is why the log just grows exponentially.

as for the errors, onimusha has some serious issues with IPU that we have never 
managed to solve so far :(

Original comment by refraction on 8 Sep 2013 at 10:20

[GoogleCodeExporter]

Well running as admin did the trick, emulog resets when reopening pcsx2. Now 
this may stop it from reaching the 5gb it was when i noticed this issue, but 
the crazy logging persists making it grow pretty fast without manual gamefixes, 
even faster if "switch GSdx to software renderer to play FMVs" which is needed 
too properly watch some of the FMVs of the game.

Original comment by CJodi...@gmail.com on 8 Sep 2013 at 11:10

[GoogleCodeExporter]

the only other thing i can suggest you try is unticking all the logging output 
on the log window and see if that cuts it down a bit, although i don't know 
what options will turn what off.

Original comment by refraction on 9 Sep 2013 at 9:41

[GoogleCodeExporter]

Doing so helped a bit. Now "IPU Invalid Intra DC Precision, switching to 9 
bits" is the only thing being log like crazy.

May i suggest as a quick fix  to clear logs on close, this way emulog would 
work as a temporal file making less noticeable its growing so big.

Original comment by CJodi...@gmail.com on 9 Sep 2013 at 9:16

[GoogleCodeExporter]

if you cleared the logs on close, they wouldn't be useful to us developers as 
that's when we need them :P

Original comment by refraction on 9 Sep 2013 at 9:24

[GoogleCodeExporter]

Well, it shouldn't grow to gigs in a release build.
I like crossx's idea actually, even for proper logging.
If nothing changed between 2 EE / IOP strings, printing the same
thing over and over is just killing readability anyway.

Original comment by ramapcsx2.code on 13 Sep 2013 at 9:33

[GoogleCodeExporter]

In situations like this yeah, but in situations where it only shows it once at 
certain intervals, it would no longer display making it impossible to find when 
the problems happen.

Original comment by refraction on 13 Sep 2013 at 9:38

[GoogleCodeExporter]

Okay, it should only count then if 2 consecutive logs are the same.
We'll see the count increasing in those intervals and should a different
log line come up the old EE/IOP log wouldn't be buried.

Implementation of that is difficult though, I think.
The problem is that every plugin and such can throw logs down stdout
and thus this filter would need to sit there.

Dunno if that's possible but imo it's worth looking at it.
Imagine certain debug sessions with just 10mb files instead of 5GB :p

Original comment by ramapcsx2.code on 13 Sep 2013 at 9:58

[GoogleCodeExporter]

a better idea would be like the TBL Miss thing where it bombs out after so many 
consecutive errors.

so in this case, say log it for 100 lines, then if it's still going, stop 
logging it. But as you say, it'll take a fair bit of implementing ;p

Original comment by refraction on 13 Sep 2013 at 10:42