Re: [hlds_linux] Replay corruption/crashing
On 22/02/2012 18:30, doc wrote: I've assumed if they are going to crash it crashes in the beginning when you load the file. I don't think I've seen any ones that crash in the middle of the replay. Thanks, that's obviously makes it a lot quicker if so. I've Gone through all the turbine source tv replays (around 51) I had too and none of them fail either. -- Dan. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
I've assumed if they are going to crash it crashes in the beginning when you load the file. I don't think I've seen any ones that crash in the middle of the replay. On Wed, Feb 22, 2012 at 9:58 AM, dan wrote: > > So is my assumption correct? Can I just load each demo to see if it loads, > or do I need to play them all beginning to end? Can the model loader null > bug trigger half way through playing a demo, or will it always occur when > the demo is loaded? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
On 22/02/2012 14:22, dan wrote: On 22/02/2012 02:52, Jon Lippincott wrote: Can anyone confirm that this same error shows up in SourceTV demos? Never ime of copying them from my server to watch. But I've only copied a small %age, perhaps I was lucky. I've got about 192 though, so I'll try them. I've not found any yet after loading all the 2fort ones I had (around 50), but I realised I made the assumption that if the demo is corrupt it will crash tf2 when I load it without me having to play the whole thing. I know that happens with replays, but they are typically short replays anyway. So is my assumption correct? Can I just load each demo to see if it loads, or do I need to play them all beginning to end? Can the model loader null bug trigger half way through playing a demo, or will it always occur when the demo is loaded? -- Dan. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
On 22/02/2012 02:52, Jon Lippincott wrote: Can anyone confirm that this same error shows up in SourceTV demos? Never ime of copying them from my server to watch. But I've only copied a small %age, perhaps I was lucky. I've got about 192 though, so I'll try them. -- Dan. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
More interesting: does this happen while the item systems are down (nobody using unlocks) > > From: Jon Lippincott >To: Half-Life dedicated Win32 server mailing list >; Half-Life dedicated Linux server mailing list > >Sent: Wednesday, 22 February 2012, 3:52 >Subject: Re: [hlds_linux] Replay corruption/crashing > >Can anyone confirm that this same error shows up in SourceTV demos? > >-Jon > >From: hlds-boun...@list.valvesoftware.com >[mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Jon Lippincott >Sent: Monday, February 20, 2012 4:44 PM >To: Half-Life dedicated Linux server mailing list; Half-Life dedicated Win32 >server mailing list >Subject: [hlds] Replay corruption/crashing > >Hi everyone. > >The thing that's been tricky about this particular bug is that it occurs >intermittently. In order to fix it, we need a way to reliably reproduce the >error. I am hoping I can get some of you to help so that we can put this issue >to bed. > >The problem seems to stem from corrupt replay data being written on the >server. If possible (if it isn't completely random), I need to get the server >into a state where it will reliably write a bad replay. Does a particular map >need to be loaded? Is it a particular item that's equipped? If anyone has >specific information on this, please let me know. Your help would be greatly >appreciated! > >-Jon >___ >To unsubscribe, edit your list preferences, or view the list archives, please >visit: >https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
Can anyone confirm that this same error shows up in SourceTV demos? -Jon From: hlds-boun...@list.valvesoftware.com [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Jon Lippincott Sent: Monday, February 20, 2012 4:44 PM To: Half-Life dedicated Linux server mailing list; Half-Life dedicated Win32 server mailing list Subject: [hlds] Replay corruption/crashing Hi everyone. The thing that's been tricky about this particular bug is that it occurs intermittently. In order to fix it, we need a way to reliably reproduce the error. I am hoping I can get some of you to help so that we can put this issue to bed. The problem seems to stem from corrupt replay data being written on the server. If possible (if it isn't completely random), I need to get the server into a state where it will reliably write a bad replay. Does a particular map need to be loaded? Is it a particular item that's equipped? If anyone has specific information on this, please let me know. Your help would be greatly appreciated! -Jon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
If it's about some item, could be the grordbort weapons as i've seen 2 kinds of errors while loading replay after downloading it succcessfully. - GetDynamicBaseline: FindStringIndex(192-CTFLaserPointer) failed - CModelLoader::FindModel: NULL name I'll see if i have the borked replays still saved later today. I can look through server logs at that time which layout the people involved had on. -ics 21.2.2012 2:43, Jon Lippincott kirjoitti: Hi everyone. The thing that's been tricky about this particular bug is that it occurs intermittently. In order to fix it, we need a way to reliably reproduce the error. I am hoping I can get some of you to help so that we can put this issue to bed. The problem seems to stem from corrupt replay data being written on the server. If possible (if it isn't completely random), I need to get the server into a state where it will reliably write a bad replay. Does a particular map need to be loaded? Is it a particular item that's equipped? If anyone has specific information on this, please let me know. Your help would be greatly appreciated! -Jon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
On 21/02/2012 02:44, dan wrote: On 21/02/2012 02:19, Mart-Jan Reeuwijk wrote: would be handy if we had verbose logging where stated is: - what loadout/strange and/or festive - what hats/effects and a cross link with if replay got garbled Well it would be nice but we don't Something like this might help narrow it down a bit 1. Join a server with replay enabled. 2. Choose spectate. 3. Start recording a demo 4. Hit F6 + esc to get a replay 5. Spectate the players for a bit seeing what weapons they have 6. Disconnect. 7. If the replay fails you have a demo of most of the player loadouts to see whatever everyone had. 8. Try and recreate, on an empty server bar yourself, with each loadout from step 7. I'm at step 8 at the moment, I've got 3 replays that fail and, for the last one, a demo that works of the game in progress. Ok, after a lot of trial and error and mostly successful replays recorded. I managed to cause a replay to fail, on an empty server bar me. Map: ctf_turbine Class : sniper Loadout : stock sniper rifle, razorback, tribleman's shiv, genuine anger In the 8 steps someone had a similar loadout, so it could be significant. The replay was just leaving spawn, switching weapons a couple of times, firing a few shots and then hitting k to kill. Nothing out of the ordinary that I can recall. But, then I joined another empty server, played a life as demo, played a life as sniper with that loadout again and both replays worked. So, I think it's either independent of loadout or anything players are doing or you have do something subtle with that sniper loadout to trigger it. Either way, an empty server with the round just starting as described above gave me the null model error, so you probably don't need anything special to recreate this, except lots of trials until the problem happens. I must have recorded around 2 1/2 pages of demos, so around 30. Of them all bar 1 on an empty server worked. One with me playing on a full 2fort server worked too, and 3 made on a full plr map failed. HTH. -- Dan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
On 21/02/2012 02:21, Eli Witt wrote: I've watched my access/error httpd logs closely over the last 8 months in order to see what's going on, and it's simple to see what replays are corrupting(ed) by what .dmx files are requested endlessly for all time. These are presumably a different issue. The corrupt replays people have are downloaded successfully from the server, they just don't work when you try to watch them. -- Dan. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
On 21/02/2012 02:19, Mart-Jan Reeuwijk wrote: would be handy if we had verbose logging where stated is: - what loadout/strange and/or festive - what hats/effects and a cross link with if replay got garbled Well it would be nice but we don't Something like this might help narrow it down a bit 1. Join a server with replay enabled. 2. Choose spectate. 3. Start recording a demo 4. Hit F6 + esc to get a replay 5. Spectate the players for a bit seeing what weapons they have 6. Disconnect. 7. If the replay fails you have a demo of most of the player loadouts to see whatever everyone had. 8. Try and recreate, on an empty server bar yourself, with each loadout from step 7. I'm at step 8 at the moment, I've got 3 replays that fail and, for the last one, a demo that works of the game in progress. -- Dan. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
Speaking as someone who's been running replays using the FTP offload since day 1, I can reliably say that any certain map is not the cause of the problem. I've watched my access/error httpd logs closely over the last 8 months in order to see what's going on, and it's simple to see what replays are corrupting(ed) by what .dmx files are requested endlessly for all time. tail -n 3 error.log was the smallest I needed to go to see this: [Mon Feb 20 20:43:20 2012] [error] [client ] File does not exist: /var/www/fastdl/replays/20110603-181226-cp_gorge.dmx Which brings me to a little sidenote bitchfit I want to throw. There's a TF2 client still mindlessly trying to download a 8 month old replay file, over and over, even though it's gotten probably close to 10,000 404 errors on that particular request. I can tell you the idle habits of some people who've got static IP's based on the 404 patterns in my error.log files. tl;dr certain map isn't the cause - it's something else be it server hiccup, player, model, whathavenot. Any admins out there that run one of those vanilla no unlockables no items/hats/stuff servers that doesn't sit empty 24/7 who can chime in and say if yous server ever has crapped out replays? That would certainly go a long way to determining if some unlockable/wearable/unusual hat effect is the root cause, because that option is so far inside the ballpark of possible I can taste it. On Mon, Feb 20, 2012 at 8:46 PM, dan wrote: > On 21/02/2012 00:43, Jon Lippincott wrote: > >> Hi everyone. >> >> The thing that's been tricky about this particular bug is that it occurs >> intermittently. In order to fix it, we need a way to reliably reproduce the >> error. I am hoping I can get some of you to help so that we can put this >> issue to bed. >> >> The problem seems to stem from corrupt replay data being written on the >> server. If possible (if it isn't completely random), I need to get the >> server into a state where it will reliably write a bad replay. Does a >> particular map need to be loaded? Is it a particular item that's equipped? >> If anyone has specific information on this, please let me know. Your help >> would be greatly appreciated! >> > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
would be handy if we had verbose logging where stated is:
- what loadout/strange and/or festive
- what hats/effects
and a cross link with if replay got garbled
couple dozen of those combinations will prolly get some direction in what to
look for.
and a look into the physics doing way more distance punch with explosions etc
then should be would maybe also be handy in this regards...
>
> From: dan
>To: Half-Life dedicated Linux server mailing list
>
>Sent: Tuesday, 21 February 2012, 2:46
>Subject: Re: [hlds_linux] Replay corruption/crashing
>
>On 21/02/2012 00:43, Jon Lippincott wrote:
>> Hi everyone.
>>
>> The thing that's been tricky about this particular bug is that it occurs
>> intermittently. In order to fix it, we need a way to reliably reproduce the
>> error. I am hoping I can get some of you to help so that we can put this
>> issue to bed.
>>
>> The problem seems to stem from corrupt replay data being written on the
>> server. If possible (if it isn't completely random), I need to get the
>> server into a state where it will reliably write a bad replay. Does a
>> particular map need to be loaded? Is it a particular item that's equipped?
>> If anyone has specific information on this, please let me know. Your help
>> would be greatly appreciated!
>
>It's difficult to spot a pattern, because there are some things quite often
>the same for me whenever I'm playing yet some replays work, some don't.
>
>So I'm fairly sure my loadout and class or map choice don't trigger it.
>
>- It'll usually be a Valve server (one of the fra ones)
>- Usually playing CTF, either 2fort, turbine or doublecross
>- I'll usually be playing demoman or soldier, with various loadouts - i.e I
>can't say "It fails when I use weapon X"
>
>So, I doubt a specific map triggers it. If a specific class or loadout does,
>I'm fairly sure that demo and soldier aren't the culprits.
>
>If I get time later I'll try on an empty server to record a replay with each
>class, see if I can find something repeatable.
>(Do you know if source tv has the same problem? Because it's easier for me to
>get these)
>
>FWIW, although perhaps you've seen lots of failure cases :-
>Here's a specific example from 2 rounds from the same map and game on Valve's
>server.
>
>The first one worked fine (it ended when the round ended) :-
>
>February 16th, 4:13pm
>
>"20120216-171314-ctf_doublecross"
>{
> "handle" "1176"
> "name" "20120216-171314-ctf_doublecross"
> "recording" "0"
> "base_download_url" "http://146.66.153.17:80/008/";
> "server_start_record_tick" "3419"
> "last_block_to_download" "20"
> "last_consec_block_downloaded" "20"
> "server_session_id" "0x2D32B53F"
> "all_blocks_downloaded" "1"
>}
>
>"replay_8833"
>{
> "handle" "8833"
> "map" "ctf_doublecross"
> "session" "1176"
> "spawn_tick" "0"
> "death_tick" "20582"
> "status" "3"
> "complete" "1"
> "length" "313.725006"
> "postdeathrecordtime" "5"
> "rendered" "0"
> "player_slot" "7"
> "max_block" "20"
> "start_time" "1709.027100"
> "title" "ctf_doublecross: February 16, 2012 @ 4:13 PM"
> "recon_filename" "20120216-171314-ctf_doublecross_8833.dem"
> "screenshots"
> {
> "screenshot"
> {
> "width" "512"
> "height" "320"
> "base_filename" "20120216-171314-ctf_doublecross_0"
> }
> }
> "record_time"
> {
> "date" "1583"
> "time" "4528"
> }
> "player_class" "3"
> "player_team" "2"
> "killer_class" "0"
> "kills"
> {
> &q
Re: [hlds_linux] Replay corruption/crashing
On 21/02/2012 00:43, Jon Lippincott wrote:
Hi everyone.
The thing that's been tricky about this particular bug is that it occurs
intermittently. In order to fix it, we need a way to reliably reproduce the
error. I am hoping I can get some of you to help so that we can put this issue
to bed.
The problem seems to stem from corrupt replay data being written on the server.
If possible (if it isn't completely random), I need to get the server into a
state where it will reliably write a bad replay. Does a particular map need to
be loaded? Is it a particular item that's equipped? If anyone has specific
information on this, please let me know. Your help would be greatly appreciated!
It's difficult to spot a pattern, because there are some things quite
often the same for me whenever I'm playing yet some replays work, some
don't.
So I'm fairly sure my loadout and class or map choice don't trigger it.
- It'll usually be a Valve server (one of the fra ones)
- Usually playing CTF, either 2fort, turbine or doublecross
- I'll usually be playing demoman or soldier, with various loadouts -
i.e I can't say "It fails when I use weapon X"
So, I doubt a specific map triggers it. If a specific class or loadout
does, I'm fairly sure that demo and soldier aren't the culprits.
If I get time later I'll try on an empty server to record a replay with
each class, see if I can find something repeatable.
(Do you know if source tv has the same problem? Because it's easier for
me to get these)
FWIW, although perhaps you've seen lots of failure cases :-
Here's a specific example from 2 rounds from the same map and game on
Valve's server.
The first one worked fine (it ended when the round ended) :-
February 16th, 4:13pm
"20120216-171314-ctf_doublecross"
{
"handle""1176"
"name""20120216-171314-ctf_doublecross"
"recording""0"
"base_download_url""http://146.66.153.17:80/008/";
"server_start_record_tick""3419"
"last_block_to_download""20"
"last_consec_block_downloaded""20"
"server_session_id""0x2D32B53F"
"all_blocks_downloaded""1"
}
"replay_8833"
{
"handle""8833"
"map""ctf_doublecross"
"session""1176"
"spawn_tick""0"
"death_tick""20582"
"status""3"
"complete""1"
"length""313.725006"
"postdeathrecordtime""5"
"rendered""0"
"player_slot""7"
"max_block""20"
"start_time""1709.027100"
"title""ctf_doublecross: February 16, 2012 @ 4:13 PM"
"recon_filename""20120216-171314-ctf_doublecross_8833.dem"
"screenshots"
{
"screenshot"
{
"width""512"
"height""320"
"base_filename""20120216-171314-ctf_doublecross_0"
}
}
"record_time"
{
"date""1583"
"time""4528"
}
"player_class""3"
"player_team""2"
"killer_class""0"
"kills"
{
"kill"
{
"victim_name""laurinarthen"
"victim_class""1"
}
"kill"
{
"victim_name""Yiddery"
"victim_class""4"
}
"kill"
{
"victim_name""sveta2012viva"
"victim_class""2"
}
"kill"
{
"victim_name""laurinarthen"
"victim_class""1"
}
"kill"
{
"victim_name""JurdeV (NL)"
"victim_class""7"
}
"kill"
{
"victim_name""sveta2012viva"
"victim_class""2"
}
"kill"
{
"victim_name""sveta2012viva"
"victim_class""9"
}
"kill"
{
"victim_name""laurinarthen"
"victim_class""6"
}
"kill"
{
"victim_name""SnoopingYid"
"victim_class""8"
}
"kill"
{
"victim_name""coenjurling"
"victim_class""1"
}
"kill"
{
"victim_name""laurinarthen"
"victim_class""1"
}
"kill"
{
"victim_name""JurdeV (NL)"
"victim_class""7"
}
"kill"
{
"victim_name""am"
"victim_class""6"
}
"kill"
{
"victim_name""[FR]Vachekîrit"
"victim_class""2"
}
"kill"
{
"victim_name""Yiddery"
"victim_class""4"
}
}
"dominations"
{
"Domination"
{
"
Re: [hlds_linux] Replay corruption/crashing
Hi Alex, Thanks for the response. It isn't that we need example replays with the error - we need to be able to catch the actual server in action, writing corrupted data. In order to do so, we need to figure out what causes the server to write that corrupted data in the first place. Under what circumstances will a server write a bad replay? That's the question for which I am trying to find an answer. It may be that a specific item is equipped on one of the players, and that's screwing things up - I'm not sure. That's what I need help finding! Thanks again. -Jon -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Alex Kowald Sent: Monday, February 20, 2012 5:08 PM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] Replay corruption/crashing Glad this is being looked into! Pretty much all of the replays I try to download do not work so it's a big problem. It's very reproducible! They download just fine and when I try to watch/edit I get this lovely error message: CModelLoader::FindModel: NULL name It does this on the following maps: arena_well, arena_granary, arena_offblast, arena_watchlower though I doubt the map is the problem. I'm running linux and I use the local file replay method. Now, I run a heavily modded server that gives players random loadouts.. so I've kept my mouth shut. It's probably causing trouble, but I have gotten a few replays to work in the past. :) If you need them, I have some replay files saved that crash. Just tell us how we should submit them (just the .dem?) and I can send off a few. Thanks again! On Mon, Feb 20, 2012 at 7:43 PM, Jon Lippincott wrote: > Hi everyone. > > The thing that's been tricky about this particular bug is that it occurs > intermittently. In order to fix it, we need a way to reliably reproduce the > error. I am hoping I can get some of you to help so that we can put this > issue to bed. > > The problem seems to stem from corrupt replay data being written on the > server. If possible (if it isn't completely random), I need to get the server > into a state where it will reliably write a bad replay. Does a particular map > need to be loaded? Is it a particular item that's equipped? If anyone has > specific information on this, please let me know. Your help would be greatly > appreciated! > > -Jon > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Replay corruption/crashing
Glad this is being looked into! Pretty much all of the replays I try to download do not work so it's a big problem. It's very reproducible! They download just fine and when I try to watch/edit I get this lovely error message: CModelLoader::FindModel: NULL name It does this on the following maps: arena_well, arena_granary, arena_offblast, arena_watchlower though I doubt the map is the problem. I'm running linux and I use the local file replay method. Now, I run a heavily modded server that gives players random loadouts.. so I've kept my mouth shut. It's probably causing trouble, but I have gotten a few replays to work in the past. :) If you need them, I have some replay files saved that crash. Just tell us how we should submit them (just the .dem?) and I can send off a few. Thanks again! On Mon, Feb 20, 2012 at 7:43 PM, Jon Lippincott wrote: > Hi everyone. > > The thing that's been tricky about this particular bug is that it occurs > intermittently. In order to fix it, we need a way to reliably reproduce the > error. I am hoping I can get some of you to help so that we can put this > issue to bed. > > The problem seems to stem from corrupt replay data being written on the > server. If possible (if it isn't completely random), I need to get the server > into a state where it will reliably write a bad replay. Does a particular map > need to be loaded? Is it a particular item that's equipped? If anyone has > specific information on this, please let me know. Your help would be greatly > appreciated! > > -Jon > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
[hlds_linux] Replay corruption/crashing
Hi everyone. The thing that's been tricky about this particular bug is that it occurs intermittently. In order to fix it, we need a way to reliably reproduce the error. I am hoping I can get some of you to help so that we can put this issue to bed. The problem seems to stem from corrupt replay data being written on the server. If possible (if it isn't completely random), I need to get the server into a state where it will reliably write a bad replay. Does a particular map need to be loaded? Is it a particular item that's equipped? If anyone has specific information on this, please let me know. Your help would be greatly appreciated! -Jon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
