next »

[matt-12345]

I have a large rar archive compressed non-solid. It contains many mod files. I saved a .pls play list from the .rar archive. The play list will load and it can play individual files from the archive without a problem. The problem: no matter what, xmplayer will want to read the entire archive to check the titles within the archive. (This is unacceptable when this archive is on a dvd due to constant reading.)
I already modified the .ini file by adding:
NoCheckDead=1
NoCheckScan=1
NoListExt=1

I also unchecked "verify file content" under the play list category in the options

The program also takes up a huge chunk of cpu usage as it's attempting to read from the rar file.

** Is there a way to deactivate any playlist check or scan that would take place??
(the nocheckscan command in the .ini only shuts off the warning if you try to exit.)

** I don't want it to even bother with scanning:

Any help is appreciated, thanks.
-Matt

[Ian @ un4seen]

No, I'm afraid there isn't currently any way to stop the tag/length scanning. As you say, it's needed to produce formatted titles (the playlist file's titles may not be using the chosen formatting). Note that the scanning runs at lowest priority, so shouldn't take CPU time away from anything else that needs it.

[Coma]

But it could be made an option, and when the option to skip scanning is selected, the user will have to settle with filenames in place of real names.

[matt-12345]

Yes, it would be an awesome option to add to this program. Thanks for the information.

- Even if I could match the pls formatting to the current format style, I think it still does the scan.

[Ian @ un4seen]

The problem is it's not possible to tell what formatting the playlist's title are using. But anyway, here's an update to try, which includes a "NoScanList" XMPLAY.INI setting to skip the scanning of playlist entries...

   www.un4seen.com/stuff/xmplay.exe

Note it'll only skip the scanning when the playlist entry includes the length.

[matt-12345]

Hey wow! Thanks a ton for the update!! This did fix one of the problems and allowed me to figure out what was going on.

Problem 1: Rar compression. Even though I was using non-solid compression, it wanted to read the entire file before it could get to the end of the play list.
Solution: Use 7z non-solid compression.

Problem 2: Xmplay still wants to read all the titles to see if there are any dead ones.

This can be stopped thanks to the .ini command nocheckdead, but only at startup.
Current solution: load play list, shutdown program, reload program, and enjoy!
-Is there a simple way to make it stop scanning for dead play list entries? (I bet you really hate me as of now; you don't have to put time into what I ask for as I am just curious).

I really appreciate you working on this issue. I downloaded the entire mod archive as of 2007. I'm currently finding a way to make this huge mass of music playable (I know, I'm insane). I've been working on decompressing, and re-compressing all this music to fit on a set of 8 DVDs.

[Ian @ un4seen]

Problem 2: Xmplay still wants to read all the titles to see if there are any dead ones.

The dead track scanning just involves checking that the file exists - it won't scan the title if it doesn't have to, eg. when the title has already been scanned (or "NoScanList" is in effect). With an archived file, it will actually just check that the archive exists - it won't look inside the archive for the file.

So the dead track scanning should be very quick (much quicker than scanning titles and lengths). Is it not?

[matt-12345]

Yes, it is much faster. For a 1.9 GB archive including 7109 files, it took 19 seconds to check for dead. This is being read on a DVD. Over a network 100Mbps, it took about two minuets. These speeds are perfectly acceptable. I had the mindset that it would continue longer. During the scan, it slows down access time to files in the play list, but is acceptable.

-Thanks again for the new feature you added to XMPlay. I highly recommend adding this to any future versions. It's extremely useful when it comes to low-bandwidth access, extremely fast access, archive access, and preventing wear and tear on hard drives or optical drives.

[Ian @ un4seen]

I guess "NoCheckDead" could be extended to skip dead checking on any new tracks (not just at startup). I have no personal preference as I don't use the option myself, so I'll leave it up to the masses to decide