Ok, so point 9) seems to match my assumption in the previous post.
But operating on the client side to reduce the updates of candlestick data to only the ones related to candlestick close seems impossible to me. For sure, you cannot achieve that by leveraging LS_requested_max_frequency.
I think that your only possibility is to:
  • subscribe normally and read all updates,
  • keep the state of the current candlestick by integrating the updates,
  • however, whenever an update carries a new timestamp value, save the previous state as a full candlestick and clear the state to prepare for the next candlestick (but the incoming update should itself take care of the clearing).

I cannot understand point 10), but it seems just a reinforcement of point 9).

I also can't understand point 11). So far, the problem seems that, in streaming API you get more lines than needed, not fewer.
Perhaps you mean that if you cannot satisfy point 9) you have to give up subscribing to candlesticks and subscribe to ticks only and use the ticks to build the candlesticks yourself on the client side. Guidance on this is obviously out of our scope as Lightstreamer support.