[rtmpdump] Junk CTS Timestamps from C-SPAN1?(almost dupl message)

[Gunnar]

Almost duplicate message, thought first one had gone wrong, can be 
deleted, omitted

Anyway, the difference that I also managed to use a brute force fix on 
rtmpdump, managed to add a "sanity check" on the 24 bit (cmposition 
timestamp" in Read_1_Packet by using, the commented out (#if 0) old code.
Checks if CTS < 10000 as an unsigned int, if not sets it to 32.

HOWEVER, tried to print out, check "where it comes from" when loaded 
into the packet buffer but difficult to find "it" in the code.
My best try logs only nice "valid" timestamps which would mean something 
is overwriting, changing it somewhere "along the way".
However downloaded latest "official" windows rtmpdump.exe and it also 
produces junk-jumps.

Additionally the  magic of "only on CSPAN1" and "started a month ago" 
althgh one psbl oservation is that when started the CSPAN1 files have a 
very long delay between audio and video for mplayer to correct for?
Could cause ovf of buffers or similar in rtmpdmp?

Question: Where would be earliest time, code place where I can easily 
check the timestamp, as close to reading sockets as possible?
(I have yet to figure out how exactly this ReadN and buffering, decoding 
socket data is done, TCP, rtmp and video packet mess, not to forget 
timestamps here and there? plus resume code)

Gunnar

PS The junk-stamps occure maybe every 2-3 second, fairly regularly in 
1-2 bursts, values always "similar" in the same stream, file.
PPS have not tested on ubuntu yet, everything on windows