Ventoy depends on something we don't include and have deliberately avoided adding for the last decade. From our side; they broke support that we don't use or need or rely upon, and it's their responsibility to un-break it.
Addind the driver package.mk is not enough to build the driver. You also need to mod the project or device 'options' file to build the driver package. You may also need to add/pick firmware from linux-firmware.
We don't do anything unusual with SD card creation/formatting .. so 
You are in the wrong forum for assistance with pirate download tools. Goodbye.
Not possible because VNC requires a Windowing system and in the GBM/V4L2 world we run directly on the DRM framebuffer without any kind of Windowing environment. You can crossgrade to the Generic-Legacy image which still uses Xorg, but no HDR there (if using kit that can support that). This is not technically a bug (everything working as designed) and it will be non-trivial to 'fix' so I wouldn't expect to see any progress anytime soon.
Use the code in this repo at this commit: https://github.com/chewitt/ssv605…d6bc33c6ce33b1f - newer commits will break the driver. The driver is crap so if it compiles you're lucky. It will not run on anything newer than Amlogic 3.14 or maybe 4.9 vendor kernels. Don't even think about asking for support!
thanks for great release, only thing I miss now is non-crazy white subtitles for hdr on rpi4, any progress on that?
No progress. It's not something simple to fix so won't be a quick one.
"getedid create" not "get edit create" .. try again 
Just use the "box" image and run from SD card.
I'm guessing.. but output to small displays requires an LE add-on to provide system support for the LCD device, and the separate Kodi add-on which configures Kodi to output something onto the display. If you're missing one of the other .. no output.
MiQi does not have S/PDIF output, so the audio card node in dts/dtb file does not describe an S/PDIF interface. You will need to build a custom LibreELEC image with kernel patch to modify the device-tree (adding the interface).
No need to play HDR content as the EDID data is static (doesn't change during playback), but connect direct to the TV/Projector to capture the correct EDID data with "getedid create" and then reconnect with the AVR in the chain.
The Generic (not Generic-Legacy) x86_64 image should run on that system AFAIK.
Spielmops If the box has Android (WeOS) still installed then you must configure and boot with the "box" image. Once booted into the box image you can download the "wetek-play2" image to /storage and overwrite Android with emmctool to run LE from emmc if you like. I do suggest you try the image from an SD card first before overwriting Android as there are feature/function differences between the old vendor kernel imag and AMLGX and it won't meet everyone's requirements.
There is no such thing as a "stuck" screen, only GPUs that are perhaps no longer supported (or loading the wrong driver) and thus never overwrite the boot splash with Kodi. You should still be able to SSH into the box and run "pastekodi" to share a URL so we can see what's wrong or not working.
NB: LE does not (and never will) guarantee to support all hardware. It's nice if things can keep going, but if older hardware doesn't align with our long-term technical direction and desire to keep the distro simple, we aren't going to bend over backwards to support it.
The official Plex add-on is broken and needs to be fixed by Plex devs.
Until that happens I've been using the version here: https://pannal.github.io/dontpanickodi/ which works fine. There are quite a few refs to it in the Plex forums.
HDMI is connected to port 1, and needs to be in port 0 nearest the power connector. Also note that 99% of users have no need to force 4K60 modes since there is very little 4K media in 4K60 format.
NB: If you reinstall the banned add-ons shown in the first log, further support will be refused.
LE is using the default libc resolver and this caches records according to their TTL values so I doubt caching is the issue. I'd make an educated guess that Kodi makes some form of discovery request which is being denied or sinkholed by Pi Hole and so the request is being repeated (ad infinitum) hoping to get a response (which never comes). There is probably something in Kodi that could have better failure logic. In the same breath Pi Hole improvement to not break the world's most popular mediacentre app would be a good thing too. The decision to use Pi Hole also makes it a self-inflicted problem, sort of, so both sets of developers will probably point fingers at the other.
More verbose logging from Pi Hole and/or perhaps a PCAP of the traffic to look at would be useful.
