I explain the problem: The playback of videos hangs natively in wifi or lan about 30 sec of reading, however the same video on the pi3 starts without any problem.
Even the RPi3 is not powerful enough to "just start" a transcoding session. You should also see a significant waiting period with the RPi3 when it is transcoding. So, I believe we have to figure out why your client, whatever it is, uses Direct Play with your RPi3 while it forces your Tinkerboard to transcode the video.
Please tell me more about your client. And please take a look at the Web App -> Status -> Now Playing to check if the video is transcoded on your RPi3.
with ARM was heating the proc and planted during the construction of the db)
I suppose your Tinkerboard is heavily throttling the CPU because of excessive heat issues. If it even overheats while only scanning your media files, I will overheat during any transcoding session.
But when I change the playback quality during the video on a transcoding in less than 1 mbits, the video reads
What do you mean with "the video reads", exactly? The client shows the "spinning wheel"? However, using anything other than "original quality" is not recommend (see my next paragraph).
PS: As a reminder, the tinker board is 2GB of ram, the network card is gigabyte and wifi and the processor is an ARM Cortex-A17 Quad @ 1.8 GHz SoC Rockchip RK3288 that decodes native H264 and H265.
Video transcoding is a HUGE problem for the ARM cores. Hardware support on ARM is not utilized at the moment by Plex, so the CPU has to do all the work. It's the same on your RPi3 and your Tinkerboard. That's why you should avoid on-demand video transcoding at all costs. I recommend to use the Plex Media Optimizer  to create versions of your videos that do not require transcoding.
It's a basic 32 bit but I noticed that it runs better on 64 bit
The SoC on the Tinkerboard is ARMv7, it does not support 64 bit mode.