Get Fixtures : Questions/suggestions

[Eliakos]

Hello,

From a call of Get Fixtures, is it possible to get :

• Only live events? ie with LiveStatus <> "NoLiveBetting". Or asked differently, LIVE_STATUS can have 3 values : 0, 1 and 2, respectively for "No live betting will be offered on this event", "Live betting event", "Live betting will be offered on this event". Can we pass this LIVE_STATUS parameter somewhere to get the related events corresponding to the LIVE_STATUS given value?

• Only events with odds, ie as it is possible that the event is in Get Fixtures response but not in Get Odds, can we pass a parameter in order we have in the Get Fixtures response only events for which odds have been set? (and only Straight Odds for example)

• Events sorted by date (for example from events the closest in time to the ones that are most distant in time)

[Eliakos]

Are these subjects actually possible with the wrapper or do we have to add some code managing this stuff? Would you have a code example of what is possible in the context of the wrapper related to these questions?

Thanks in advance

[harveysburger]

Hey, so about the sorting it s bets you handle that on your end after getting the results.

The fixtures feed returns all fixtures including those without any lines. That's how the pinnacle/ps3838 Api work and the wrapper is just mirroring that. In the past I had to do my own filtering there, basically I get the lines first, then get the fixtures then remove from the fixtures any if them that didn't have lines... Or some other filtering of the sort.

As for is Live, there is 3 values but really values 0 and 2 should be considered the same . If you want live data then check for IsLive == 1, is you want pre-game look for IsLive !=1

The underlying API (and as such the Wrapper as well) don't support querying for live fixtures only or pre-game fixtures only, you have to filter the data on your end.

Once you do the initial call it s important to provide the "since" parameter for subsequent calls. If you do that the volume of data on every call won't be that big so any sort of filtering on your end isn't too bad.

Hope this helps

[Eliakos]

Hello Harvey,

I mostly agree on the live parameter. Mostly because i have strategies working on live events, so they work on 1 and 2 values event, but they would fail or success (one or the other does not depend on me but luck) on value 0, this is why the distinction is important. Could that be taken into account in a next release?

In the meantime i find a solution for that as the wrapper seems to catch only the 1 value :), IsLive is defined in GetFixturesRequest, how to make the call? I mean do i add there something like :

public GetFixturesRequest(int sportId, bool isLive, string apiVersion = "v1"); in order to be able to make this call ?: var fixtures = await api.GetFixtures(new GetFixturesRequest(SampleSportId, 1, lastFixture));

Noted about the fixtures / lines sorting / cleaning ... thank you.

[harveysburger]

One thing to understand with the pinnacle/ps3838 data is that if a fixture has IsLive 1, that 1 will ever change to 0 or 2.

Also a fixture with 0 or a 2 will never change to become a 1

However a fixture with a 0 value may be updated to 2, or one with 2 could be updated to 0. Going from 2 to 0 seems rare but from 0 to 2 is fairly common. So don't discard permanently fixtures with 0 as they may turn into 2 later.

[harveysburger]

As for supporting 3 state in the method, I'll check but the underlying Api might not support that so the Wrapper will have to query all fixtures and filter out locally if you want let say only status 1 and 2 but not 0. Ill check later, haven't coded in there in some time

[Eliakos]

Yes, that would be great Harvey the wrapper support all the api features in general

Yes, IsLive 1 never going to the other values is logic. 0 never going to the other values is logic as well. 2 never going to 1 is not logic but that's not a big deal and it also does not disturb me as my strategies are happy whatever with 1 or 2 values, 0 is the problem for me when it occurs and missing the 2 value is a pitty as i would lose some events and related profits.

More disturbing is a 0 value may be updated to 2, as "No live betting will be offered on this event" explicitly and clearly says it can't become a 1 or 2. Also one with 2 could be updated to 0 is a problem as you can have a strategy working for "Live betting will be offered on this event" which would be transformed into the non sense "No live betting will be offered on this event" just like if words have no meanings... for me it's as mad as you watch a soccer event which, during play is transformed into a tennis event, i never saw a tennis event with 22 players on the field and 22 balls :)

[harveysburger]

The reality is bookmakers are depending on external feeds to get InPlay game events, and it s not always clear at the time of a fixture being created whether or not an InPlay feed will be available, so the process of creating a fixture and the process of determining whether or not the thing will be offered live is often separate

I don't really see things go from 2 to 0, not sure if it happens in practice

From 0 to 2 you ll see that often however, for reason explained above

[Eliakos]

So your advice is to not filter at source but to retrieve all events and inspect the live value to filter "locally" (at information retrieval)?

[harveysburger]

The thing is we wouldn't be filling at the source, in order to get only 1 and 2 the wrapper will have to retrieve all fixtures from the api and filter the 0 out after, so either way the filtering will be done locally not at the source.

I don't mind expanding the wrapper but I'd suggest you just filter the 0 on your end.

[Eliakos]

Ok, I will do that and if you agree/ allow me to, i prefer to annoy you (as little as possible) on understanding the wrapper for example by having some code examples which saves much time into learning the wrapper. This saved time helps a lots into focusing on the extra work to do ourselves.

Is that possible? I mean code examples (for all geatures provided by the wrapper) and how to modify parameters values used by methods. This would also minus the number of questions to submit to you.

[Eliakos]

Hello Harvey,

You mentioned "Once you do the initial call it s important to provide the "since" parameter for subsequent calls. If you do that the volume of data on every call won't be that big so any sort of filtering on your end isn't too bad."

Let's take SampleCodeApp example :

                var fixtures = await api.GetFixtures(new GetFixturesRequest(SampleSportId, lastFixture));

                var lines = await api.GetOdds(new GetOddsRequest(fixtures.SportId,
                    fixtures.Leagues.Select(i => i.Id).ToList(), lastLine, false));

"since" is represented by 'lastFixture" and "lastLine" here, correct? sa lastLine is the third parameter we can find as "since" in the class GetOddsRequest.

Also, if we use that in a loop, we would have to :

• retrieve all fixtures first by several calls to GetFixtures
• then retrieve "all lines" by several calls to GetOdds. In fact we should never get "all lines" as the server will almost always provide us new odds for the retrived fixtures, no ?

But then we just repetively collect new odds for the retrieved fixtures so if we want to cover new sport events, we would have to call GetFixtures again without the since (then followed by calls with since). When do you identify this need? you do it after a delay you define or because the server tells you you're at the end of the fixtures list you could retrieve after your calls with since parameter?

[Eliakos]

Hi, Just a detail but in the ps3838 doc, LiveStatus, as discussed, has values from 0 to 2. In the wrapper, i see instead "NoLiveBetting", "GoingLive" and "Live"