I tested two different options while running HTSeq-Count, `-s no` and `-s reverse`. This are the results:

For `-s no`:
> __no_feature	435592

> __ambiguous	953159

> __too_low_aQual	0

> __not_aligned	0

> __alignment_not_unique	8164048

For `-s reverse`:
> __no_feature	573728

> __ambiguous	410510

> __too_low_aQual	0

> __not_aligned	0

> __alignment_not_unique	8164048

For the option `-s reverse` there are lower ambiguous values but higher no_feature than for `-s no`.
As far as I know this option depends on the construction of the library, but when they gave me this sequences they didn't mention it. All I know is that it's was constructed under a Illumina protocol and that it was a Paired-End experiment of RNA-Seq from peach (Prunus persica).
I'm inclined to think that less ambiguous values are just better, even than with more no_feature values.

So, which one it's right?

===============

Edit:
This are the results from `-s yes`:
> __no_feature	41467373

> __ambiguous	506

> __too_low_aQual	0

> __not_aligned	0

> __alignment_not_unique	8164048
This is a pretty common method to determine the strandedness of a library and is essentially what RSeQC is doing. In this case, `-s reverse` is the correct setting (it's also the majority of what's produced these days). The general reasoning is:

 1. If it's an unstranded library, then each of the stranded methods will have ~2x more `_no_feature` counts than the `-s no` setting.
 2. If it's a stranded library, one of the stranded setting will have "slightly" higher `_no_feature` counts (because reality is annoying like that) and the other will have vastly higher `_no_feature` counts.