MCEBuddy GUI loopt vast - Service Niet Verbonden

Fouten / Functieverzoeken Bugs
1

Verzoek Type:
BUG

MCEBuddy Versie en Type (32bit of 64bit):
MCEBuddy 2.5.5 x64

Besturingssysteem en Type (32bit of 64bit):
Win10x64 20H2 en gebruik van HW-encoding met een RTX2060.

Samenvatting van het probleem of suggestie:
De MCEBuddy GUI blokkeert met de venstertitel “Service Not Connected” en alle elementen in het venster zijn uitgegrijsd. De enige optie is het programma te sluiten en te wachten tot het Windows-venster “reageert niet” verschijnt, waarna het programma geforceerd kan worden afgesloten. Er wordt aangegeven dat diagnostische gegevens naar Microsoft worden verzonden, maar ik heb geen idee of u Microsoft kunt inschakelen voor details.

Ik draai een instantie van WSL Ubuntu of af en toe een VirtualBox-instantie. Ik weet niet of dat invloed heeft op MCEBuddy. Concurrentie om CPU-cores? Bijvoorbeeld: bij het opstarten ziet MCEBuddy alle cores (4), maar mogelijk reserveert VBox of WSL cores exclusief voor zichzelf en weet MCEBuddy niet dat dit is veranderd?

Stappen om de bug te reproduceren:
Start de MCEBuddy GUI.

2

Dat is Windows dat aangeeft dat je CPU aan resources tekort komt en de verbinding tussen de GUI en de engine verbroken wordt. Verminder de werklast of verhoog het RAM/schijf snelheid

3

Ik denk nog steeds dat er iets vreemds aan de hand is. Ik draai op 34% CPU en het “Not Responding” MCE Buddy GUI-proces neemt daar 27% van in beslag. Dus mijn belasting zonder de GUI is 7%. Dat klopt niet, want eerder ging alles goed.

Ik gebruik ook HW (GPU)-transcoding en ik draai andere applicaties die GPU-gebonden zijn. Is er een test of conflictering in MCE Buddy voor exclusieve toegang tot de GPU en is dat de conflictbron? Beheert Windows dat exclusieve gebruiksbeleid voor CUDA-applicaties? CUDA is nVidia’s GPU API SDK, ter info.

Ik draai ook Plex en Plex gebruikt HW-transcoding voor zijn werkzaamheden. Is er iets in de MCE Buddy-logs of de Windows-activiteitenlogs waar ik naar kan kijken om de dader te vinden?

Ik draai ook de SiliconDust HD Homerun DVR-software op dezelfde machine, maar voor zover ik weet is dat een CPU-only applicatie en ik heb nooit eerder een conflict gehad in al die jaren dat ik alle drie op dezelfde machine gebruik (SD HDHR DVR, Plex en MCEBuddy).

Alvast bedankt, @Goose.

4

Hier is de threadstack (via SysInternals Process Explorer) van de thread die alle CPU-capaciteit opslokt:

ntdll.dll!NtQueryKey+0x14
KERNELBASE.dll!MapPredefinedHandleInternal+0xe54
KERNELBASE.dll!MapPredefinedHandleInternal+0xa80
KERNELBASE.dll!RegOpenKeyExInternalW+0x141
KERNELBASE.dll!RegOpenKeyExW+0x19
DNSAPI.dll!Reg_GetValueEx+0xed3
DNSAPI.dll!DnsApiFree+0xfba
DNSAPI.dll!NetInfo_Build+0x117
DNSAPI.dll!DnsUpdateMachinePresence+0x7ff
DNSAPI.dll!DnsDhcpRegisterInit+0x1f9b2
DNSAPI.dll!DnsDhcpRegisterInit+0x1fad3
DNSAPI.dll!DnsDhcpRegisterInit+0x1a68a
IPHLPAPI.DLL!GetOwnerModuleFromPidAndInfo+0x9cd
IPHLPAPI.DLL!GetPerAdapterInfo+0x30
[Native Frame: IL Method without Metadata]
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\
    System.dll!System.Net.NetworkInformation.SystemIPv4InterfaceProperties.GetPerAdapterInfo+0x93
    System.dll!System.Net.NetworkInformation.SystemIPInterfaceProperties..ctor+0x220
    System.dll!System.Net.NetworkInformation.SystemNetworkInterface..ctor+0xcd
    System.dll!System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces+0x19e
    System.dll!System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces+0x4b
C:\Program Files\MCEBuddy2x\MCEBuddy.Util.dll!MCEBuddy.Util.Net.isLocalMachine+0x9e
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.StatusForm.DisableControls+0x62d
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.StatusForm.backgroundUpdate_ProgressChanged+0x24d
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089
    System.dll!System.ComponentModel.BackgroundWorker.OnProgressChanged+0x9b
[Unmanaged to Managed Transition]
clr.dll!CoUninitializeEE+0x1b73
clr.dll!CoUninitializeEE+0x1a88
clr.dll!MetaDataGetDispenser+0x33602
clr.dll!MetaDataGetDispenser+0x33a75
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x84
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Delegate.DynamicInvokeImpl+0xa0
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackDo+0x9d
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackHelper+0x69
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.RunInternal+0x172
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x15
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x55
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallback+0xbc
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbacks+0xe6
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc+0x509
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback+0xc2
[Unmanaged to Managed Transition]
[Native Frame: IL Method without Metadata]
clr.dll+0x221e
USER32.dll!CallWindowProcW+0x3f8
USER32.dll!DispatchMessageW+0x259
[Native Frame: IL Method without Metadata]
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop+0x341
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ThreadContext.RunMessageLoopInner+0x1c7
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ThreadContext.RunMessageLoop+0x52
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.Program.Main+0x3a
[Unmanaged to Managed Transition]
clr.dll!CoUninitializeEE+0x1b73
clr.dll!CoUninitializeEE+0x1a88
clr.dll!CoUninitializeEE+0x2338
clr.dll!SetRuntimeInfo+0x8c2
clr.dll!SetRuntimeInfo+0x1287
clr.dll!SetRuntimeInfo+0x113b
clr.dll!SetRuntimeInfo+0xa87
clr.dll!SetRuntimeInfo+0xa05
clr.dll!CorExeMain+0x14
mscoreei.dll!CorExeMain+0x71
MSCOREE.DLL!CorExeMain+0x72
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

Einde.

5

Zag in een andere post van @Goose:

Als de service is gestart, dan blokkeert je firewall of antivirus de poort (23332) die door de MCEBuddy-service (engine) wordt gebruikt om te communiceren met de client (GUI).

Dus ik onderzoek poort 23332 in de Windows-firewall om te zien of dat een probleem is.

6

Ik wilde voorstellen om de automatische firewall-uitzondering en de UPnP-optie op de pagina Systeeminstellingen te proberen uitschakelen. Het lijkt erop dat Windows vastloopt bij het opvragen van de firewall- en netwerkadaptergegevens.

7

Issues met elkaar verbinden:

8

Het CPU-probleem is opgelost in de vandaag uitgebrachte 2.5.6 BETA-versie

9

Dat lijkt het GUI-opstartprobleem voor mij te hebben opgelost. Ik kon geen instellingen in de GUI bereiken omdat het vastliep voordat het hoofdvenster klaar was met laden.

De versie 2.5.6 van 2021-04-27 installeerde echter en startte meteen probleemloos. Zelfs met 30% belasting (andere applicaties - en met 4 cores betekent dat eigenlijk dat één core in gebruik is), en met een andere GPU-applicatie die draaide, startte de MCEBuddy GUI snel en was klaar voor gebruik.

Dus schenk jezelf een lekker drankje in voor het zo snel vinden en oplossen van het probleem.
Complimenten en blijf gezond, @Goose.

10

Heb nog wat meer getest. Wauw! Een GPU-taak die draait, een KMTTG die shows van mijn Tivo ontsleutelt en downloadt, game-updates die binnenkomen, en de CPU piekte tot 95%. De GUI reageerde nog steeds snel en als een rockster. Toonde aan dat MCEBuddy een conversie op de GPU uitvoerde (naast mijn GPU-taak) bovenop de 95% CPU-belasting. De volledige GUI komt op en ik kan ermee interageren, dus wat het ook was, het is zeker opgelost.

Goed werk geleverd, @Goose!