TommyT

@charlie303, in case your interested in keeping any c# code that uses v2 authentication: I took teebeast's new project with v3 session auth and the 5.0.5 LS and I swapped out the v3 session auth and replaced it with a v2 session auth: Lo and behold the LS connect worked fine. Seems the 5.0.5 LS is the key to the broken link. Regards TommyT

@charlie303, I would agree that some Friday night maintenance has implemented some breaking changes to LIVE lightstreamer, but I am not convinced is a V3 issue. My feeling that is may be some setting of a connection option....possibly inaccessible or unsupported in the LSClient and ConnectionInfo props Is this c# conversion to V3 authentication something you have got working for lightstreamer connection.? I note that (by using browser dev tools) the streaming companion uses V1 authentication and passes a basic CST/XST password token. This fits with mf2's opening of the connection " Authenticate with the REST api via a V3 session call Issue a V1 session call to get the XST and CST token Send the following HTTP POST request to the lightstreamer server, at `/lightstreamer/create_session.txt`: " regards TommyT

@chalie303, LIVE LightStreamer: same thing has happened to be since 14 May. I cant now connect, though I have been connecting fine, everyday for the last 2 months. This is too much of a coincidence that it happens to both of us at the same time. Regards TommyT

Hi Funky, I was using the LS dot net Client dll. it supports calls to "connect" and "disconnect" which is pretty opaque. I did not/could not find the level of detail you found (error.public-api.exceeded-api-key-allowance) . It seems to confirm it, though am not sure how the streaming companion escapes this limit even though it uses the same API key and account regards Tom

Wall Street, 10-Feb-2022 17:45:22 - 17:45:30 Today the IG chart data has a gap in that period, but yesterday there was data there. ( How do I know? - because I closed a spread bet in that period and then saw it was given a strange closing price, so I looked at the data). In this period and a few seconds before there was high volume trading and a substantial market drop. At the time I reviewed this in the live chart and I could see 1sec interval data for each second of that period. It was there yesterday but today I look and its gone ??? I also trade using the API and get tick prices from the stream. I write that data to file. In that period I got 49 ticker updates, so there was price info available, just I as the chart showed at the time. I also downloaded ticker data from Dukascopy and the data is there also. Can anyone explain where this data has suddenly gone or why IG charts do not have it but others do? There is in fact a even bigger gap soon after and duckascopy also has data while IG does not. The reason I have focused on 17:45:22 - 17:45:30 is that closed a position at 17:45:29, and yet the closing price applied was "rewound" to that for 17:45:22. The ticker data says the price had moved in 46 points, so I lost 46 points on the bet Regards Tom

Hi Swingwin (and other contributors), I too had a similar problem with the DEMO stream, however my timings were different. I had no issues in December but started to get the same issues as you in early Jan. At the same time as I had connection issues with DEMO, the streaming companion on demo worked fine, and the same code DotNetClient_N2 connect to LIVE stream worked fine There are other posts on the forum where others state it has happened to them, but during different periods. Given it seems to affect different people at different times, and those people seem to be using it then it suddenly stops for a while, I am beginning to wonder if this is down to the stated data limit. “40 concurrent subscriptions”. I wonder if, when an application has the stream up and is killed during testing/debugging, does it leave the subscription count incremented? This would seem to explain why different people get it at different times. If then at some point the count is reset access comes back – which it seems to. And this would also explain why it mostly happens with DEMO. (I have had it happen on LIVE too when I have had to use LIVE when DEMO was not available) A natural counter to this would be that if this is the case it should block the companion connection too. However, I used F12 dev tool on the browser to look at the mechanism for connecting the companion. From what I can tell there is a slight difference in the login request headers in the PUT to /gateway/deal/session The c# code I have adds X-IG-API-KEY and VERSION as default headers, and Content-Type as custom to that request particular, whereas the companion uses req.headers = { "X-IG-API-KEY": credentials.apiKey, "Content-Type": "application/json; charset=UTF-8", "Accept": "application/json; charset=UTF-8" }; Not sure what “Accept” is doing. Regards Tom

Casey, Thank you for all your input on this - much appreciated. As "free" streams go IGs is quite good. I make the assumption that the integration into MT4 uses this stream, as the correlation to tick count is so exact. I just wish MT4 took advantage of better features of the stream. Perhaps my assumption is wrong and MT4's feed is generic which is independent of the underlying broker There is some rough correlation between tick volumes and trade volumes but it is far from a linear scalar and diverges even further at higher volumes, when the market is more volatile. For this reason I disregard it I have looked at other feeds and the best I could discover in terms of content was dxFeed, though like many other similar broker-oriented feeds it is too expensive for me given the base+exchange increment price structure. Of the free or "inclusive" feeds, I think there are none better than IG's so I will happily use the IG feed, though I will be using the REST access. The sample app is very useful once one sorts the 3rd party package updates. Regards Tom

Casey, From viewing the IG stream it appears that, for FX, the tick_count and LTV are the same value. This confirms that in MT4 indicators, for both FX and indices, the volumes are equal to the tick_count. Ludwig' response explains why FX uses tick count, but indicies can have a better, calculated LTV. Ludwig makes no reference to MT4. I would infer that IG/MT4 feed had been poorly implemented to used the tick_count rather than LTV. For FX this is trivially equivalent but for indicies, this is sadly deficient. I will not be using MT4. regards

Casey, Thank you for your response I was looking at indices - ftse100 specifically by way of example. I will check the same for FX and report what I find in that case too Regards

The values of the volume indicator in the IG charts and the MT4 charts are different - they are not the same values and they are not even a scalar proportion of each other So where is IG getting is volume and where is MT4 getting its volume? Using the IG Streaming Companion tool one can see the various field values in the" Chart" data items of the stream Comparing this stream to the IG chart I can see that IG chart's volume is equivalent to the stream's LTV - last traded volume doing the same for MT4 I can see that the MT4 chart's volume is equivalent to the stream's LTV CONS_TICK_COUNT - tick count Given that IG's own chart presents the LTV as the volume, it would seem that this is the preferred measure, and I have to agree. On that basis, I would say MT4 is using the wrong value I would like to use MT4 to trade, but I don't like tick-count-as-volume. Is there anyway via the MT4 configuration or custom code that I can get hold of the LTV volume. Does anyone at IG know if the LTV data in MT4's tick variables so that I might be able to build my own indicator?