Some RSI calculations are missing on the 1 minute timeframe

[hackcatml]

Describe the bug
When running ta.rsi(close, 14) on a 1-minute timeframe dataset of size 1440, only 1434 RSI values are produced.
However, the correct number of results appears when using a 5-minute timeframe dataset.

To Reproduce
Steps to reproduce the behavior:

1. Download 1m timeframe datasets.
   pyne data download ccxt --symbol "BITGET:BTC/USDT:USDT" --timeframe 1 --from "1"
2. Create a simple Pyne strategy

"""
@pyne

This code was compiled by PyneComp — the Pine Script to Python compiler.
Accessible via PyneSys: https://pynesys.io
Run with open-source PyneCore: https://pynecore.org
"""
from pynecore import Series
from pynecore.lib import (
    close, script, ta, log
)


@script.strategy("my strategy", overlay=True, initial_capital=10000)
def main():
    rsi: Series[float] = ta.rsi(close, 14)
    log.info("rsi: {0}", rsi)

3. Run the strategy
   pyne run test ccxt_BITGET_BTC_USDT_USDT_1.ohlcv

4. Observe the bar index
   The final bar index is much lower than the number of rows in the OHLCV file.

Expected behavior
RSI values should be generated for every bar in the dataset.

Screenshots

• OHLCV file size

• pyne run command result

• Missing calculations
  e.g., 2025-11-14 17:18:00+0000

Environment:

• OS: macOS
• Version: (e.g. Ubuntu 22.04, Windows 11)
• Python version: 3.11, 3.12, 3.13
• How you ran the script: pyne run

Additional context
I tested this issue using the latest pynecore commit.

[wallneradam]

Thank you for taking the time to report this issue and for providing such detailed reproduction steps! This is really helpful.

After investigation, this is actually expected behavior, not a bug. Here's what's happening:

The Cause: Gaps in the Data

The Bitget API doesn't return data for every minute - there are periods with no trading activity. When we downloaded the same data you used, we found:

• Total records in OHLCV file: 1440
• Real bars (with trading): 1434
• Gap bars (no trading): 6

The gap timestamps (no trading activity from Bitget):

2025-11-25 14:20:00 UTC
2025-11-25 17:41:00 UTC
2025-11-25 21:02:00 UTC
2025-11-26 00:23:00 UTC
2025-11-26 03:44:00 UTC
2025-11-26 07:05:00 UTC

How PyneCore Handles This

1. When converting data to OHLCV format, PyneCore fills gaps with volume=-1 (a flat candle with previous close price)
2. When running scripts, these gap bars are skipped by default (skip_gaps=True)
3. This matches TradingView's behavior - they also skip bars with no trading activity

Why This Is Correct

Calculating RSI (or any indicator) on a "fake" bar with no real price movement would produce misleading results. The 1434 RSI values you're seeing represent all the bars where actual trading occurred.

How to Verify

You can check for gaps in your OHLCV file:

from pynecore.core.ohlcv_file import OHLCVReader

with OHLCVReader("your_file.ohlcv") as reader:
    gaps = sum(1 for ohlcv in reader if ohlcv.volume < 0)
    print(f"Gap bars: {gaps}")

---

Note: We're converting this issue to a Discussion, as we found it valuable for other users who might encounter the same situation. Thanks again for bringing this up!

[hackcatml]

Thanks for the clarification.

But it’s strange, when I check the chart in TradingView, there's no flat bar where the data’s volume is –1.
I think the 1 minute timeframe downloaded data is a bit unreliable.

By the way, shouldn’t the bar index still increase? The time and bar index don’t match if some bars are skipped.

[wallneradam]

The volume -1 is just a placeholder. This makes he OHLCV format extremely fast. Because there are no gaps in it, it is always easy to calculate where a data is for a specified datetime.
On TradingView these bars are hidden. Also PyneCore just skips these bars. The results are the same. And no, when there's no new data, it is actually not a bar. It is the behavior of TV and all other exchanges too.

[hackcatml]

Thanks, I completely understand now!

[hackcatml]

@wallneradam Hey, I understood how Pynecore handles gaps.
But I couldn’t understand why a large exchange like Bitget was producing six gaps, so I investigated the issue a bit more.

Bitget has the following behavior when downloading the ohlcv data:

• If the number of 1m bars returned equals the limit, then can get candles starting from since + 1m timestamp
• If the number of bars returned is less than the limit, then can get candles starting exactly from the since timestamp.

For example:

• When requesting with since = 1764271140000 and limit = 200,
  the total candles returned are 200, and the first candle’s timestamp is since + 1m (60000) = 1764271200000.

• But when requesting with since = 1764328500000 and limit = 200,
  the total candles returned are 56 (less than the limit), and the first candle’s timestamp is the same as since = 1764328500000.

So this is why gaps occurred when downloading 1m data from Bitget.

After receiving the first 200 candles, the function download_ohlcv sets
tf = dt + timedelta(minutes=1)
which means the next since becomes the timestamp of the 201st candle.

But since the limit is 200, the next batch starts from since + 1m, which is the 202nd candle.
As a result, the 201st candle gets recorded as a gap.

This is why a gap appeared every 201st candle (60 * 201 = 12060 seconds).
e.g., 1764258000 + 12060 = 1764270060
1764270060 + 12060 = 1764282120