Doing a tracert doesn't reveal lost packets. each route serves at around 150ms. Same counts for a continuous ping test to e.g. google which is at around 118ms without any timeouts although at the same time the receiver image freezes. Pinging the main / backup cs server is around 150ms. I for my case am surprised at the moment cause it worked w/o flaws for the last months. Meanwhile I updated the receiver firmware, resetted all settings, set it up new, tried mgcamd and newcamd but those also freeze. I am stuck atm and returned to CCcam and have no clue why this "suddenly" started to happen to me.
Doing a tracert helps you figure out which hop (on the way of the source to the destination) is causing your decoding requests to get dropped.
If the cam doesn't receive the ACK in time it will retransmit the packet causing a delay, if the delay is long enough you end up with a freeze.
How in the world is pinging google supposed to help you figure out if your connection to cs is reliable?
How is icmp supposed to tell you if your tcp packets are reaching the destination in time?
Is your receiver connecting to google.com to decode stuff?
Are you having access to some super-secret cardserver running on google.com nobody else knows about?
Do a continuous tracert to the cs (main/backup) using tcp and wait for a freeze.
If the tracert shows a timeout the moment you have a freeze you know wherever your tunnel/connection is causing the problem or your local equipment.