Missed a DHS bus by 30 seconds, ended up getting there about 8:15am. Everything was gone before we arrived.
-
Welcome to the WDWMAGIC.COM Forums!
Please take a look around, and feel free to sign up and join the community.
News Star Wars: Rise of the Resistance Standby Line and Boarding Groups at Disney's Hollywood Studios
- Thread starter wdwmagic
- Start date
Missed a DHS bus by 30 seconds, ended up getting there about 8:15am. Everything was gone before we arrived.
DisneyPirate123
Member
Was MMRR posted wait time accurate? Hoping to RD MMRR during spring break but 160 minutes is a LONG wait!
Was 120 when we entered. Saw 105 soon after. We are currently at 60 minutes and are inside the building.
disneygeek90
Well-Known Member
Yesterday it was posted at 105 and I waited 65. Friday it was posted 105 and 120 and I waited about 80 mins each time.
If you can get into the main queue next to the theater without the extra queue leading into the main center of the park, that’s about what you’re looking at.
I’m here in the queue by myself on a Monday (and why are more people here today than this weekend? Go figure).
Hawkeye_2018
Well-Known Member
The security lines moved pretty quickly when we were there.
Also, the hard phone reset a few minutes before didn't seem to make much of a difference. First day I was group 86 and second day was 106. Still got to ride both days though.
Also, the hard phone reset a few minutes before didn't seem to make much of a difference. First day I was group 86 and second day was 106. Still got to ride both days though.
Joel
Well-Known Member
New discovery that I somehow missed in my initial testing: the getPositions API call is made about 3 minutes after the app is initially loaded, even if you don't touch anything. Which of course means that for 60 seconds after that, tapping the My Status button or refreshing the status page is a no-op. It then appears to be called every 6 minutes from then on. I have no idea why.
And if that wasn't annoying enough, it would be more precise to say that these automatic calls are scheduled to be made ~3 minutes after app load and then every 6 minutes thereafter. That's because the call isn't made if you aren't presently in the app; instead, it's delayed until you re-enter it. So if you load the app 5 minutes early, switch to your Web browser for a few minutes, and then switch back to MDE with 30 seconds to go, the getPositions call that was scheduled for 3 minutes after app load is made at this point, and you're locked out of making this API request again until ~30 seconds after the virtual queue opens.
@Demarke's advice of loading the app at 7:57:30 (2.5 minutes before opening) now seems frighteningly prescient, as it's just about the perfect time! Unfortunately, this makes timing issues even more important and obnoxious than they already were, since I'm sure plenty of people following the Demarke method aren't strictly adhering to his recommended time down to the second.
But wait! If you go to the Boarding Status page (the one you get to by tapping the My Status button), these background calls to getPositions are no longer made! Truly, Disney IT is a world of mystery and wonder!
Over the next few mornings, I'm going to test out starting from the status page and see how that works. For now, though, I recommend sticking with the Demarke method. Just be extremely mindful of launching the app in the narrower window of roughly 60-180 seconds before opening.
And if that wasn't annoying enough, it would be more precise to say that these automatic calls are scheduled to be made ~3 minutes after app load and then every 6 minutes thereafter. That's because the call isn't made if you aren't presently in the app; instead, it's delayed until you re-enter it. So if you load the app 5 minutes early, switch to your Web browser for a few minutes, and then switch back to MDE with 30 seconds to go, the getPositions call that was scheduled for 3 minutes after app load is made at this point, and you're locked out of making this API request again until ~30 seconds after the virtual queue opens.
@Demarke's advice of loading the app at 7:57:30 (2.5 minutes before opening) now seems frighteningly prescient, as it's just about the perfect time! Unfortunately, this makes timing issues even more important and obnoxious than they already were, since I'm sure plenty of people following the Demarke method aren't strictly adhering to his recommended time down to the second.
But wait! If you go to the Boarding Status page (the one you get to by tapping the My Status button), these background calls to getPositions are no longer made! Truly, Disney IT is a world of mystery and wonder!
Over the next few mornings, I'm going to test out starting from the status page and see how that works. For now, though, I recommend sticking with the Demarke method. Just be extremely mindful of launching the app in the narrower window of roughly 60-180 seconds before opening.
KevinPage
Well-Known Member
Yet yesterday I loaded the app at 7:55 am and stayed on that main page, Find Out More gave me Join Boarding Group on next screen and I netted BG 2, the first group of the day.
So what would explain that?
If I understand correctly, it checks when the app first loads, then 3 minutes later then after that every 6 minutes. If you loaded at 7:55 the subsequent checks would have been about 7:58 then 8:04. Since you opened up Find out more at 8:00, that would have been more than 60 seconds since the 7:58 check.
That's if I am following along correctly
KevinPage
Well-Known Member
If I understand correctly, it checks when the app first loads, then 3 minutes later then after that every 6 minutes. If you loaded at 7:55 the subsequent checks would have been about 7:58 then 8:04. Since you opened up Find out more at 8:00, that would have been more than 60 seconds since the 7:58 check.
That's if I am following along correctly
Correct, so it should not have worked for me (theoretically) if Im understanding all of this.
QUEUES is the initial call at app opening AND Find Out More button click
POSITIONS occurs by clicking MY STATUS
Joel
Well-Known Member
When you hit Find Out More it calls getQueues, not getPositions, so it would still have been available no matter when the background calls to getPositions are made.
Keep in mind that the rate limiting of these API calls is handled separately. The initial getQueues call on app load only blocks the app from calling getQueues again for the next 60 seconds. You can still call getPositions (once) during that time. And vice versa.
In this specific situation, though, you should have still had access to both API calls. Even if you loaded the app at 7:55:59, the background call to getPositions would have been made before 7:59, so the app would have been able to do it again when the queue opened.
KevinPage
Well-Known Member
OK, wow, my head is spinning like @gerarar love of pipes in the wind
So let me try to simplify this for me (and others) and correct me if I’m wrong
1. As long as you load the app a minimum of 60 seconds before 8am, you will still have access to to another API (GetQueues) when you click FIND OUT MORE (that means a week, a day, an hour all the way to 61 seconds before the time you want it)
2. GetPositions (essentially your 2nd bite at the
if GetQueues fails to populate after clicking Find Out More) is what we are discussion and need a more simplified explanation of
Joel
Well-Known Member
Exactly right. The getPositions call is a nice fallback if you jump the gun (e.g. because your clock was fast), but this additional complexity means it may not always be available depending on when you initially launch the app.OK, wow, my head is spinning like @gerarar love of pipes in the wind
So let me try to simplify this for me (and others) and correct me if I’m wrong
1. As long as you load the app a minimum of 60 seconds before 8am, you will still have access to to another API (GetQueues) when you click FIND OUT MORE (that means a week, a day, an hour all the way to 61 seconds before the time you want it)
2. GetPositions (essentially your 2nd bite at the
KevinPage
Well-Known Member
Ok, so I’m still foggy on WHY 7:57:30 is the perfect time to load in relation to GetPositions.
Can you explain what would happen if you load the app in regards to this at
7:55
7:57:30
7:59
I think seeing multiple scenarios will help my
Joel
Well-Known Member
7:57:30 isn't exactly perfect, but it's close enough considering, for all I know, Demarke just randomly pulled it out of a hat. The actual "perfect" time to load the app would 7:58, since it's smack dab in the middle of the 1-3 minutes before opening that we've determined as "safe".Ok, so I’m still foggy on WHY 7:57:30 is the perfect time to load in relation to GetPositions.
Can you explain what would happen if you load the app in regards to this at
7:55
7:57:30
7:59
I think seeing multiple scenarios will help my
This issue is kind of tricky, which is what makes it so annoying -- especially since there doesn't seem to be any good reason for the app to be making these API call automatically anyway. But let's work through some examples (times are approximate):
7:55
- 7:55 - getQueues called on app load (expires at 7:56)
- 7:58 - getPositions called automatically (expires at 7:59)
- 8:00 - Queue opened, both API calls available
- 7:57:30 - getQueues called on app load (expires at 7:58:30)
- 8:00:00 - Queue opened, both API calls available
- 8:00:30 - getPositions called automatically, but the queue is already open (and you should have gotten a BG by now anyway) so it doesn't matter
7:56:30
- 7:56:30 - getQueues called on app load (expires at 7:57:30)
- 7:59:30 - getPositions called automatically (expires at 8:00:30)
- 8:00:00 - Queue opened, only getQueues is available for the next 30 seconds
Great information on this forum on the best strategies for giving yourself the best odds of getting on a boarding group.
Does anyone have any information on the best size party you should have to increasing your odds of getting on a boarding group? My family has 4 people in it and we are going with another family of 4. We are all linked together in the app.
Is it better to keep our families separated and try for parties of 4 or have all of us try for a party of 8? To clarify there are only two adults per family, so only 4 of us will be running the app and trying to get on.
Thank you,
Does anyone have any information on the best size party you should have to increasing your odds of getting on a boarding group? My family has 4 people in it and we are going with another family of 4. We are all linked together in the app.
Is it better to keep our families separated and try for parties of 4 or have all of us try for a party of 8? To clarify there are only two adults per family, so only 4 of us will be running the app and trying to get on.
Thank you,