I would generally recommend a background in the sorts of things you care to reverse engineer. Don't for instance do Nintendo's player but if there is some open source video grabber for an embedded device then figure out the general workflow and you can come at the changes more. Equally while I might care about the precise instructions, calculations and timings for a damage model in a game then here you care more about having a video work which yields two main approaches. Don't know what they would have had for an index, if it is gone then hopefully you can find some cached data on one out there (that is to say dump things before you have tried loading the program in case loading clears it, same for any video files themselves).
If it is a download and play rather than streaming (slightly different approach, though mostly means it is segmented) then check it is not a common codec underneath it all (software patents mean games are not necessarily your standard MP4 H264 AAC type affair). At that point you have basically a downloader (see wget) and player (see mplayer for something to say), maybe with a handshake to make sure it is a 3ds or whatever that it is coming from rather than a PC (though as this is video rather than something you pay for then that is less of a concern, or likely to be far weaker*).
Alternatively if it is said common codec and the main url is no longer active you could edit the program to use a different URL on a server you control. Such a thing is also a debugging approach as you get fully formed requests, hopefully in plaintext, and can puzzle out their meaning.
Likewise it is typically better to be able to watch these services in action rather than being left with one side of the equation, and inability to play around with it. If nothing else being able to fire up wireshark or something to see the general flow of packets would make sense of a lot of things you might be seeing in assembly (by the way x32dbg is a wonderful program but as far as I am aware it is for PC programs, not ARM console stuff which you will want the paid version of IDA or something else like ghidra or radare2 for.
https://wrongbaud.github.io/posts/ghidra-debugger/ ). Or better yet you might have found that the 3ds downloads are broadly the same as the ones on the website, just cut down in resolution/framerate or something else and with a slightly different name.
*possibility Nintendo includes the account or some identifying console marker for metrics (who watches, who eventually buys... especially as they actually went in on the demos cost sales mindset).
Anyway most channels are themselves self contained programs (easier to update than needing to issue a firmware update, also less space for the firmware in memory if it does not have to be included) so you would probably start there. If you could make it work on an emulator then fantastic, if you have to debug on hardware or static (emulators and speaking to online services is a tricky one) then oh well still can do things just more tedious.
