fetch does not work properly on CRAM files when multiple_iterators is True

[nspies]

CRAM files do not apparently work properly when used with cram.fetch(..., multiple_iterators=True). Using the examples from the tests/pysam_data directory and the following test code:

import pysam

def test_fetcher(fetcher):
    print(next(fetcher).reference_name)

chrom = "chr2"
start = 200
end = 2005

# these all work
bam = pysam.AlignmentFile("pysam_data/ex1.bam")
test_fetcher(bam.fetch(chrom, start, end))

bam = pysam.AlignmentFile("pysam_data/ex1.bam")
test_fetcher(bam.fetch(chrom, start, end, multiple_iterators=True))

cram = pysam.AlignmentFile("pysam_data/ex1.cram")
test_fetcher(cram.fetch(chrom, start, end))

# this one does not
cram = pysam.AlignmentFile("pysam_data/ex1.cram")
test_fetcher(cram.fetch(chrom, start, end, multiple_iterators=True))

I get the output:

chr2
chr2
chr2
chr1

Where I'd expect all the results to be chr2. It appears that the fetch on the cram file is starting from the beginning, rather than the specified coordinates.

I'm using the latest version of pysam from github. I'm not sure exactly what's going on in #293, but this may be a related issue.

[AndreasHeger]

Thanks for the nice test case, something is clearly wrong.

[AndreasHeger]

The reason is: when using multiple iterators I use the same index across the iterators. This works for BAM, but not for CRAM. Not sure I fully get all the details, but it looks as if while setting up the query, options are set, for example in cram_itr_query():

cram_range r = { tid, beg+1, end };
int ret = cram_set_option(cidx->cram, CRAM_OPT_RANGE, &r);

A solution is to provide each iterator with its own index.