Hello Peter,
SLPacket.SLTERMINATE is an internal “flag” in the seedlink code to indicate that a termination request was received due to some “abnormal” state, or that the “end of buffer or selected time window” was reached. So it may be that there is something wrong with the packets or connection for GE.SLIT…HHZ. Do you see this behavior for other streams? Do you see this behavior when you are on a different Internet/network connection?
Anthony
Hi Anthony
That far I have understood things from looking under the hood of obspy, but clearly there seems to be no problems re-trying to read� streams from the socket (hence the connection is not properly closed), or alternatively simply reconnecting to the server, thus my question what would be the proper way to handle the problem as it obviously exists.
E.g. if re-connecting as done in the solution in my second post should I also try to make sure the socket is properly closed from my side or is this handled by SLClient automatically, or if simply continuing to attempt reading (using the collect() method) streams from the socket how to handle the gaps in the data that arises?�
Haven’t seen the behavior from some other stream and until today this stream were did not cause any problems either�
Haven’t tried some other network but can do so tonight from home.
regP
BTW, did you try running the script I attached in my original post? That would answer the question if the problem exists on you end of the wire as well
regP
Hi Anthony
I can confirm that the problem for the given stream also exists when running the script from home
regP