OpenNap early disconnect and INCOMPLETE tag not being removed..

[WhiteLightningX]

Hey guys/gals, long time no post.. I put WinMX on a new laptop of mine and have run into strange problems that I've never encountered to date. When using OpenNap, it always says the user disconnected right before the file finishes up (anywhere from halfway to 40KB or sometimes less-just never makes it to the end lol), and even when files complete, if they complete that is, the __INCOMPLETE__ tag stays on the file, it never renames them. And i know the users are not disconnecting because they are still there if i retry or browse them. Soooo i dont know what's going on. Any ideas? WinMX sick? PC sick?  lol

Any help would be appreciated!

Oh! and how far along are we on the new client atm? I feel like a kid waiting for santa...I know it's not gonna get here any faster with me sitting up being anxious but I'm just curious. I'm sure it'll be a most excellent work, I was just wondering if there is any "super up to date awesome cool news" thats only happened recently. lol

[GhostShip]

I think I have heard of the failure to rename a completed file from the incomplete tag, it had something to do with the newer operating system having some security setting to block such activity, as to the failure to complete the files size wise that too may have something to do with the differing way of reading the files data/metadata, I know from testing the new client that the way it reads the files (the same way MX does) is not the same that windows does but the difference is usually minor.

Anyway no new news yet as its been a busy time in real world life for all of the developers but they are all bearing in mind that the time to get the whole project ready to go is drawing near, and we are all still working on areas that need fixing or improving.

[GhostShip]

I had a look through the forum and found these useful posts relating to the issue you mentioned I hope.

https://forum.winmxworld.com/index.php?topic=4804.msg29850#msg29850

https://forum.winmxworld.com/index.php?topic=8134.msg48800#msg48800

The basic issue is in where your downloading the files to as the default in a newer machine means the files go into a protected folder and that is why the files wont rename automatically when they are completed.

[winmxuser1234]

I've battled with something similar for years upon years myself, though for me it's something that occurs only at random.
A file will get to within maybe 3-20 bytes of it's end and then disconnect. The lost bytes are also at the beginning of the file (not at the end), so any ID3-V2 tag gets corrupted on such files (this actually makes it possible to check for lost bytes before the transfer finishes).

This has occurred on two fully different computers w/two different operating systems (Win-ME and Win-XP)
3 different model cable modems
2 different model routers.
(no these weren't all replaced in trying to troubleshoot this issue lol, just over the years things break (wear out or whatever) and get replaced)
At this point the only two things left remaining are the ethernet cable I use (seems like it shouldn't be the cable, everything else works fine), and Earthlink ISP.


Using v3.53.
Wondering if should I try 3.31 to see if it still happens (or maybe 3.54b?), I'm not so sure now if this actually began sometime around that version being released (for sure there was a period this never happened... been a user since v1.81 or 1.87 or whatever the original versions were before WPNP lol).

[reef]

@ winmxuser1234

Is this an issue with just opennap or does it occur on the wpn as well?
Also, does this only occur with movie files or also with mp3?

[winmxuser1234]

Whoops, I thought I had put that in the post...  It's only on Opennap, never on WPN.

I haven't dabbled enough in movie files to know if the issue occurs with them too, but for sure mp3s (had an "ALBW" file or 2 get corrupted by this too).
Seems I've had it happen on a couple .JPGs also.
It's extremely at random. Re-downloading them often will result in successful (complete) transfers, though not always.

[winmxuser1234]

Well, just had it happen on a .RAR file too.
Reverting to 3.31 made no difference.
Winrar won't even give me an option to try to "repair" it either

Can V2.6 be installed alongside 3.31 or 3.53? Anyone know if they would conflict with each other on the same PC? (no idea if this would even help)

[White Stripes]

you can install them side by side (make sure to specify a different install directory) but not run them side by side... you'd need to install a different opennap client and use a different port with it..

[winmxuser1234]

I fired up my old Win-ME box with v2.6 on that... Still happens.

It really seems like it's got to be something on the ISP end of things... But how?
How is it possible several bytes can go missing right at the beginning of a transfer without some sort of error occurring? Where in the heck do they go? lol

It happens maybe 1 out of 20 transfers on average, so I've just been dealing with it (not too real big of a deal with mp3s, though rar & zip files are another story). However a couple times I've seen other users unsuccessfully re-queue random files in my Uploads window that they had just finished downloading, which leads me to wonder if this is happening on outbound xfers too.

I guess no one else (except possibly the OP) has seen anything like this before?

[silicon_toad2000]

sorry for the noob questions, but how to you know the bytes are missing at the beginning of the file?

[White Stripes]

the first 300kb of a file on nap are backed by the hash.... if you are losing bytes at the beginning you are downloading a different file than the one the client is saying you are...

[winmxuser1234]

sorry for the noob questions, but how to you know the bytes are missing at the beginning of the file?

I can tell by the ID3-V2 tag (and occasionally also the mp3 header)  will be corrupted before the download finishes. When it does finish (disconnects) there will usually be a ID3-V1 tag present (which there would not be if the file was missing it's bytes at the end). The file will also not have skips or glitches in the middle of it (meaning the bytes are not lost somewhere in the middle).

the first 300kb of a file on nap are backed by the hash.... if you are losing bytes at the beginning you are downloading a different file than the one the client is saying you are...

Pretty sure the file I downloaded IS the file I requested from my search results...
If I click to download "This-Song.mp3" @320kbps for example, I get "This-Song.mp3" @320kbps (it'll just have a corrupted V2 tag), not "Some-Other-Unknown-Song.mp3" @ some other bitrate, if that's what you're saying.

Much of the time there's only a single user out there who has the file I want anyway, so there couldn't be another source for a different file to come from.

I guess I don't understand.

[White Stripes]

have you tried changing ports on where the nap client operates? use something in the high range.. 6699 is historically known as nap so your isp could be screwing with you...

have you tried an alternate nap client rather than just a different version of winmx (my personal favorite is lopster) ?

what about the nap server itself? does it do it for all of them? some nap servers arent winmx friendly... what version of what client is the other person usually using? (winmx 2.6 follows the rules closer than the 3.x series)

[WhiteLightningX]

Well it seems to be back to normal now. Right clicking the WinMx icon and selecting "run as administrator" from the compatibility menu fixes the _INCOMPLETE_ tag issue. Not sure if that's what fixed the early byte cut-off problem, but that is now gone as well. 
Thanks!

[winmxuser1234]

have you tried changing ports on where the nap client operates? use something in the high range.. 6699 is historically known as nap so your isp could be screwing with you...

have you tried an alternate nap client rather than just a different version of winmx (my personal favorite is lopster) ?

what about the nap server itself? does it do it for all of them? some nap servers arent winmx friendly... what version of what client is the other person usually using? (winmx 2.6 follows the rules closer than the 3.x series)

I'm using TCP 16699 (ME box) and 26699 (XP box). Same thing for UDP, adding a "1" or "2" to it.

It happens on most, if not all nap servers, yes (but never on WPN).

I was gonna ask if someone might have another client recommendation... (I messed with audioGnome for a bit many many years ago, however it didn't really do much for me so I ended up sticking with MX). I have heard of Lopster, I'll try to find it and give it a shot. I do know for an absolute fact V2.6 has worked for me in the past though (pretty sure 3.31 too), so I'm not too real sure another client will fix it.

I guess I will report back.


Also, thanks for reporting back on yours White Lightning. Good to know at least one of us has found a resolution.

[reef]

Utatane is a pretty nice opennap client with lots of customization and options. You can download it from the archives here...

httpss://archive.winmxworld.com/Utatane/Utatane_0253_English.zip