Author Topic: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads  (Read 43357 times)

Synetech

  • Posts: 129
Hi,

I've noticed that XMP (latest, and a bunch couple of old versions) is starting up slow again.  I've tried putting it in it's own directory, completely devoid of any skins, vis, plugins, etc. and it still starts up slow—YES I disabled my AV.

I've done some tests to figure out why and found that it does a whole lot of file access on startup, a lot of which look odd.

1.  It opens, reads, and closes, the desktop.ini file from the root of each and every drive available, TWICE!  Why?
2.  It then creates a temp file and renames it a million times (once for each of a WHOLE LOT of media types) and accesses and manipulates it.
3.  It then  accesses all the associated programs for those media types.

These are the extensions it renames the temp file to:
ANI, B3D, BMP, CAM, CLP, CR2, CRW, DCX, DDS, DIB, DJVU, DJV, ECW, EMF, EPS, FPX, FSH, G3, GIF, GSM, ICO, ICS, IDS, IFF, IW44, J2K, JNG, JP2, JPC, JPE, JPEG, JPF, JPG, JPM, KDC, LBM, LDF, LWF, MNG, NGG, NLM, NOL, PBM, PCD, PCX, PDF, PGM, PNG, PPM, PS, PSD, PSP, RAS, RGB, RLE, SFF, SFW, SGI, SUN, TGA, TIF, TIFF, WBMP, WBM, WMF, XBM, XPM

This is really odd behavior and I do not understand why it would do so.  Worse, it visibly impacts the startup time.


What's going on?

Synetech

  • Posts: 129
Okay I've done a little more testing.

The temp file thing was present in 3.0.0.7-3.3.0.1, 3.0.0.6- did not have it nor do 3.3.0.2+.

The desktop.ini access however is still present and is causing a significant slow down since it opens, reads, and closes all of them two times (not a big deal if you only have C:\ but if you've got more, then…)  It's done this since 2.1 (2.0 did not.)

Also, as of 3.3, it also opens, reads, and closes the desktop.ini file in the AppData directory a half a dozen times.

Finally, it opens, reads, and cloeses the xmplay.ini file several hundred times on startup, and the same plus a write for every read on shutdown.  This is a serious hit to startup (and shutdown) time.  It should only open and close it once, but even better it should only read/write once as a block.  Perhaps a memory mapped file or something?

Dotpitch

  • Posts: 2871
Over here it only loads \Application Data\desktop.ini (no file associations), and only once. And a giant list of windows-dll's, wdmaud.drv gets lots of attention, xmplay.ini is probably fully read once per option it contains (over 100 times to start with), plugin dll's a dozen times, and finally some hooked dll's are loaded. Also, the total library is checked for dead files. It all doesn't bother me that much, because I know applications can take some time to load (even explorer.exe can take half a minute here occasionaly). Most of the time it comes up within five seconds, so I'm pretty satisfied :).

These are the extensions it renames the temp file to:
ANI, B3D, BMP, CAM, CLP, CR2, CRW, DCX, DDS, DIB, DJVU, DJV, ECW, EMF, EPS, FPX, FSH, G3, GIF, GSM, ICO, ICS, IDS, IFF, IW44, J2K, JNG, JP2, JPC, JPE, JPEG, JPF, JPG, JPM, KDC, LBM, LDF, LWF, MNG, NGG, NLM, NOL, PBM, PCD, PCX, PDF, PGM, PNG, PPM, PS, PSD, PSP, RAS, RGB, RLE, SFF, SFW, SGI, SUN, TGA, TIF, TIFF, WBMP, WBM, WMF, XBM, XPM...
Looks like a list of files that shouldn't be loaded by XMPlay or a plugin. On the other hand, the ones I recognize are all image formats...

Torkell

  • Posts: 1169
@Synetech: Do you have any image manipulation/browsing programs installed? It could be that one of them has a global hook DLL which is doing this. Try starting notepad, and see what files it uses.

The desktop.ini access is probably by internal Windows functions or hook DLLs, not directly by XMPlay.

With xmplay.ini, if that's what's happening then it looks like Ian's using the Get/WritePrivateProfile functions, which open and perform a linear search through the file for each call. They're not really designed for mass reading/writing, but work well for individual settings. If you're not doing so Ian, it might be an idea to use Get/WritePrivateProfileSection.

The file reading shouldn't hit things too much, as the disk cache hangs around across calls. I can say from experience however that if the INI file's being accessed over a network then it will be sloooow.

@Dotpitch: A lot of those Windows DLLs will be either cached or already mapped into memory, so it won't cause too much of a performance hit. A small program I wrote ends up loading such fun things in it as asOEHook.dll (Norton AntiSpam, not relevant as my program doesn't do email), idle.dll (Yahoo messenger idle detection), BtBalloon (Bluetooth-related, again not relevant), three versions of the C runtime and two dlls for the IntelliPoint software.

Synetech

  • Posts: 129
Of course XMPlay will need to load, well, a load of DLLs and DRVs, since it is a multimedia app.  :)  I'm not too concerned with those, in fact most apps touch those, so I've filtered them out of FileMon.  As for explorer, what can I say?  Blech!  Still, it's my favorite shell, I just wish it wouldn't suck so much.  ;D  XMP doesn't take toooo long to load, but I remember it used to load faster.  I'm just trying to help optimize it (and figure out why it does this odd stuff.)



I did a few more tests and desktop.ini isn't accessed by other applications, it's obviously something that XMPlay is doing; perhaps some sort of drive enumeration (don't know why it needs to do that.)  I understand the INI-reading being the cause, but there's got to be a better way.  Opening and closing the file between reads is fine if there's only a few items, but when there's dozens/hundreds, it's not so good.  I'll try setting it to use the registry instead of the INI file and profiling it then (but then I'll have to use my reg backup to backup the settings).

Tsorovan

  • Posts: 1247
What I want to know is why you have desktop.ini files on the root of drives? I've never seen that.

Ian @ un4seen

  • Administrator
  • Posts: 20437
The desktop.ini access however is still present and is causing a significant slow down since it opens, reads, and closes all of them two times (not a big deal if you only have C:\ but if you've got more, then…)  It's done this since 2.1 (2.0 did not.)

Using Filemon, I don't see any of that. What Windows version are you using?

Also, as of 3.3, it also opens, reads, and closes the desktop.ini file in the AppData directory a half a dozen times.

This seems to be from a SHGetSpecialFolderLocation call (to get the AppData path). Certainly, XMPlay isn't directly accessing the DESKTOP.INI file :)

Finally, it opens, reads, and cloeses the xmplay.ini file several hundred times on startup, and the same plus a write for every read on shutdown.  This is a serious hit to startup (and shutdown) time.  It should only open and close it once, but even better it should only read/write once as a block.  Perhaps a memory mapped file or something?

The XMPLAY.INI file will be cached by Windows anyway, so the subsequent accesses shouldn't require any disk access. Looking at the Filemon log, you can see that the accesses are taking practically no time (probably under 50ms total to read all the INI options here).

Also, the total library is checked for dead files.

Just to clarify... the dead track/file checking is done after XMPlay is up and running ;)

Synetech

  • Posts: 129
What I want to know is why you have desktop.ini files on the root of drives? I've never seen that.

This is why ;):

Code: [Select]
[.ShellClassInfo]
IconFile=e:\winstuff\setup\icons\drives\c.ico
IconIndex=0
Infotip=Microsoft Windows XP Professional
HTMLInfoTipFile=e:\winstuff\setup\Folder Settings\c\Comment.htt
ConfirmFileOp=0
[ExtShellFolderViews]
{BE098140-A513-11D0-A3A4-00C04FD706EC}={BE098140-A513-11D0-A3A4-00C04FD706EC}
[{BE098140-A513-11D0-A3A4-00C04FD706EC}]
Attributes=1
IconArea_Image=e:\winstuff\setup\Folder Settings\c\Background.jpg
IconArea_Text=0x0080FFFF
IconArea_TextBackground=0x00008000

Honestly, it's mostly a relic from Windows 2000 which used HTT files to customize folders.  It was fantastic but XP doesn't really do that anymore.  :(  One use for it however is to skin the backgrounds and icon.



Using Filemon, I don't see any of that. What Windows version are you using?

I'm using XP.  I've saved a Filemon log of the accesses that I can send.  I find it very curious the way it does so.  [For me] XMP accesses the Desktop.ini files from the folders in this order: C:,G:,J:,F:,I:,E:,H:,D:,K:,M:,L:,O:,N:,AppData,Desktop    Very strange.  ???

This seems to be from a SHGetSpecialFolderLocation call (to get the AppData path). Certainly, XMPlay isn't directly accessing the DESKTOP.INI file :)

Probably, but why does XMP need the AppData path?  I thought it checks for an INI file in the current directory, then the registry (or vica versa).

The XMPLAY.INI file will be cached by Windows anyway, so the subsequent accesses shouldn't require any disk access. Looking at the Filemon log, you can see that the accesses are taking practically no time (probably under 50ms total to read all the INI options here).

For me it takes a total of 3.484 second to read my normal XMPlay.ini.  If I delete XMPlay.ini it takes 2.329 seconds to "read" it and 3.328 to read it after it creates the default.  Writing is always less than a ½ second no matter what.  There's 150 lines in the default and I've got almost 400 in my normal one.

Tsorovan

  • Posts: 1247
Ah. I use custom icons on certain dirs, but I use totally classic directories otherwise. I thought the settings for the roots were in the registry. Sorry for diverting you from the issue at hand.
* Tsorovan steps away

Synetech

  • Posts: 129
Ah. I use custom icons on certain dirs, but I use totally classic directories otherwise. I thought the settings for the roots were in the registry. Sorry for diverting you from the issue at hand.
* Tsorovan steps away

They are but there is more than one way to do it.  In fact I've got three different ways to do the icons in the registry, and two by file.  I not only use classic directories (uh, wait, you mean no sideband?) but also classic skin (I hate skins, they're pretty but slow things down.)  I just have the backs of my roots skinned (sounds like a dental statement :D).

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #10 on: 9 Aug '06 - 14:34 »
I'm using XP.  I've saved a Filemon log of the accesses that I can send.  I find it very curious the way it does so.  [For me] XMP accesses the Desktop.ini files from the folders in this order: C:,G:,J:,F:,I:,E:,H:,D:,K:,M:,L:,O:,N:,AppData,Desktop    Very strange.  ???

This seems to be from a SHGetSpecialFolderLocation call (to get the AppData path). Certainly, XMPlay isn't directly accessing the DESKTOP.INI file :)

Probably, but why does XMP need the AppData path?  I thought it checks for an INI file in the current directory, then the registry (or vica versa).

XMPlay needs to know the AppData path for per-user config.

I don't know why it's accessing all your DESKTOP.INI files, but I guess it's the same SHGetSpecialFolderLocation call. If you can, you could try testing SHGetSpecialFolderLocation and see if you get the same result. As I say, XMPlay doesn't specifically access any DESKTOP.INI files.

The XMPLAY.INI file will be cached by Windows anyway, so the subsequent accesses shouldn't require any disk access. Looking at the Filemon log, you can see that the accesses are taking practically no time (probably under 50ms total to read all the INI options here).

For me it takes a total of 3.484 second to read my normal XMPlay.ini.  If I delete XMPlay.ini it takes 2.329 seconds to "read" it and 3.328 to read it after it creates the default.  Writing is always less than a ½ second no matter what.  There's 150 lines in the default and I've got almost 400 in my normal one.

Is that just the XMPLAY.INI reading, or including the other stuff in between the first and final read? Note that the INI options aren't read all together.

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #11 on: 9 Aug '06 - 17:08 »
It's just the XMPlay.ini.  It does about 624 operations on it (open, lock, read, close).  Then it enumerates the folders in it's directory and starts loading plugins and depending on the plugin it will read the INI for them.  It then reads the INI some more, loads the viz files, then skins, more INI,  and it's done.  But, you're right, no single round of INI reads is longer than ½ a second.



As for desktop.ini, you're right it is SHGetSpecialFolderLocation.  But, why are you using it?  Try SHGetSpecialFolderPath, it's easier to use, faster since it doesn't cause the overhead of reading extra folders (roots, doc, etc. PLUS their desktop.ini's), and doesn't require linking to shell32.lib.

Code: [Select]
char buf[MAX_PATH]=_T("");
SHGetSpecialFolderPath(NULL, buf, CSIDL_APPDATA, FALSE);
Done.  :)

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #12 on: 11 Aug '06 - 12:28 »
It's just the XMPlay.ini.  It does about 624 operations on it (open, lock, read, close).  Then it enumerates the folders in it's directory and starts loading plugins and depending on the plugin it will read the INI for them.  It then reads the INI some more, loads the viz files, then skins, more INI,  and it's done.  But, you're right, no single round of INI reads is longer than ½ a second.

According to Filemon, it's well under half a second in total here :)

As for desktop.ini, you're right it is SHGetSpecialFolderLocation.  But, why are you using it?  Try SHGetSpecialFolderPath, it's easier to use, faster since it doesn't cause the overhead of reading extra folders (roots, doc, etc. PLUS their desktop.ini's), and doesn't require linking to shell32.lib.

Code: [Select]
char buf[MAX_PATH]=_T("");
SHGetSpecialFolderPath(NULL, buf, CSIDL_APPDATA, FALSE);
Done.  :)

The problem is I don't think that function is available on standard Win95. I guess it could be used when available though. Is the accessing of your extra DESKTOP.INIs really delaying things very much?

Btw, that function is in Shell32 too, and Shell32 is needed for other things anyway (so there's no avoiding it ;)).

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #13 on: 11 Aug '06 - 16:43 »
Try SHGetSpecialFolderPath, it's easier to use, faster since it doesn't cause the overhead of reading extra folders (roots, doc, etc. PLUS their desktop.ini's), and doesn't require linking to shell32.lib.
The problem is I don't think that function is available on standard Win95. I guess it could be used when available though. Is the accessing of your extra DESKTOP.INIs really delaying things very much?

I specifically remember 95 as being listed but I checked again and you're right, it requires IE 4 (4.71).  I'm guessing that you've already searched for functions that do this that support 95, so I won't keep looking.  It's a shame that you have to use a primitive function like that though, although like you said, you could use a better one when detected.  It's really just a matter of the extra overhead that the older function adds, that's all.  Maybe I'll do a profile some time, but for now it's not taking that long (just cut out any unnecessary plugins, skins, and vis and it's okay.)


Btw, that function is in Shell32 too, and Shell32 is needed for other things anyway (so there's no avoiding it ;)).

Yes, I thought that might be the case.


I'm still curious as to what was causing XMPlay to access all those file types.  It started doing that in 3.0.0.7 and stopped in 3.3.0.2.  Was there something that you added then took out (or fixed)?  It created a temp file and kept renaming it.  That was you right? not indirectly through a function?  Do you even have copies of the source of each version?  Personally I only make a backup whenever I'm about to make a big change, so I can't really diff much.  :(  Thank goodness for the unlimited undo function of the IDE, I use that to go back and make a copy of a previously working function to compare to what I've turned it into.  :D

Rah'Dick

  • XMPlay Support
  • Posts: 932
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #14 on: 11 Aug '06 - 17:51 »
I might be wrong, but the App Folder location can be read from the registry, not?

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData (REG_SZ) - under WinXP.

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #15 on: 11 Aug '06 - 18:01 »
No, you're right.  It can also be read by querying the %AppData% environment variable.

Each method has it's pros and cons.  The main reason to use an API function is for compatibility.  Not all methods are available on all platforms, so using an API call will allow you to get it without having to write platform-specific/detecting code.  (Of course if written correctly, the API call should use the least demanding—most efficient—method available on the target platform.)

Since one of XMPlay's goals is to be as compatible as possible (hey, it runs on everything from Windows 95A-Vista!) as well as to be as light as possible, it makes sense for Ian to use API calls instead of packing tons of functionality into the program itself, not to mention the waste of reinventing the wheel (unless of course you are making a better wheel.)  :)

Rah'Dick

  • XMPlay Support
  • Posts: 932
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #16 on: 11 Aug '06 - 18:07 »
Right... The question is, how many lines of code would this tradeoff require to work on all Windows versions - and how much would the startup efficiency gain from it?

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #17 on: 11 Aug '06 - 18:19 »
That's the €64,000 question.

Lines?  Well, you'd need several to query the OS version and a few more to if/case it.  You'd need some kind of function array or something to determine which function to call for the different platforms.  The main problem is that it's not always up to the Windows version, often it's up to the IE version which can vary across and even within Windows versions.

As for the gain, it depends.  I'm sure that most users of XMPlay will have simple systems with a couple of drives/partitions, a few special folders at default locations, and so on.  It probably starts up fast for most people—especially if they're not paying attention.  For the rest of us, it likely starts up fast enough—especially if we don't pay attention.

Torkell

  • Posts: 1169
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #18 on: 11 Aug '06 - 18:51 »
Yes, but reading it from the registry is a really bad way to do things. See http://blogs.msdn.com/oldnewthing/archive/2003/11/03/55532.aspx for how.

BTW, I recommend that blog to anyone interested in the nitty-gritty of the Windows shell, and why certain things are the way they are. It's got a fair bit of "how not to code"-type entries.
« Last Edit: 11 Aug '06 - 18:54 by BoggyB »

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #19 on: 11 Aug '06 - 19:06 »
Hehe, yup Raymond has some interesting and informative posts there.  :)

Like I said, compatibility.  But honestly, backward compatibility is one of the dumbest things Humans have ever done.  Screw those four programs, Hell, screw ALL programs!  Doing something right is more important.  Besides, any app worth having will either be updated or replaced.  Once I've finished laying my basic infrastructure, I will be recompiling all of my apps to be updated and to conform.

I am anxiously awaiting a Windows written completely from scratch.   :-\
« Last Edit: 11 Aug '06 - 19:24 by Synetech »

Rah'Dick

  • XMPlay Support
  • Posts: 932
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #20 on: 11 Aug '06 - 22:46 »
Yes, but reading it from the registry is a really bad way to do things. See http://blogs.msdn.com/oldnewthing/archive/2003/11/03/55532.aspx for how.

BTW, I recommend that blog to anyone interested in the nitty-gritty of the Windows shell, and why certain things are the way they are. It's got a fair bit of "how not to code"-type entries.
Nice article there. Ok, you convinced me.

Torkell

  • Posts: 1169
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #21 on: 12 Aug '06 - 22:03 »
Like I said, compatibility.  But honestly, backward compatibility is one of the dumbest things Humans have ever done.  Screw those four programs, Hell, screw ALL programs!  Doing something right is more important.  Besides, any app worth having will either be updated or replaced.  Once I've finished laying my basic infrastructure, I will be recompiling all of my apps to be updated and to conform.

I am anxiously awaiting a Windows written completely from scratch.   :-\
That's apparently what NT was.

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #22 on: 12 Aug '06 - 22:25 »
I am anxiously awaiting a Windows written completely from scratch.   :-\
That's apparently what NT was.

Except that it's still got backward compatibility, especially it's offspring.  Vista is just NT 6 and includes all the nasty compatibility stuff that all other Windows have had.  :(

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #23 on: 21 Aug '06 - 15:21 »
Oops, I only just noticed this post :)

I specifically remember 95 as being listed but I checked again and you're right, it requires IE 4 (4.71).  I'm guessing that you've already searched for functions that do this that support 95, so I won't keep looking.  It's a shame that you have to use a primitive function like that though, although like you said, you could use a better one when detected.  It's really just a matter of the extra overhead that the older function adds, that's all.  Maybe I'll do a profile some time, but for now it's not taking that long (just cut out any unnecessary plugins, skins, and vis and it's okay.)

To see whether it's worthwhile adding support for SHGetSpecialFolderPath (when available), how long is it taking to access the extra DESKTOP.INI files?

Here, the DESKTOP.INI accesses take practically no time (the time reading is constant)...

Code: [Select]
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_OPEN C:\Documents and Settings\...\desktop.ini SUCCESS Attributes: HSA
14:53:05.312 xmplay.exe:3200 IRP_MJ_CREATE C:\Documents and Settings\...\desktop.ini SUCCESS Options: Open  Access: All
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLOSE C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_LOCK C:\Documents and Settings\...\desktop.ini SUCCESS Excl: No Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_STANDARD_INFO C:\Documents and Settings\...\desktop.ini SUCCESS Length: 62
14:53:05.312 xmplay.exe:3200 IRP_MJ_READ C:\Documents and Settings\...\desktop.ini SUCCESS Offset: 0 Length: 62
14:53:05.312 xmplay.exe:3200 FASTIO_UNLOCK C:\Documents and Settings\...\desktop.ini RANGE NOT LOCKED Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLEANUP C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_OPEN C:\Documents and Settings\...\desktop.ini SUCCESS Attributes: HSA
14:53:05.312 xmplay.exe:3200 IRP_MJ_CREATE C:\Documents and Settings\...\desktop.ini SUCCESS Options: Open  Access: All
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLOSE C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_LOCK C:\Documents and Settings\...\desktop.ini SUCCESS Excl: No Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_STANDARD_INFO C:\Documents and Settings\...\desktop.ini SUCCESS Length: 62
14:53:05.312 xmplay.exe:3200 IRP_MJ_READ C:\Documents and Settings\...\desktop.ini SUCCESS Offset: 0 Length: 62
14:53:05.312 xmplay.exe:3200 FASTIO_UNLOCK C:\Documents and Settings\...\desktop.ini RANGE NOT LOCKED Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLEANUP C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLOSE C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_OPEN C:\Documents and Settings\...\desktop.ini SUCCESS Attributes: HSA
14:53:05.312 xmplay.exe:3200 IRP_MJ_CREATE C:\Documents and Settings\...\desktop.ini SUCCESS Options: Open  Access: All
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLOSE C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_LOCK C:\Documents and Settings\...\desktop.ini SUCCESS Excl: No Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_STANDARD_INFO C:\Documents and Settings\...\desktop.ini SUCCESS Length: 62
14:53:05.312 xmplay.exe:3200 IRP_MJ_READ C:\Documents and Settings\...\desktop.ini SUCCESS Offset: 0 Length: 62
14:53:05.312 xmplay.exe:3200 FASTIO_UNLOCK C:\Documents and Settings\...\desktop.ini RANGE NOT LOCKED Offset: 0 Length: -1
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLEANUP C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 IRP_MJ_CLOSE C:\Documents and Settings\...\desktop.ini SUCCESS
14:53:05.312 xmplay.exe:3200 FASTIO_QUERY_OPEN C:\Documents and Settings\...\XMPlay\xmplay.pls NOT FOUND Attributes: Error

I'm still curious as to what was causing XMPlay to access all those file types.  It started doing that in 3.0.0.7 and stopped in 3.3.0.2.  Was there something that you added then took out (or fixed)?  It created a temp file and kept renaming it.  That was you right?

Yep. That was to fix file associations that were made outside of XMPlay's Integration options. Now, instead of going through all file types at startup, it'll just check file types that arrive via DDE.

Synetech

  • Posts: 129
Re: ! XMP 3.3.0.5: Slow Startup / Unexplained File Reads
« Reply #24 on: 21 Aug '06 - 16:45 »
Ah, that explains it.  Well you fixed it nicely.   Now, if I could just get rid of all the plugins I don't actually use and trim down the Open dialog's file-type listbox…  :)


Oh, and what happens if there is more than one plugin that can handle a filetype.  For example, what if you have the native XMP MIDI plugin present as well as the Winamp MIDI plugin (and perhaps, another one as well), or maybe two 3rd party plugins for something that there is no native support for.  Which one is used to render the song?