开云体育

@Richard I know that you were not trying to suggest one should use the same numerical ids for different request types. I just wanted to add another reason why one should not do it. Looks like we

I request live data with generic ticks set to RT Trade Volume (#375) which returns a trade volume string in addition to the regular default tick data (bid, ask, size etc).? ?Lately I've been getting

I never got a first nextValidID? < 100. Got things like "117", why ? never look at the why, I don't know of any zombie process and it works, so ... Your absolutely right, rules are more relax, and I

thank you for the clarification. Gives me a better handle on what's going on. I'm going to rationalize my data approach in 2024 as I have MANY experimental scripts ( python, julia, and now mojo) which

Good luck with log reading. I hope it helps you find the root cause. I removed lots of log detail in the hope that would make things clearer, but apparently it did not. To summarize the log one more

thank you AGAIN for such a detailed analysis.? I have turned on the HMDS logging feature for extra detail, thanks again for the heads up.? I am always a little nervous when there is a hint of data

You are welcome. Generally, IBKR has relaxed historical data pacing rules over the years, but in the spirit of "did something change", here a couple of observations. This is "thin ice territory" in

Jürgen I wasn’t trying to suggest that one should use the same order ids for different request types, merely that the rules are far more relaxed than Gordon’s post implied. Indeed, what

WOW that's my bad sorry. the last date the program worked was Thu 21 Sep *2023* 02:11:09 AM then the next day Fri 22 Sep 2023 02:11:09 AM CDT? it failed to get any data.? Excellent work Holmes

It's happening again today, about 10 bad ticks already. On further investigation, it's been going on for months but not so bad and I haven't noticed. The bid/ask, realtime bars, depth and historical

comicpilsen, I see you consistently mentioning the date to be 9/20/22. Are you sure that you stopped getting data one year ago? Or am I misunderstanding what the issue is?

thank you Jurgen I just wanted to see if there was any change in the API or Ib's pacing rules. The code wants 1y 1d for about 100 symbols and has been working for about 5 years, all the symbols are

Requesting historical data for a contract with symbol='AAPL', exchange='SMART', currency='USD' and and undefined primaryExchange still work fine for us (tried 1_day bars for the last 100 days). The

I agree with your summary of the requirements for orderIds and requestIds and that they are independent of each other, Richard. From a practical point of view it makes sense to avoid situations where

MktData but the RTV (233) and yes 30 minTicks away. My chart looks like this.? I've rarely even seen 1 bad tick but 10+ in one day is strange. I added a little yellow arrow at the 3 +30 error in

Yes, this happens from time to time after upgrading to a new version (of IBG in my case), on the next day or two. But not consistently, I couldn't notice any pattern..

In a recent thread, Gordon Eldest drew attention to this little gem from IBKR, concerning a new setting supposedly introduced in TWS 10.16+:

Gordon I don’t see anything in the least surprising about the ‘very small number for reqId’. nextValidId is only really relevant for order ids, because of the requirement for them to be

Recently I switched TWS (Standalone 10.19.2d) to Linux (Mint 21.1) and Auto Restart is no more working.? TWS just shuts down. Interestingly, after manual launch next day the <Lock and Exit> settings

fair point about the I / It. The statement should have been. The program has been working for several years without modification and it suddenly stopped working on 9/20/22. I am not asking for anyone