This issue is caused by the new NMBS systems not providing this data for the past anymore, requiring a fallback to parsing the website for liveboards in the past. This has always been lacking certain details, but at least the trains should show up correctly. I noticed the NMBS seems to have a new webpage for this, will see if I can adjust the fallback to be more reliable.

Even https://www.belgiantrain.be/nl/travel-info/current/search-by-station does not really search in the past, so it seems like more work is needed on the iRail side to compute these results ourselves, for example based on their GTFS/GTFS-RT feed. That feed is missing information such as platforms, but it's quality may hopefully be sufficient for historic data.

There is already a linked connections feed for the NMBS GTFS/GTFS-RT data on graph.irail.be, which should allow to consume the data in an easier way.

Ok that's clear. I guessed it has something to do with the new NMBS systems. The most important reason that I opened this ticket that it worked fine the past couple of months, but since a few weeks not.

The old variant is still available (halleluja), because the new variant is really a mess for filling in the compensation form. http://www.belgianrail.be/jp/nmbs-realtime/query.exe/nn?HWAI=VIEW!view=realtimeinfo

Pushed a possible fix to staging.api.irail.be, could you check if the data is correct, or at least better? Please search back at least two hours in the past, otherwise you might still get a response from the "new" source which doesn't handle historical data that well (now you only get data from the fallback if the new one fails, this should probably be replaced by a cutoff based on the queried time)

Thanks! Seems to work for now! I get a lot more trains now in the staging api!Could this be implemented at a later stage in the hyperrail app too?

The fix has now been rolled out to production as well. Any apps querying in the past will benefit from this, as the whole fallback datasource logic is implemented on the server side. Leaving the issue open in order to improve the "failover" logic so the iRail API picks the best datasource for requests in the near past (typically between 1 minute and 1 hour in the past)