My understanding is that this debug log is intended to reveal all the DNS requests during the debug session and that at some point (I would assume the timing is important) that I would refresh or call that web page to see what happens on the pi-hole. Am I on the right track here? Can you describe the sequence of events...?
You are on the right track, but the log you are referring to is the pihole.log. The debug log is a file generated when you run the debug command (pihole -d). At the end of the debug log, you are asked if you want to upload the log. If you select yes, the log goes to a server and the token you get allows the developers to find your token. The debug log is a tool to let both you and the developers troubleshoot any Pi-Hole problems.
Tailing the pihole.log lets you see in real time all the DNS traffic passing through the Pi-Hole.
The pihole.log is tailed by one of the following methods:
That I noticed also on my side (but only if you play from within the app, and not airplay from the iPhone/iPad - if you airplay, ads will be airplayed too). Also the same happens via Playstation's Youtube player.
With the mobile app/browser, there is a complex check for a specific pattern/sequence at content pre-load, that is beyond the (only) DNS resolution/block ability of Pi-hole.
As for HULU, you can do what @jfb said. Tail the log, and see in real-time what domains are queried/needed by the HULU app.
By elimination, see what blocked domains get you to an ad-free experience.