[LoRd_MuldeR]

Originally Posted by MrVideo

I had to search the C: drive in order to find lxp_xurl. When I manually run it, it povides me with some help options. But, there was no failure.

Just go to the %TMP% directory. LameXP will create a sub-folder with a random name here on startup. The lxp_curl.exe you are looking for will be in there.

Originally Posted by MrVideo

I have no idea what I am looking for in its output. But, it didn't complain about no DLLs not being found.

Watch out for a missing DLL file, or for a missing entry point in one of the required DLLs. For me all looks good on my Windows XP machine though:
https://imgur.com/a/7SyOy5j

(Note: Warning about delay-loaded DLLs can be ignored, because delay-loading is commonly used for optional dependencies)

Originally Posted by MrVideo

As a test, I did: lxp_curl -I --url http://forum.doom9.org and all went well. It displayed the http header.

Then I don't understand what was the problem before

In your earlier post you said that cURL failed to run with error code -1073741515, aka 0xC0000135, aka STATUS_DLL_NOT_FOUND:
https://docs.microsoft.com/en-us/ope...c-49e60bebca55

So that would have indicated that the cURL process could not be created because of a missing DLL.

If, however, you can start cURL from the command-line without problem, and if you are 100% sure that you were testing the same "lxp_curl.exe" file, then a missing DLL apparently is not the problem.

Originally Posted by MrVideo

Why not just ping 8.8.8.8? That IP isn't going away any time soon.

Ping is a whole different thing than HTTP. While HTTP is based on TCP, the "ping" command is implemented via ICMP. Note that ICMP is neither based on TCP nor UDP, but is a "layer 3" protocol of its own.

Generally, a working "ping" does not guarantee that a HTTP/TCP connection will work too. At the same time, if a sever doesn't respond to "ping", it could still respond to HTTP/TCP. Many web-servers block ICMP for security reasons.

So, it is much more meaningful to test an actual HTTP/TCP connection than only "ping'ing" the server.

Furthermore, trying to connect to an IP address instead of a host name wouldn't test DNS resolution at all! So, we have to connect to an actual host name, in order to see whether DNS resolution is working properly.

Last but not least, testing just a single host name (server) would be unreliable, because it would introduce a single point of failure.

That's why we have a list of many "known" host names (160 at this time), and we consider the Internet connection to be "working" as soon as at least 5 out of those could be reached successfully.

Originally Posted by MrVideo

I just noticed that when extracting flac tracks from a flac file, the directory that is created always has a " (2)" added to the name, even though it is the only directory there.

Oh wait, I see why it did it. If the flac file is named: Album.flac, it tries to create a working directory called: Album.flac. Obviously that is a conflict. The directory that contains the files is called: Album. So, why not make the working directory: Album. Then there won't be a conflict.

I assume you are talking about CUE sheet import here

In fact, the default (suggested) name of the output folder is based on the file name of the .cue file that you are importing, not on the name of any of the Wave, FLAC or whatever file(s) that are referenced in the .cue file.

The suggested output folder name should contain a "…(n)" suffix, if and only if a file or directory of the name without that suffix already exists.

Is it possible that your .cue file was called something like "album.flac.cue" and therefore the suggested output folder name would be "album.flac", but a file named "album.flac" already existed?