SEQ not decoding at times

[RavenCT]

Now I've had enough experience with it to know that you have to wait at times for a zone to decode, but it seems lately that since the last build, there are times when a zone won't decode at all. As a matter of fact, some times when that happens I get the "dot running across" the screen again.

I've made sure that I've pulled the latest CSV tree, did a:
make -f Makefile.dist
.configure
make
make install

so I should have a clean build. One thing to note with this is that it was happening to me last night trying to zone from DL into Karnors... It wouldn't decode, zone out and back, no decode, zone out and back... Poof, decoded almost as soon as I landed in the zone.

Stranger and stranger... I'll see if I can get the message it puts to the console when it doesn't decode (there's something there, but stupid me forgot to write it down or anything...)

Anyone else had this happening?

[cbreaker]

Yea, this has happened to me a bunch of times. However, I'd never had a time when I was not able to decode the zone after some time (sometimes up to 30 minutes)

Some notable zones are WL, Swamp of no hope, Kithicor Woods, Oasis. There's a few more but I forget what they are. These zones tend to take a long time to decode; sometimes they decode right away.

I'm thinking that the keys are sometimes more difficult to find. Perhaps this was a slight modification on Verants part, nothing to break SEQ, but causes longer decode times occationally..

But, I dunno, could be wrong. Probably. Most likely.

[RavenCT]

Strange thing about it finding the keys is that if I remeber correctly, the SEQ console would say that it found a key, found a key, found a key, found a key, or something like that...

Stranger still...

[STiLE]

Fear Plane has never once decoded for me. Ive zoned in Lord only knows how many times and sat there for who knows how many hours waiting for it. Even tried camping and coming back a few times and nothing. That sux considering it would be nice to know when my fookin epic mob is up. Oh well. Guess I get to do it the hard way :D

[S_B_R]

If you guys would have used the search function (http://seq.sourceforge.net/search.php?s=) you'd have your answers already... Raven, shame on you. You should know better ;)

It usually takes something to spawn to get a zone to decode. So for the Vast majority of times (like 99%) zoning and re-zoning won't help, and in some cases it could make your problem worse. You'll see this happen in less busy zones more often than the busy ones. The other 1% of the time you likely missed a zone packet and the zone might not ever decode.

So. Anyway. The Moral of this story is Don't zone back and forth over and over agian, just wait a while, or spawn a pet, or kill something and when it respawns you should get a decode. Or even get a friend to zone in after you that will work too. ;)

Oh and use the search function (http://seq.sourceforge.net/search.php?s=) in the future please...

[RavenCT]

Your correct, I know that SEARCH should be our first line of attack... but what I was talking about here was not a zone that was sparsly populated either with mobs or without them. I've had it happen in Karnors and Dreadlands... each time with more that 30 people in each zone... both of which I know that there are lots of spawns/deaths/etc...

It was just some strangeness with SEQ and I was curious about it...

Ah well, SEQ compiles on :)

[RSB]

I sometimes have to shut down SEQ, Log off my character, start SEQ, log back in and BAM everything works. But for me I'm starting to think that it may have been due to my Hub going bad....my new hub to GRRRR

RavenCT - it doesn't say it has found a key, it says it has found a POSSIBLE key if I'm not mistaken.

Could it be because SEQ just misses a packet on the network somehow?

RSB

[Dok]

On a semi-related issue, many times when I do zone in, I'm only getting some of the mobs to decode. The rest that dont, stay as unknown. This doesn't happen all the time, but definatly more often then not. Its just been recently since its started doing this (last 3 months probably). And yes, since I know someone is going to ask, I am using the lastest CVS.

Anyone experience anything like this?

On a side note, I am running VMWare to run linux, so it may be just vmware dropping packets once in a while, or maybe even my hub doing it, but I'd like to see if anyone else has any ideas as I'm out.

[Cryonic]

Yes. My fix was to use a better system with a PCI nic, rather than my P150 laptop with a pcmcia nic. The problem showed up because I was downloading stuff in the background, so the tcp/ip stack gives priority to traffic needing to go to the machine (rather than processing traffic going to other machines like my EQ box). So, built SEQ on a Quad PPro 200 with a 10/100 3Com Server NIC and it doesn't happen anymore.

[RSB]

The more I think about it the more it seems that it is due to packets being dropped as a possible cause.

My hub seems to be having a hard time transferring data that might have a larger packet size.

I can send 64k files and it is a bit slow but 128k normally times out. EQ is encredibly laggy and web pages don't fully load but MSN and IRC don't seem to be effected much.

I put a crossover cable between my windows machine and all works fine but going thru the hub with a number of different new cables and testing different combinations of ports show they all suffer from this lag. The hub shows no collisions.

My hub might have been going bad for a while can SEQ is just showing the end result of that.

RSB

[Ratt]

Oddly enough, I've experienced this.

Couple weekends ago, I took one of my SEQ laptops over to a friends house. My SEQ laptop works flawlessly on my home and work networks... but at my friends house, it had trouble decoding and was generally being a pain in the ass... just like he kept complaining about to me (which I blew him off) ...

But it seems the quality of your network does infact play a big part in how SEQ operates... which makes a bit of sense, but I wouldn't have believed it would have that large of an impact if I didn't see it for myself.

[cbreaker]

Yea, I concur =)

As the machine running EQ can simply get retransmits of the data it needs due to lost packets, SEQ has no such luxery since it's just watching and can't ask for retransmits. If a packet was missed the first time, I don't know if SEQ will look for it a second time.

Perhaps if SEQ was designed with this in mind, it could watch out for this, but it would probably involve a lot of extra coding that would probably not be worth it in the long run.

-cb

ps. I could always be wrong, in fact I probably am.

[high_jeeves]

I have noticed in the past, while doing other high activity transfers on my network, that while there is lots of traffic on the network, SEQ has problems. I would guess that in high traffic situations, a network card in promisc. mode (or atleast some network cards) drop lots of packets. This could also be the reason that on machines with a high datarate setting, data gets lost.

--Jeeves

[Virusmaster]

This has been an issue with me too at times. I agree with all of you EXCEPT S_B_R, with his "use the search function, your answer is in there" attitude, because he is simply WRONG. This is not the "spawn a pet" problem. I know this because I play a mage. I spawn a pet all the time, sometimes just to get a look at an empty zone to see what mobs are out there. What I've found almost always works is shutting SEQ down, restarting it and re-logging. That seems to work every time. And yes, some zones have this problem much more than others, and it's not due to the player or mob count. I'm thinking it may be a dropped packet problem, but I am no expert. Could be something else. Whatever it is, when "V" finds out I hope they exploit the problem and break SEQ, because then the problem will get fixed :) Until it's fixed I can live with it. It's really only a problem on raids when I don't have the luxury of logging for a few, and even then I can fake a LD if I have to.

BTW, you guys are the best. All of you, even the impatient ones that say "Use the search feature moron".

[high_jeeves]

I don think there is anything here for "V" to exploit.. the packet gets sent.. the EQ box receives it and ack's. The SEQ box drops it... its a freak of the network and has nothing to do with anything that could be exploited.

--Jeeves

[Ratt]

As I tried to explain Virusmaster, it's not an issue with SEQ, but an issue with a crappy network. I have 4 EQ machines going at Datarate 9 with Websurfing in the background on my home network and have exactly 0 problems with decoding in any zone. I take the SAME machine over to a friends network with 4 EQ machines going and no web surfing and the thing takes a crap like you wouldn't believe. The only different part here is the network ... hence, it's the network that screwed up, not SEQ.

There isn't really anything to fix or exploit as far as I can tell... other than taming your collisions and getting good, solid Cat5 cable with good/solid NIC cards and a hub.

[S_B_R]

Originally posted by Ratt
As I tried to explain Virusmaster, it's not an issue with SEQ, but an issue with a crappy network. I have 4 EQ machines going at Datarate 9 with Websurfing in the background on my home network and have exactly 0 problems with decoding in any zone. I take the SAME machine over to a friends network with 4 EQ machines going and no web surfing and the thing takes a crap like you wouldn't believe. The only different part here is the network ... hence, it's the network that screwed up, not SEQ.

There isn't really anything to fix or exploit as far as I can tell... other than taming your collisions and getting good, solid Cat5 cable with good/solid NIC cards and a hub.

I guess this is where I was coming from on my answer before... My Network is very stable and very few (if any) collisions. I use a Netgear 8port 10/100 hub and All my NICs are either Intel ProServer 10/100's or 3com 3c905(x)-TP's.

I have run as many as 8 Clients and 6 Instances of SEQ before on the same network with no trouble at all. 4 of those SEQ's were on Laptops 2 of them were running on the Firewall box exporting the $DISPLAY out to 2 other Windows boxes running Reflection/eXceed/etc...

I wonder if these problems have anything to do with the recent influx of Ultra-Cheap 10/100 NICs. Most of them that I have seen are basically the NIC equivalent of a WinModem, meaning most of the real work is being done by your CPU. Or it might be possible that these cards have signal strength issues (same goes for hubs here)...

[fryfrog]

Quad ppro 200's? i bet its fun to type "make -j4" :)

[Cryonic]

:)

It's about the equivalent of a PII750 (if such a beast had been made) since the PPro core is what ended up in the PII.

[STiLE]

why would you have to have a quad ppro setup to type -j4...just splits it up into 4 jobs. You can do that with 1 processor if you want...just might run into a problem depending how many jobs you split it into.

[Cryonic]

You just pointed out the reason why you would want a quad box to do -j4. Basically you want one compile job per processor, so for 1 cpu you definitely don't want to do -j4 or you most likely will end up slowing down the whole compile process.

[STiLE]

indeed...but thats not to say you cant do -j4 with just one ;)

[high_jeeves]

From my experience, you should try do -j(#of processors + 1).. it reduces compile times by about 10% (all processors stay at 100% all the time). I found this to be true on my old Dual PPro 200...

While you can do -jX on a single processor machine, it is generally slower to compile than executing one job at a time.

--Jeeves

[Conehead]

I was doing fine before I went to 4.0.1 4.0.0 worked fine although it crashed a lot. My machine is a PIII 550 with a PCI NIC and my network if 100 Mbit copper. I have a sniffer running and I have no packet loss. I am running cable modem with 1.5 meg a sec transfer and it is clean too. I really question the network quality responce. I think the code regressed. Hope you fix it because SEQ is useless to me now. It never decodes for me anymore.

Conehead

[Conehead]

Well after more investigation what do I find but a rouge NIC in another machine spamming my internal net. DOH! Seems to work fine now. Moons aligned or something cause this happened at the same time I pulled the CVS and rebuilt. How weird.

[RSB]

After replacing my hub all my problems cleared up too.

Well I still have problems but nothing to do with SEQ or my network 8)

RSB

[myleftfoot]

Completely offtopic:

S_B_R: I love your sig. That's exactly what I did to the company laptop as I handed it over when they laid me off. "Oh, no, all the data is intact! See, it is still running X-Windows. Here's the root password. Oh, the reason the hard drive light is on is because it's handling a scheduled job, don't shut it down early or it may crash. Have a good day."

Muhahahahahah....

[flobee]

I have been having thie problem on and off recently and sometimes more with certain zones such as WWL, and ToV takes about 10 minutes to decode. Even if i pet up or someone zones in etc. I'll start checking out my hardware to see if something is dying.

[Ari]

Originally posted by RSB
After replacing my hub all my problems cleared up too.

Well I still have problems but nothing to do with SEQ or my network 8)

RSB

Can I ask what hub you went with? I've been having this problem for months now and I'm starting to think about trying to fix it.

[Yueh]

Try the latest CVS. The decode is ridiculously quick :) I'm assuming Zaphod pulled some 30th century software trick out of his ... sleeve ... and made it work without an actual CPU :)

[Cyclone_T]

Hmm..

I dont know about all you blaming it on the network..

Im going to run a quick copy of EQ here and SEQ on the linux box and then copy what im seeing it do on the other computer *in the terminal window* as its trying to "decode" the zone.

It doesnt seem to have anything to do with networking at all, but rather finding the right "key" to decode??

Perhaps thats whats taking so long, because there are all these damn zones to surf through and it just has to find the right "zone key" to decode?

Mebbe not...

In the meantime *while those are loading up* I have another question. I've done a CVS search and i do know how to do the cvs -d:pserver (etc etc) thing to "upgrade" to the latest install..but once i've run that, do i have ot make install?? or something?

I was reading a post earlier on this thread and it seemed as tho once you install the CVS update you have to make install? or something like that?

I honestly dont know too much about Linux and I dont wanna do something thats not necessary and might f$#k up the SEQ install hehe.

SOo if anyone could fill me in on any additional tasks that might help, or even be required after the CVS update, that'd be great..thanks

Anyway back to the point:

Ok here's what my terminal is showing... and what its doing to "decode" the zone..as I believe thats what it is doing.

LOADING FILTER FILE: /usr/local/share/showeq/filters_netherbian.conf
Zone:EntryCode: Server, zone:Netherbian
TIME: 13:09 03/23/3174
EQ EPOCH OCCURRED AT <LARGE NUMBER HERE> SECONDS POST UNIX EPOCH
CHECKING KEY: 0X67000000
CHECKING KEY: 0X68000000
ZONE: Entered: ShortName: (etc etc etc)
**a bunch of crap about netherb lair map and all that, then continues on with the key thing**

CHECKING KEY: 0X6E000000
CHECKING KEY: 0X6F000000
*ETC, ETC ETC*
CHECKING KEY: 0X7F000000
Possible Key: 0xdc88ec36
DecodePacket(): FOUND KEY: 0x42ef529c
Decrpyting and dispatching with key: 0x42ef529c

*etc etc with all the stuffa bout your player and what not*

The thing with this is..all this took about 5 to 10 mins to decode

So im very sure it has nothing to do with the network itself, but something thats going on via game.

I think the closest relavent idea..is that its waiting for something to spawn to identify mobs with or something?

Other than that, i've known this thing to go on for upwards of 30 - 45 mins still trying to find the key..

Highest CHECKING KEY i've gotten it to was somewhere around 0xde000000

Or something like that..which was about 30 mins (ish) around there after i've zoned in already.

Most commonly takes its time on Kunark and some velious/luclin zones. More or less on luclin than velious, velious has random decode times

So im guessing its waiting for a spawn.

*shrugs*

All the same I still dont know if its the decode waiting for something to spawn to compare it to or if it is just going through the key's one at a time until it finds the proper one..

[high_jeeves]

1) Search and you will find:

http://seq.sourceforge.net/showthread.php?s=&threadid=523&highlight=update

(i know its unbeleivable, but it does work!)

2) It is looking for the key, we dont know the key... this IS a network issue most of the time. Packet loss on the network means ShowEQ isnt getting all the packets it needs to decode. All of the stuff in this thread is accurate. Please read it.

--Jeeves