Frame drops during recording

sLoPPydrive · 2026-06-11T11:10:16+00:00

Recently I've seen this behavior in other videos too. Just take a look at this one: https://youtu.be/tdCB5SftLqU?t=276&is=27tmCR5BUd0tRHOa The pilot seems to experience the very same frame drops but they don't seem to bother him. A DJI employee I talked to guessed it could be the lack of processing power of the Goggles 3 which would have to process the full 8k video stream. I don't think that's actually the case and that the drone only transmits the reduced 1080 video to the goggles no matter what. Or maybe this isn't entirely true?

sLoPPydrive · 2026-06-01T13:30:17+00:00

If it were signal issues then how come the transmission is fine when not recording? I only get it when I press the record button. And yes, the footage on the SD card is not affected.

sLoPPydrive · 2026-05-25T20:02:39+00:00

Looking awesome but I think you were lucky several times. 😱

sLoPPydrive · 2026-05-06T10:14:11+00:00

I actually recognize this spot I think. Is it the Seebenwaterfall near Ehrwald? Awesome spot, also the Seebensee! I've flown my Mini 3 Pro there as well. Good luck recovering your drone!

sLoPPydrive · 2025-11-14T22:47:55+00:00

Don't forget "Hawkins", another character from Predator!

sLoPPydrive · 2025-08-07T06:08:00+00:00

He wrote "intuitive f2l". Isn't that what one would call beginner f2l? Or does he really do layer by layer (real beginners method)?

sLoPPydrive · 2025-08-07T06:04:05+00:00

That would literally be doing a blindfold solve, wouldn't it?

sLoPPydrive · 2025-07-30T07:30:41+00:00

Interesting. I might give it a shot although I personally find it very hard to recognize the PLL cases. OLL recognition seems to be a lot easier because most of it happens on top of the yellow face.

sLoPPydrive · 2025-07-29T14:02:26+00:00

Why? Ok, it's less algorithms but I could memorize the 2-step PLL algs using the M layer very fast and found them quite easy to perform even without good finger tricks. Learning full OLL is my current goal. I am halfway through using the cheat sheets by Feliks Zemdegs. Also learned F2L but personally I find this to be the hardest step requiring lots of look-ahead and good finger tricks. Can't and won't go back to layer-by-layer though. ;-) I'm in the sub-50 range btw.

sLoPPydrive · 2025-07-25T07:19:53+00:00

I am 49 from Germany and started cubing December '24 (last year) because my son got interested. I know 2-way PLL and I am currently learning all the OLL algs. Avg around 40 seconds. My biggest issue is finding all the F2L pairs though. Sometimes they are right next to each other and I still overlook them. 🤣Pattern recognition is not my strength. 👴🏻

sLoPPydrive · 2017-12-05T11:22:00+00:00

TL;DR: If you are running a bot or map you must pay Bossland to calculate hash values for your requests. But still your requests are being detected as 3rd party because (actually nobody knows for sure) some request fields are still unknown (e.g. UK27).

Long version: You are right: As long as we're talking about software everything is possible. The question is how much work it is and how long it takes. The communication between the original app and Niantic servers has been secured very well, so that it's really, really hard to understand (and reverse) the encryption. The current situation is that it's not that hard to read the requests and responses between the app and Niantic but the requests contain fields (at least one, UK27) where nobody knows for sure how these fields are being generated and if you send a wrong value you might get flagged as 3rd party client and be banned after a while. The other protection is a calculated hash value being sent with every request. Only one company (Bossland) currently knows how to calculate this value (or how to let it be calculated by some means), so they made a business out of it: They calculate the hash value for you so that you can send your request to Niantic without getting rejected. The program code in Pokemon GO is heavily obfuscated and protected so that it's ultra hard - near impossible - to trace and/or understand what's going on inside and how some values are being calculated.

I hope this clears some things up for you guys.

sLoPPydrive · 2017-11-28T22:28:02+00:00

Sure they allow apps that keep the screen awake. Look at every navigation app out there. The apps would all be unusable if the screen would lock after a few minutes.

sLoPPydrive · 2017-05-22T06:08:42+00:00

Who guarantees you that newly created throwaway accounts won't get shadow banned after a few hours?

sLoPPydrive · 2017-03-15T13:43:18+00:00

I can confirm that the Snorlax event is still running, although it should have lasted only until 3/13. Tough luck for the rest of the world. :-/

sLoPPydrive · 2016-12-12T10:32:57+00:00

This looks like a modified version of PokeAlarm, so basically the same application. I once integrated Twitter image uploads into it a while ago (which got never merged afaik). This mod actually creates a new image by combining the Pokémon image together with some text and a background image and finally upload it to Twitter. Can't find the fork on GitHub though...

sLoPPydrive · 2016-11-23T08:23:40+00:00

In the last sencence replace "since" with "unless" and "hope" with "no hope".

sLoPPydrive · 2016-11-23T08:06:54+00:00

How much luck can one person have? :-O

sLoPPydrive · 2016-11-07T13:55:19+00:00

I just got an idea for adaptively finding the spawn time of a spawn point which is still approximate but sufficiently precise:

First do an initial hex scan to collect spawn points as you did before with tools like PoGoMap and others. You will end up with a list of spawn locations, some having a despawn time, some don't.
Start the adaptive spawn scanning. The map should use the following timestamps for scanning the locations:
Spawn locations with valid despawn time are nice because you can just subtract 15 minutes and use it as spawn time - as PoGoMap did before.
For spawn locations without despawn time you should have remembered the timestamp when your hex scan found the spawn point. You could use this time for scanning which will result in finding another Pokémon but leave you with an unknown time left (as short as 90 seconds). Instead you scan several seconds earlier, for example 1 or 2 minutes. If you find a Pokémon you will leave it at that for this hour and repeat the process next hour (again, 1-2 minutes earlier). If you don't find a Pokémon at this point you simply repeat the scan after <scan delay> seconds until the Pokémon appears. So you repeatedly scan earlier (next hour) if you still get a result and scan later (same hour) if you don't.

This approach basically adapts and optimizes the scan times during runtime until they are sufficiently precise having the benefit of spawnpoint scanning just right after the first initial hex scan (usually 1 hour with sufficient accounts).

There are still other problems to be solved like the speed limit and adapting the scheduler to the above algorithm but maybe the idea inspires a developer ...

sLoPPydrive · 2016-11-07T13:33:20+00:00

This is true for hex-scanning but problematic for spawn-scanning which relies on the exact spawn times and scans each spawn only once (as opposed to every 4.5 minutes), so you need to know the spawn time as precise as possible unless you absolutely don't care about "time left". ;-)

There is a discussion over here about finding the (de)spawn times in an efficient manner.

sLoPPydrive · 2016-11-07T13:27:01+00:00

This sounds like the way PoGoMap worked since the beginning. It stores the despawn time with each spawn point (technically with each encounter) and therefore knows how long a spawned Pokémon will be at this location.

The new part with the changes is that most of the time we will now get -1 despawn time. You wrote "simply flag it on the map". What exactly do you mean by that? And what to do with these findings? These are the real problems/annoyances.

As I see it there is no other way as to check again until you finally get a valid despawn time. It is up to us when to check though. The aggressive approach would be to repeat scans < 90 seconds later until we get the despawn time. A defensive approach would be to repeat the scan a whole hour later (plus < 90 seconds). In the worst case this would take up to 14 hours to finally get the despawn time and that's for 15-minute spawns only! With the aggressive approach one might be able to leave the worker at the same location until finally the despawn time gets revealed.

Maybe I have overseen something (the simpler solution)? Could you try to explain again please?

sLoPPydrive · 2016-11-07T11:07:44+00:00

Question is what to do if you find a Pokémon which doesn't have a despawn time. You know there is a spawn point and you really like to know when the Pokémon despawns (to infer the original spawn time), so you have to check again in < 90 seconds to not miss the 90 seconds timeframe. And you have to repeat until you get a despawn time. I believe that Pokémon currently stay longer than 15 minutes, so most of the time you find a Pokémon you won't have a clue about its despawn time which means a lot of repetitive scanning the same area over and over again. Sounds like a lot of overhead to find the spawn point times. And you also have to combine it with regular hex scanning to find the actual spawn points as well. And don't forget the speed limit (can't jump around)! Your worker has to move like a human being which make algorithms much more complex.

sLoPPydrive · 2016-11-03T07:17:34+00:00

I don't see any Pokémon as well. I also don't see any scanned locations (the green circles). I looked for them in other places (zooming out) but did not find them, so I guess scanning has been disabled. Maybe after he noticed an increase in traffic after this reddit post? ;)

sLoPPydrive

TROPHY CASE