Ticket tips and Tricks for 2025 festival

[paulshane]

Just now, Crazyfool01 said:

We streamed it on here via zoom to @squirrelarmy tv. 😂 where he was able to get it . I had to ask people to be silent when they joined the zoom call 🙂 

 

ace 😄

[LOWERCASE GUY]

I've been lurking here for a while now, but have noticed something that I don’t think has been mentioned in this thread yet which may suggest a queue is likely to be used this year.

 

www.seetickets.com and glastonbury.seetickets.com normally use the See Tickets native servers: either the 5 ‘main’ servers 31.221.2.88/89/90/91/92; or the 3 ‘other’ servers 167.98.233.88/89/90 (those of you who remember the hosts file hack from last year should be familiar). However, if you open a command line and run either ‘ping glastonbury.seetickets.com’ or ‘nslookup glastonbury.seetickets.com’ the IP addresses returned will not be any of those servers. I can’t tell you exactly what servers you’ll get returned as that’ll depend on exactly where you are located. This happens because glastonbury.seetickets.com is now hosted on Akamai edge servers, which means you connect to an Akamai server close to your location and that server in turn connects to the native See Tickets servers. You can verify the location of the server you’re connecting to by searching for the IP location using e.g.: https://dnschecker.org/ip-location.php

 

This change, as far as I can tell, happened on Tuesday last week. More interestingly, while the main See Tickets webpage www.seetickets.com remains on the 5 main servers, the dedicated subpage for the Sam Fender ticket sale samfender.seetickets.com was also put onto these Akamai edge servers, which ended up using the Queue-it system. So as the Glastonbury subpage was put onto these Akamai edge servers around the same time as the Sam Fender subpage was also put onto them, and as Akamai are in partnership with Queue-it (see https://www.akamai.com/resources/partner-story/queue-it) I’m currently considering the use of a queue as likely.

 

A further option they could utilise to make the queue “fairer” would be to tokenise access to the queue. This would probably work by emailing each registrant (after registration closes) a unique code to access the queue, this would limit each registrant to one place in the queue and prevent the use of multiple browser sessions to get multiple places in the queue. They didn’t do this for Sam Fender, so it would be a first for See Tickets, which makes it perhaps unlikely, but something to be aware of.

[balti-pie]

i love it, but i have absolutely idea what any of it means really. Im going to try and memorise bits of it so i can say it to other people when they talk to me about glasto tickets, and then i can appear smarter and more in the know 

[Crazyfool01]

I’m confused … have just slept on it but things are no clearer … sounds good as an early post though 

[parsonjack]

2 hours ago, LOWERCASE GUY said:

I've been lurking here for a while now, but have noticed something that I don’t think has been mentioned in this thread yet which may suggest a queue is likely to be used this year.

 

www.seetickets.com and glastonbury.seetickets.com normally use the See Tickets native servers: either the 5 ‘main’ servers 31.221.2.88/89/90/91/92; or the 3 ‘other’ servers 167.98.233.88/89/90 (those of you who remember the hosts file hack from last year should be familiar). However, if you open a command line and run either ‘ping glastonbury.seetickets.com’ or ‘nslookup glastonbury.seetickets.com’ the IP addresses returned will not be any of those servers. I can’t tell you exactly what servers you’ll get returned as that’ll depend on exactly where you are located. This happens because glastonbury.seetickets.com is now hosted on Akamai edge servers, which means you connect to an Akamai server close to your location and that server in turn connects to the native See Tickets servers. You can verify the location of the server you’re connecting to by searching for the IP location using e.g.: https://dnschecker.org/ip-location.php

 

This change, as far as I can tell, happened on Tuesday last week. More interestingly, while the main See Tickets webpage www.seetickets.com remains on the 5 main servers, the dedicated subpage for the Sam Fender ticket sale samfender.seetickets.com was also put onto these Akamai edge servers, which ended up using the Queue-it system. So as the Glastonbury subpage was put onto these Akamai edge servers around the same time as the Sam Fender subpage was also put onto them, and as Akamai are in partnership with Queue-it (see https://www.akamai.com/resources/partner-story/queue-it) I’m currently considering the use of a queue as likely.

 

A further option they could utilise to make the queue “fairer” would be to tokenise access to the queue. This would probably work by emailing each registrant (after registration closes) a unique code to access the queue, this would limit each registrant to one place in the queue and prevent the use of multiple browser sessions to get multiple places in the queue. They didn’t do this for Sam Fender, so it would be a first for See Tickets, which makes it perhaps unlikely, but something to be aware of.

The only flaw in the logic is that the new See set up was in place from at least 14th October, when I spotted it myself.  Otherwise the hypothesis could be sound.

[incident]

16 minutes ago, parsonjack said:

The only flaw in the logic is that the new See set up was in place from at least 14th October, when I spotted it myself.  Otherwise the hypothesis could be sound.

 

Yeah, looking at this thread, my post on the subject was on Oct 14th so the change would have been on or probably before then. I wouldn't like to guess how much before as it's not like I was looking at this daily.

Edited 1 hour ago by incident

[Avalon_Fields]

2 hours ago, LOWERCASE GUY said:

A further option they could utilise to make the queue “fairer” would be to tokenise access to the queue. This would probably work by emailing each registrant (after registration closes) a unique code to access the queue, this would limit each registrant to one place in the queue and prevent the use of multiple browser sessions to get multiple places in the queue. They didn’t do this for Sam Fender, so it would be a first for See Tickets, which makes it perhaps unlikely, but something to be aware of.

That would certainly be a significant change. I feel they’re going to have to flag up any such changes soon, or run the risk of many complaints on the day with people not hearing or misunderstanding any new system. I’m not convinced it’ll happen, surely the time to announce changes would have been when the sale date, and supporting details, was released?

[efcfanwirral]

2 hours ago, LOWERCASE GUY said:

I've been lurking here for a while now, but have noticed something that I don’t think has been mentioned in this thread yet which may suggest a queue is likely to be used this year.

 

www.seetickets.com and glastonbury.seetickets.com normally use the See Tickets native servers: either the 5 ‘main’ servers 31.221.2.88/89/90/91/92; or the 3 ‘other’ servers 167.98.233.88/89/90 (those of you who remember the hosts file hack from last year should be familiar). However, if you open a command line and run either ‘ping glastonbury.seetickets.com’ or ‘nslookup glastonbury.seetickets.com’ the IP addresses returned will not be any of those servers. I can’t tell you exactly what servers you’ll get returned as that’ll depend on exactly where you are located. This happens because glastonbury.seetickets.com is now hosted on Akamai edge servers, which means you connect to an Akamai server close to your location and that server in turn connects to the native See Tickets servers. You can verify the location of the server you’re connecting to by searching for the IP location using e.g.: https://dnschecker.org/ip-location.php

 

This change, as far as I can tell, happened on Tuesday last week. More interestingly, while the main See Tickets webpage www.seetickets.com remains on the 5 main servers, the dedicated subpage for the Sam Fender ticket sale samfender.seetickets.com was also put onto these Akamai edge servers, which ended up using the Queue-it system. So as the Glastonbury subpage was put onto these Akamai edge servers around the same time as the Sam Fender subpage was also put onto them, and as Akamai are in partnership with Queue-it (see https://www.akamai.com/resources/partner-story/queue-it) I’m currently considering the use of a queue as likely.

 

A further option they could utilise to make the queue “fairer” would be to tokenise access to the queue. This would probably work by emailing each registrant (after registration closes) a unique code to access the queue, this would limit each registrant to one place in the queue and prevent the use of multiple browser sessions to get multiple places in the queue. They didn’t do this for Sam Fender, so it would be a first for See Tickets, which makes it perhaps unlikely, but something to be aware of.

Great info!

 

And on the last bit... I can see "sorry, bot!" happening as you click on the email link...

[incident]

Just now, Avalon_Fields said:

That would certainly be a significant change. I feel they’re going to have to flag up any such changes soon, or run the risk of many complaints on the day with people not hearing or misunderstanding any new system. I’m not convinced it’ll happen, surely the time to announce changes would have been when the sale date, and supporting details, was released?

 

The change described there (tokenising) is something See now have the capability to do, but personally would be surprised to see deployed just because of how much it diverges from what has gone before and how much scope for issues it creates. Same for any kind of system that requires authentication.

 

Basically I reckon that any changes which result in a need for extra knowledge or steps outside of the ticket system should definitely be published well in advance, as that's something people really need to know if they're going to encounter it.

 

I don't think a straight "waiting room / click here to join the queue" change by itself would need flagging though, as (from a user perspective) it simply be one more waiting page on the same site and would be broadly consistent with the existing published information - the process would still ultimately boil down to visit the site, click to try and buy tickets until you get through, and once you do enter the registration number + postcode then proceed to purchase.

[LOWERCASE GUY]

 

9 minutes ago, incident said:

 

The change described there (tokenising) is something See now have the capability to do, but personally would be surprised to see deployed just because of how much it diverges from what has gone before and how much scope for issues it creates. Same for any kind of system that requires authentication.

 

Basically I reckon that any changes which result in a need for extra knowledge or steps outside of the ticket system should definitely be published well in advance, as that's something people really need to know if they're going to encounter it.

 

I don't think a straight "waiting room / click here to join the queue" change by itself would need flagging though, as (from a user perspective) it simply be one more waiting page on the same site and would be broadly consistent with the existing published information - the process would still ultimately boil down to visit the site, click to try and buy tickets until you get through, and once you do enter the registration number + postcode then proceed to purchase.

  

23 minutes ago, Avalon_Fields said:

That would certainly be a significant change. I feel they’re going to have to flag up any such changes soon, or run the risk of many complaints on the day with people not hearing or misunderstanding any new system. I’m not convinced it’ll happen, surely the time to announce changes would have been when the sale date, and supporting details, was released?

I agree that the best argument against a queue system (and by extension a tokenised access queue system) is the lack of communication from the festival that the ticket buying process is changing. I've had a look in the Wayback Machine at the relevant section of the Ticket Info page:

https://web.archive.org/web/20241007051708/https://www.glastonburyfestivals.co.uk/info/#tickets--how-to-book which is from October 7th, and compared it to the current version on the site. The comparison shows that there has been some updates to this section of the guide since October 7th. Mostly minor textual changes for clarity, perhaps the most substantive change is that your registration is now locked for 10 minutes rather than 5 minutes if an attempt to book is already held against your registration number, or if your 5 minutes on the booking page ends. So given this section of the site was updated around the announcement of the sale date, then why keep in the part about the 20s auto refresh if a queue system was to be implemented? Perhaps See Tickets haven't told the festival they're changing the booking system, or perhaps it's because the booking method isn't changing and it is the correct information. 

 

Last year the festival published a ticket buying FAQ exactly two weeks before the intended date of the coach sale (which was then pushed back by two weeks): https://www.glastonburyfestivals.co.uk/news/2024-ticket-sale-faq/. If they publish a guide to the ticket buying process when it isn't changing, then you'd imagine they'd definitley publish one when it is changing. Two weeks before this year's coach sale is this Thursday, so perhaps by the end of this week we'll have a bit more clarity.

 

Edited 1 hour ago by LOWERCASE GUY

[parsonjack]

10 minutes ago, LOWERCASE GUY said:

So given this section of the site was updated around the announcement of the sale date, then why keep in the part about the 20s auto refresh if a queue system was to be implemented?

The queue system wouldn't negate the 20s refresh functionality.  I got it, albeit not Glastonbury branded, during the Fender pre-sale at one point after the sale had started and I attempted to join the queue.

 

I think See could quite easily tack on the queue, and argue that the GFL ticket blurb still covers the change.