I didn't know about that problem as I have "only" 368 tracks on my server.cow wrote:Took me a while to figure out what was going on.. but if i addd 1 track over 395 aseco locks up.. normaly if aseco doesnt just crash, it will kick everyone out of my server.. server continues like nothing happened.. but peopel cant join.
At first i thought it was just a corrupted track but tested this many times and it is any track over 395..
I can see it happening as when aseco trys to load the next track it loads ""
the server will apear to take for ever to start next race.. if i kill aseco now.. evrything is good and we continue.. if i dont most likely everyone will be booted.
HELP as 394 isnt enough tracks
But there's no hard-coded track limit in all of Aseco (there was one in /nextmap back in v0.7 but that's been fixed since v0.8 ). So I'm afraid I can't solve this problem right away... I will be adding more tracks to my server that may provoke the problem here too, and then I can try to find the cause, but I'm not just adding any random track so that will take some time. Has anyone else encountered problems with a large number of tracks?Right, so every time Aseco needs to fetch the entire track list from the server, it does that in chunks of 300 tracks. If it works fine with 368 tracks on my server, I can't imagine why that method would cause a problem on cow's server with 395. In fact it's designed to work with any number of tracks precisely because the list is fetched in reasonably-sized chunks.Mistral wrote:Dont remember exactly though, but i had to rewrite some code months ago cuz the gettracklist (or similar) call to the dedicated made it go wild when too much tracks were requested at once. felt like a bug
Increasing the script timeout wouldn't make a difference. Its default is 60 seconds and if some operation doesn't complete within that time, it rarely will -- but even if it does, something isn't right as it shouldn't have take that long in the first place.cow wrote:thought i'd mention.. windows
win aseco "crashes" i mean it goes to time out error which i have at 180 seconds.. i could increase the time but when aseco doesnt crash which is most of the time.. it boots everyone.
Thats not valid for every ASECO-version ... older versions were getting all tracks at once.Xymph wrote:Right, so every time Aseco needs to fetch the entire track list from the server, it does that in chunks of 300 tracks. If it works fine with 368 tracks on my server, I can't imagine why that method would cause a problem on cow's server with 395. In fact it's designed to work with any number of tracks precisely because the list is fetched in reasonably-sized chunks.
Probably, since chunk-based fetching was already done everywhere in v0.7 except /nextmap, which grabbed only one chunk of 300 tracks (so it didn't work if the current track was beyond #300 in the server's list). I'll take your word for it that it wasn't done block-wise in older versions, but it definitely is being done now in v0.8+.Mistral wrote:Thats not valid for every ASECO-version ... older versions were getting all tracks at once.Xymph wrote:Right, so every time Aseco needs to fetch the entire track list from the server, it does that in chunks of 300 tracks. If it works fine with 368 tracks on my server, I can't imagine why that method would cause a problem on cow's server with 395. In fact it's designed to work with any number of tracks precisely because the list is fetched in reasonably-sized chunks.
I am not even sure if the original ASECO is using the blockwise transfer or if it was fixed with some RASP release.
Hmm... I didn't even know the TMN server would load the same track multiple times into its track list.cow wrote:Dont know I'll try.. I'll set up another server so i can break it.
I found some dupes int he list and some crap tracks and got down to 368.. lol yeah same as you xymph
and that leads me to another question.. it was pretty easy to find dupes doing "wall" "speed" "smooth" and "tech".. but there has got to be an easier way.. and if there isnt.. shouldnt there be
