2024 Ticket Buying Tips

[Huddy123]

7 minutes ago, efcfanwirral said:

That mentions this 60+ per minute thing as potentially pushing you to a separate page. To know this from their experiments, they must have some sort of identifier, most likely within Chrome Devtools, that tells them when this has happened. Which should mean we can monitor it as we go along, but I haven't seen anyone explain how they've found this out?

I think it's just based on the fact that if you go to glastonbury.seetickets.com right now and hit F5 61 times, it takes you to a fake holding page. It would be very handy to know whether you're on the fake page or not on the day, but I'm not tech literate enough to know how you would do that. 

[efcfanwirral]

6 minutes ago, Huddy123 said:

I think it's just based on the fact that if you go to glastonbury.seetickets.com right now and hit F5 61 times, it takes you to a fake holding page. It would be very handy to know whether you're on the fake page or not on the day, but I'm not tech literate enough to know how you would do that. 

yeah I'm wondering if there is a differentiation between that and the "real" one 

[Huddy123]

15 minutes ago, efcfanwirral said:

yeah I'm wondering if there is a differentiation between that and the "real" one 

Just looking myself and you do get a 'too many requests' error when the fake page loads. Not sure if this would be the same in the real sale. 

[efcfanwirral]

10 minutes ago, Huddy123 said:

Just looking myself and you do get a 'too many requests' error when the fake page loads. Not sure if this would be the same in the real sale. 

Nice one that looks like the sort of identifier to look out for. I'll keep the console open during the sale just in case!

[parsonjack]

4 hours ago, briddj said:

I just don't see the limit thing.

I have 7 browsers refreshing at 2 seconds across 3 devices, all just on the house wifi, and have got tickets in the last two sales.

All we know for sure is that there is some sort of limiting, in which IP plays a part and seems to be triggered when 60 hits/minute is exceeded.  That's not to say it is solely IP based, as that would put folks on shared wifi at a massive disadvantage, so there is something else in play to mitigate that.  Best guess is that See's load-balancing plays a part, where hits are shared in turn across See's servers, and in some fashion minimises the chance of a single (shared) IP breaching the limit.

It's guesswork, with a bit of fact thrown in, but a limit of some sort does exist.  Your setup generates 3.5 hits/second on a single IP.....over 3 times the limit.....there's nothing to prove or disprove that many of the holding pages you see aren't the 'fake' one, but if you've got tickets using it then at least some of your hits must have got through at exactly the right point to nab a free session.

[Festival Sounds Podcast]

Tried to condense the basics into an episode 

[Oscr]

I read that if you log in to separate users in Chrome those are treated as new sessions, so I have a technical question - if I do this on a PC and a Laptop with 2 users are those considered as 4 sessions? (potentially 6 sessions if using a private window too)

[t0paz]

3 hours ago, Oscr said:

I read that if you log in to separate users in Chrome those are treated as new sessions, so I have a technical question - if I do this on a PC and a Laptop with 2 users are those considered as 4 sessions? (potentially 6 sessions if using a private window too)

The best advise with any method you’re thinking of trying is to try it now, well ahead of the sale. If you hammer F5 on Glastonbury.seetickets.com now and breach the 60 hits per min you’ll get the busy message. Test your method and see what happens. If it doesn’t block now there is no reason it will on Thursday or Sunday.

[discgoesmic]

On 10/26/2023 at 4:49 PM, parsonjack said:

All we know for sure is that there is some sort of limiting, in which IP plays a part and seems to be triggered when 60 hits/minute is exceeded.  That's not to say it is solely IP based, as that would put folks on shared wifi at a massive disadvantage, so there is something else in play to mitigate that.  Best guess is that See's load-balancing plays a part, where hits are shared in turn across See's servers, and in some fashion minimises the chance of a single (shared) IP breaching the limit.

It's guesswork, with a bit of fact thrown in, but a limit of some sort does exist.  Your setup generates 3.5 hits/second on a single IP.....over 3 times the limit.....there's nothing to prove or disprove that many of the holding pages you see aren't the 'fake' one, but if you've got tickets using it then at least some of your hits must have got through at exactly the right point to nab a free session.

My best guess would be MAC address as it’s entirely possible to see over IP. Just a note, I used a tool with over 60+ requests per minute last year and it worked like a charm.

My view on the holding page when refreshing the site on non ticket days is this probably just triggers the holding page to display to facilitate perceived traffic.

[incident]

22 minutes ago, discgoesmic said:

My best guess would be MAC address as it’s entirely possible to see over IP.

MAC addresses are not transmitted over the public Internet, nor are they visible from behind NAT.

[Pinhead]

27 minutes ago, incident said:

MAC addresses are not transmitted over the public Internet, nor are they visible from behind NAT.

Correct.

They are all programmable now anyway so it doesnt mean what it did years ago when they were all hard coded to the ROM of the adaptor.

[Pinhead]

Shared WIFi - be mindful of this. See may consider the cumulative hit rate.

Remember See dont give a sh*t about being 'fair' to every technical circumstance or set up. Their remit is to sell tickets. If they are a bit unfair here and there it means nowt - they'll all sell regardless.

[discgoesmic]

47 minutes ago, incident said:

MAC addresses are not transmitted over the public Internet, nor are they visible from behind NAT.

Ah yes, I was thinking of LAN. Carry on! 

[Mich1268]

I have made up a Google sheets doc with reg numbers and postcodes. Does this even work for auto fill in? I am such a luddite have no technical know how whatsoever 

[2019]

17 hours ago, discgoesmic said:

Ah yes, I was thinking of LAN. Carry on! 

I think each local connection is assigned a port by your router. What see tickets get is your nat address and this port number so it can return data to the correct user or process. I'd suspect any throttling is based on this socket address. Hence multiple users sharing them same campus connection should not be subject to a group throttle.

[Traci]

Hi 

If you’ve got a few people trying for tickets for your group and one of them isn’t going , do they have to buy tickets through a See Ticket account of someone that’s going or can they log into there own , but use the registrations of those going ? 
just wondering if they need to have See log in details of one of the persons going 

Thanks in advance 😀

[incident]

Just now, Traci said:

Hi 

If you’ve got a few people trying for tickets for your group and one of them isn’t going , do they have to buy tickets through a See Ticket account of someone that’s going or can they log into there own , but use the registrations of those going ? 
just wondering if they need to have See log in details of one of the persons going 

Thanks in advance 😀

There's no accounts or logins used. Anyone can make a purchase, as log as they have the reg numbers and postcodes for the (up to) six people who want tickets.

[parsonjack]

2 hours ago, 2019 said:

I think each local connection is assigned a port by your router. What see tickets get is your nat address and this port number so it can return data to the correct user or process. I'd suspect any throttling is based on this socket address. Hence multiple users sharing them same campus connection should not be subject to a group throttle.

Thankyou for this.  I think this corroborates a theory that the rate limiting applied by Seetickets is per IP Address, but isn't an issue for shared wifi as the port number differentiates between connections using the same source IP.

It still means that more than 60 hits/minute by a single *device* will breach the limit as the port number remains the same for each request on that https connection.

[Traci]

2 hours ago, incident said:

There's no accounts or logins used. Anyone can make a purchase, as log as they have the reg numbers and postcodes for the (up to) six people who want tickets.

Thank you ☺️

[2019]

5 hours ago, parsonjack said:

Thankyou for this.  I think this corroborates a theory that the rate limiting applied by Seetickets is per IP Address, but isn't an issue for shared wifi as the port number differentiates between connections using the same source IP.

It still means that more than 60 hits/minute by a single *device* will breach the limit as the port number remains the same for each request on that https connection.

I think Https (TLS) multiplexes/tunnels common connections to the same destination, so multiple tabs in the same instance of browser will be subject to a single throttle.

What has made me smile, the company that makes the load balancers for most of the internet, and probably is where the throttle is enforced is called 'F5'. Coincidence or are they sadists?

[prestonmanc]

I've added autorefresh.io for Chrome today in preparation.  Techy question - do I need to opt for a 'hard refresh' of the page for it to be effective? I seem to vaguely remember reading something to this effect a while back but can't find any reference to it now.

From autorefresh.io - 'Hard refresh - reload the page without relying on cached data'

Cheers

[aj6658]

On shared wifi. I live in a big ten man house which has multiple routers. 

If the different routers have different IP addresses does that mean it mean each router has its own cumulative hit rate or do we still have as a whole one cumulative  hit rate. (i.e. we should spread out people on each router) 

[prestonmanc]

Second question of the day from me (sorry), this time on international tickets.

Ticket info site says:

UK Tickets can be purchased with a UK debit card or Visa or Mastercard credit cards.

International Tickets can only be bought by Visa credit card or Mastercard credit card.

I'm interpreting this as meaning that if 1 of the 6 in your group lives abroad (and is registered with a foreign post code), you'd need to use a credit card for the whole transaction to go through, as the international ticket requires a credit card payment.

OR, do we think a UK debit card is OK for all tickets and the point being made is that non-UK debit cards can't be used?

Essentially, can you use a UK debit card to buy a mix of UK and international tickets in one transaction?!

[t0paz]

8 minutes ago, aj6658 said:

On shared wifi. I live in a big ten man house which has multiple routers. 

If the different routers have different IP addresses does that mean it mean each router has its own cumulative hit rate or do we still have as a whole one cumulative  hit rate. (i.e. we should spread out people on each router) 

Are you sure it had multiple routers and not just multiple WiFi access points? If you pay one single bill for internet access then you likely have one router and therefore one IP between you.

A simple check is to go to https://www.whatismyip.com/ from the different access points and see if you have the same IP.

[2019]

12 minutes ago, aj6658 said:

On shared wifi. I live in a big ten man house which has multiple routers. 

If the different routers have different IP addresses does that mean it mean each router has its own cumulative hit rate or do we still have as a whole one cumulative  hit rate. (i.e. we should spread out people on each router) 

I'm not an expert, but I suspect that your house only has one router, which is the box connected to the telephone line/fibre/coax coming into your house. The other boxes are access points to the WiFi to improve connectivity. Imho the hit rate is specific to each users connection, rather than the house, but this is just my view.

Edited October 30, 2023 by 2019
Typo