Coverage is 0 for the second chunk if the cram file contains two concatenated chunks from the same chromosome.

[Luobiny]

Not sure if this is the issue of Mosdepth or Nim-hts, but when the cram file is generated by concatenating (samtools cat) smaller cram files that are chunks from the same chromosome, the coverage on the concatenated cram file is 0 for other chunks except the first chunk.

[brentp]

Hi, I'd need an example bam that demonstrates this issue to be able to debug.

[Luobiny]

How do I send you the files? They are pretty small, like ~300KB in total.

[brentp]

you can email them to me or add them here to the issue with .gz extension.

[Luobiny]

I emailed you the files, thank you!

[brentp]

hi, this must be a bug in htslib because if you do:

 $ samtools depth -r 1:1-249212864 concate.cram | tail

then you see that the last entry is at position 144852667 but if you do:

samtools depth concate.cram | tail

then the last entry is: 249212864

So, this is not something in mosdepth, it's concat+cram+htslib.

[Luobiny]

Thank you for looking into this issue. Indeed, "samtools depth -r concate.cram" is having the same issue too...