Re: [Discuss-gnuradio] self.set_min_noutput_items() is not a valid python command in gnuradio ?

[Activecat]

Dear Marcus,

> 2). Regarding the returning 0 issue, let me share my experience of
> experiments. I am creating a custom interpolation block with its
> interpolation factor can be changed on the fly.  Hence it is
> inherited from gr::block.  It has one input port and one output
> port. During runtime, there will be no problem if the
> general_work() return 0, provided it consume a non-zero value. The
> flow graph may become unresponsive when the general_work() return 0
> and consume zero.
>
> My explanation: Says, the instantaneous interpolation factor is
> 800. The general_work() is now called with noutput_items=699 and
> ninput_items[0]=3. In this case the only correct thing that
> general_work() should do is to consume 0 and return 0.
>
> But later the general_work() will be repeatedly called again with
> the same arguments, i.e. noutput_items=699 and ninput_items[0]=3.
> In this case again the general_work() has to consume 0 and return
> 0.  This may repeat few thousand rounds, or infinite rounds. When
> this happens the flow graph becomes unresponsive (hang).
>
> That's why it is important to set_min_output_items() to the
> instantaneous interpolation factor (which is 800), if the
> set_output_multiple() doesn't work on the fly.
>
> If there is no better workaround, we have to stick to this trick at
> the moment.
>

Hm, I'd call this a bug, iff (!) your forecast does everything right.
Can you confirm?

This problem happens because general_work() is called with noutput_items  equals to a value less than d_iFactor.

So we need to do something to handle the noutput_items, not the ninput_items[].

Hence, the issue is not with the forecast() because forecast() only affects ninput_items[].

Note:

d_iFactor is the instantaneous interpolation factor of this custom block.