There are a few common issues that have been seen when working with NDS1 and NDS2 using the SWIG clients.
Slow data retrieval when data is on tape. It is simply a slow process to read back data from tape. To help manage expectations the SWIG client will now default to an error state when asked for data that resides on tape. This is not done to prevent access to the data, but to allow the user to resubmit the request with the understanding that data will take a while (you should expect to wait at least several minutes, possibly much longer depending on the load on the tape system).
You can automatically ignore errors caused by data being on tape by setting the 'ALLOW_DATA_ON_TAPE' parameter.
Either by setting the NDS2_CLIENT_ALLOW_DATA_ON_TAPE environment variable to 1 and restarting your analysis job (restarting python, matlab, or octave). On a UNIX type system with bash it can be set as
export NDS2_CLIENT_ALLOW_DATA_ON_TAPE=1, remembering to start the analysis job from that shell.
Or by calling the set_parameter('ALLOW_DATA_ON_TAPE', '1') method on your connection object (In matlab the method name is setParameter not set_parameter).
Data not found due to a gap. This problem is mitigated with the new SWIG interface which allows fetch and iterate requests to survive gaps in the data. In addition the connection object has ability to return availability information.
NDS2 does not recognize my channel. If the data exists, it may be that the NDS2 server is mapping your request to the wrong channel. When a channel is addressed only by its base name it may not be resolved to proper channel. This can happen when there has been a rate or data type change in the epoch you currently using. You may request a channel 'A' expecting it to be at 2kHz, but NDS2 sees two versions of 'A', one at 2kHz and one at 8kHz and NDS2 could pick the wrong one.
There are two ways to help mitigate this. First set an epoch. This can reduce the channel list that NDS2 has to choose from. Use the connection.set_epoch() method.
Second, you can more fully qualify the channel name. Fully qualified names are of the form
basename,type,rate. So you could ask for the 'H1:GDS-CALIB_STRAIN' channel by requesting 'H1:GDS-CALIB_STRAIN,raw,16384' or 'H1:GDS-CALIB_STRAIN,16384,raw'. By qualifying your channel requests you can help reduce ambiguity. In this example there happen to be two H1:GDS-CALIB_STRAIN channels, one 'raw' version which is the archived version for historical data, and the 'online' data which is only useful for streaming live, no history is retained.