Correct.
The MediaTek MT7615 is the chip that deals with WiFi
and
While no one has pinpointed the exact source of the problems, the combination mentioned has numerous negative feedback.
And yes, I have encountered 5 GHz WiFi problems with DIR-878, DIR-882 and DIR-2640. All using the MT7621/MT7615 combination.
Some devices with mt7615 chipset, as well as mt7610, mt7613 and mt7603 ones suffer from wrong tx power control values in the eeprom.
See this comment in mt76 repository. There have been some workarounds via some hacking and scripting that seem to achieve decent results, but it's fairly technical and it is very very unlikely these workarounds will make it into official OpenWrt releases (there are good reasons for why not).
Radio discovery for netgear r6220 and some other devices is not yet fixed on newest master snapshot. PCI paths of the WLAN devices have changed between Linux kernel 5.10 and 5.15, hence their broken state, but there is already this PR: ramips: mt7621: add migration script for WLAN PCI paths #12198 , so next release might have that one fixed 
Affected devices:
Netgear R6220
Netgear WAC104
Netgear WNDR3700 v5
Zbtlink ZBT-WE1326
Wiflyer WF3526-P
Arcadyan WE420223-99
Beeline Smartbox Flash (Arcadyan WG443223)
MTS WG430223 (Arcadyan WG430223)
Edit: the pr has been merged, so radio discovery for those devices should work in snapshot.
Thanks for the warning/heads up ThiloteE
Thank you for your response. 
I will avoid those routers at all cost!!!
Personally, IMHO I don't touch any of the D-Link products,
because their products really suck!
Just want to share my experience.
I use 2X DIR-878 A1 (OpenWRT 22.03.03) + 1X UAP-AC-LR (latest oem/stock/official firmware) on my 3 stories house. Floor material is concrete with metal base, by the way.
Each device covering wifi signals on each floor. Dir-878 on floor level 1&3 and uap-ac-lr on level 2. All connected using gigabit switch. It already up and running 24/7 for more than 1 year.
I use it as AP with multiple SSID and VLAN tag on each SSID. And I use mostly 5ghz At 40mhz radio settings. I use 2.4ghz only for IoT devices with specific/separate SSID.
802.11r+802.11v+802.11k were also configured on my 5ghz-only SSID. No routing/firewall being use. Also, I am Not using WAN port on dir-878.
So far, I have no significant problem with 5ghz on my dir-878. Clients can roam between AP on each floor without any significant problem.
However I have some minor noticable yet insignificant issue.
Upgrading firmware using luci web+keeping old config from 22.03.01 to 22.03.03 causing all openwrt wifi stop working, it says device disabled. Luci failed to restart/reenable the radio (both 2.4 and 5ghz). The solution is to upgrade without keeping the config (factory reset), and just manually reconfigure openwrt from luci web one by one.
Wifi Performance/latency is slightly better if client connected to UAP-AC-LR. Very slight and not noticable on day to day use. I have notice it only when I test it to stream live audio stream using VBAN protocol (optimal setting parameter on VBAN) from my wired 1G PC to my android phone while roaming between AP.
DIR-878 sometimes stutter (1 stutter every couple minutes), compared to UAP-AC-LR is less stutter (more than 5 minutes only 1 stutter).
Transfering files is also little bit faster on AC LR but again, very little difference.
No issue for wifi coverage on both device.
mixed security (WPA2/WPA3) is not working for some of my smartphone even if the smartphone is WPA3 capable. But WPA3-only SSID works fine on WPA3 compatible devices. So I just stick with WPA2-PSK for now to ensure compatibility.
For me, this is understandable because WPA3 is launch after 802.11ac, and these are AC devices build before WPA3 mature enogh to be use on 802.11ac hardware. For me, WPA2-PSK with AES is sufficient. No big deal.
So I am confuse. Why so many people have random and significant problem with 5ghz on dir-878?
Is this problem solved in latest openwrt release?
The D-Link dap x1860 A runs very stable on snapshot One of my devices is having a 47 days uptime Speed is ok for it being a dbdc device + running in relayd mode as repeater, which necessarily halfs wifi throughput. A great device if you do not yet have 1 gigabit speeds available, but need an upgrade NOW or alternatively plan to use this device in the longterm to serve clients that have no need for 1 gigabit speeds. Eventually managed to get a waveform bufferbloat score of A running through 3 walls
I'm using a DIR-882 (essentially a DIR-878 with USB ports) with the nightly OpenWrt builds (I update monthly) for nearly 2 years now and also never experienced the issues described on this thread...
Just to be clear, the only real issue is with the 5 GHz WiFi.
The ethernet routing performance (using arinc9's patches) is very good/excellent.
The MediaTek MT7621A is also used in MikroTik hEX RB750Gr3 and hEX S RB760iGS
No clue. This topic was split from the original, where number of members here tried to figure it out but gave up.
The latest stable release, which you're running, the 5 GHz works but is slower than the 2.4 GHz during my testing. 
I'm wondering if D-Link had slightly different hardware inside depending on region, time period or such.
If I encountered one or two, I could chalk it up as probably a lemon but I've dealt with about 9? 10? mixture (DIR-878 rev.A, DIR-882 rev.A and DIR-2640) of routers.
IMHO, D-Link products stink, period.
It's good to hear you have great results from using DIR-878, hopefully it will continue to perform well for many years to come. But for me personally, I won't touch any of the products, I believe their product quality is not consistent throughout the world.
I have the Linksys EA7300v1 and it has "MT7615E" and it did suck out-of-the-box but after some random trying of various settings, I got it to work great.
root@wonky:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio0.country='US'
wireless.radio0.band='2g'
wireless.radio0.channel='auto'
wireless.radio0.cell_density='0'
wireless.radio0.htmode='HT20'
wireless.radio0.txpower='26'
wireless.radio0.beacon_int='200'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.wds='1'
wireless.default_radio0.ssid='WONKY'
wireless.default_radio0.encryption='psk2'
wireless.default_radio0.key='redacted'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
wireless.radio1.country='US'
wireless.radio1.band='5g'
wireless.radio1.htmode='VHT80'
wireless.radio1.channel='auto'
wireless.radio1.txpower='auto'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.wds='1'
wireless.default_radio1.ssid='WONKY'
wireless.default_radio1.encryption='psk2'
wireless.default_radio1.key='redacted'
Definitely had terrible performance prior to this combo, no idea why or which thing helped.
Anyone knows if there is a patch to fix this?
I'm using a linksys e5600 and I found that 5ghz doesn't work properly. the Current 22.03.3 and 22.03.4 includes kmod-mt7603 kmod-mt7615e kmod-mt7663-firmware-ap that apparently fixes the antenna / radio, but so far i'm not unable to use it well.
I tried the snapshoot but is more unstable
I'm trying to fix a problem I think might be related. My Linksys EA7300 V1 will stop passing network traffic on just the 2.4Ghz SSIDs Here is my saga so far but in summary it is still failing with a fresh install and minimal settings, no special firewall rules, or VLANs.
Do you think this is related?
I made custom board and custom build.
I don't know if this problem is a hardware defect.
OpenWrt 22.03.0-rc6
Sometime radio is on "device not active"
Sometime i receive Timeout.
If I try to create two networks, one 2.5Ghz and one 5Ghz, it does not.
Create two equal networks, or change the other for it to be equal.
[ 15.111366] mt7615e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20180518100604a
[ 15.238401] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 15.378786] mt7615e 0000:01:00.0: N9 Firmware Version: _reserved_, Build Time: 20200814163649
[ 15.397597] mt7615e 0000:01:00.0: CR4 Firmware Version: _reserved_, Build Time: 20190121161307
[ 901.381652] rcu: INFO: rcu_sched self-detected stall on CPU
[ 901.387241] rcu: 2-....: (1 GPs behind) idle=136/1/0x40000004 softirq=39187/39188 fqs=1041
[ 901.395642] (t=2102 jiffies g=52725 q=2487)
[ 901.399892] NMI backtrace for cpu 2
[ 901.403370] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.134 #0
[ 901.409432] Stack : 809e0000 807f62f8 807f0000 80083490 80870000 80761cb0 00000000 00000000
[ 901.417783] 80c0fbbc 809c0000 807305dc 80c3d028 807f8e27 00000001 80c0fb60 1fbf4f76
[ 901.426129] 00000000 00000000 807305dc 80c0fa00 ffffefff 00000000 ffffffea 00000000
[ 901.434474] 80c0fa0c 0000016d 807fe828 ffffffff 00000000 00000000 00000000 80730000
[ 901.442819] 00000000 807f0000 807f0000 807f62f8 00000018 803f48dc 00000008 809c0008
[ 901.451162] ...
[ 901.453602] Call Trace:
[ 901.456062] [<800080e0>] show_stack+0x30/0x100
[ 901.460512] [<80372e34>] dump_stack+0x9c/0xcc
[ 901.464863] [<8037991c>] nmi_cpu_backtrace+0x104/0x164
[ 901.469977] [<80379ad0>] nmi_trigger_cpumask_backtrace+0x154/0x184
[ 901.476136] [<80096380>] rcu_dump_cpu_stacks+0x128/0x17c
[ 901.481429] [<8009c734>] rcu_sched_clock_irq+0x7bc/0x9a4
[ 901.486735] [<800a29bc>] update_process_times+0x78/0xc4
[ 901.491947] [<800b7274>] tick_handle_periodic+0x34/0xd0
[ 901.497176] [<804a4520>] gic_compare_interrupt+0x7c/0x9c
[ 901.502478] [<8008c3b0>] handle_percpu_devid_irq+0xbc/0x19c
[ 901.508046] [<80085e0c>] generic_handle_irq+0x44/0x5c
[ 901.513088] [<8038eb80>] gic_handle_local_int+0x94/0x118
[ 901.518376] [<8038ec14>] gic_irq_dispatch+0x10/0x20
[ 901.523234] [<80085e0c>] generic_handle_irq+0x44/0x5c
[ 901.528287] [<8068b6d4>] do_IRQ+0x1c/0x2c
[ 901.532282] [<8038e3b4>] plat_irq_dispatch+0x68/0xf0
[ 901.537225] [<80003508>] except_vec_vi_end+0xb8/0xc4
[ 901.542176] [<80034b14>] irq_exit+0xcc/0x12c
[ 901.546424]
[ 906.151709] mt7615e 0000:01:00.0: Message 000049ed (seq 3) timeout
[ 932.391717] mt7615e 0000:01:00.0: Message 000049ed (seq 4) timeout
[ 958.631699] mt7615e 0000:01:00.0: Message 000049ed (seq 5) timeout
[ 964.421644] rcu: INFO: rcu_sched self-detected stall on CPU
[ 964.427234] rcu: 2-....: (1 GPs behind) idle=136/1/0x40000004 softirq=39187/39188 fqs=4187
[ 964.435635] (t=8406 jiffies g=52725 q=9811)
[ 964.439885] NMI backtrace for cpu 2
[ 964.443363] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.134 #0
[ 964.449425] Stack : 809e0000 807f62f8 807f0000 80083490 80870000 80761cb0 00000000 00000000
[ 964.457778] 80c0fbbc 809c0000 807305dc 80c3d028 807f8e27 00000001 80c0fb60 1fbf4f76
[ 964.466126] 00000000 00000000 807305dc 80c0fa00 ffffefff 00000000 ffffffea 00000000
[ 964.474471] 80c0fa0c 0000018f 807fe828 ffffffff 00000000 00000000 00000000 80730000
[ 964.482816] 00000000 807f0000 807f0000 807f62f8 00000018 803f48dc 00000008 809c0008
[ 964.491159] ...
[ 964.493599] Call Trace:
[ 964.496059] [<800080e0>] show_stack+0x30/0x100
[ 964.500509] [<80372e34>] dump_stack+0x9c/0xcc
[ 964.504860] [<8037991c>] nmi_cpu_backtrace+0x104/0x164
[ 964.509975] [<80379ad0>] nmi_trigger_cpumask_backtrace+0x154/0x184
[ 964.516134] [<80096380>] rcu_dump_cpu_stacks+0x128/0x17c
[ 964.521427] [<8009c734>] rcu_sched_clock_irq+0x7bc/0x9a4
[ 964.526734] [<800a29bc>] update_process_times+0x78/0xc4
[ 964.531947] [<800b7274>] tick_handle_periodic+0x34/0xd0
[ 964.537175] [<804a4520>] gic_compare_interrupt+0x7c/0x9c
[ 964.542477] [<8008c3b0>] handle_percpu_devid_irq+0xbc/0x19c
[ 964.548047] [<80085e0c>] generic_handle_irq+0x44/0x5c
[ 964.553089] [<8038eb80>] gic_handle_local_int+0x94/0x118
[ 964.558376] [<8038ec14>] gic_irq_dispatch+0x10/0x20
[ 964.563235] [<80085e0c>] generic_handle_irq+0x44/0x5c
[ 964.568289] [<8068b6d4>] do_IRQ+0x1c/0x2c
[ 964.572282] [<8038e3b4>] plat_irq_dispatch+0x68/0xf0
[ 964.577226] [<80003508>] except_vec_vi_end+0xb8/0xc4
[ 964.582176] [<80034b14>] irq_exit+0xcc/0x12c
[ 964.586424]
[ 984.871696] mt7615e 0000:01:00.0: Message 000049ed (seq 6) timeout
From what I can see, development is mainly done using (master) snapshot builds or even in upstream code (e.g. linux kernel). You will have much higher success receiving responses from anybody who can professionally analyse the code, if you can reproduce these issues with master snapshot builds (downloadable from firmware selector) with a popular device that is actually supported by OpenWrt. Nobody wants to possibly (try to) fix a bug that potentially already has been fixed upstream or in the snapshot builds. I recon, "custom board" and "custom build" incite not very much interest in solving this, as no nobody knows what you have changed in the code.
Only DTS is custom.
Not other.
Word of caution:
Noticed sluggish response navigating LuCI with current Snapshot r22899 dated 2023-05-16.
Downloaded via Firmware Selector with following packages:
LuCI, irqbalance, adblock, luci-app-adblock
Initial login to LuCI took approximately 1 minute after pressing Login button.
Simply navigating one menu to another within LuCI took approximately 10 seconds.
Some changes/configurations within LuCI took approximately 1 minute for change.
With that said,
A lot better than the previous snapshot release, which took even longer time to login and navigate...
Since I download via Firmware Selector and add packages at the time,
Reverted back to snapshot r22599 dated 2023-04-19