MCEBuddy-version og -type (32-bit eller 64-bit):
MCEBuddy 2.5.5 x64
Operativsystem og type (32-bit eller 64-bit):
Win10x64 20H2 og bruger HW-kodning med et RTX2060.
Resumé af problemet eller forslaget:
MCEBuddy GUI låser med vinduestitlen “Service Not Connected”, og alle elementer i vinduet er nedtonede. Den eneste mulighed er at lukke/afslutte programmet og vente på, at Windows’ “svarer ikke”-dialog vises og tvinge programmet til at lukke. Den siger, den sender diagnostiske data til Microsoft, men jeg har ingen idé om, I kan hente detaljer hos Microsoft.
Jeg kører en instans af WSL Ubuntu eller en lejlighedsvis VirtualBox-instans. Jeg ved ikke, om det påvirker MCEBuddy. Kamp om CPU-kerner? f.eks. ved opstart ville MCEBuddy se alle kerner (4), og måske reserverer VBox eller WSL kerner eksklusivt for sig selv, og MCEBuddy opdager ikke, at det har ændret sig?
Det er Windows, der siger, at din CPU er løbet tør for ressourcer, og det bryder forbindelsen mellem GUI’en og motoren. Reducer arbejdsbyrden eller øg RAM/hastigheden på disken.
Jeg synes stadig, noget er skævt. Jeg kører med 34 % CPU, og MCE Buddy-GUI-processen, der står som “Not Responding”, sluger 27 % af det. Min belastning uden GUI’en er altså 7 %. Det giver ikke mening, for tidligere har alt kørt fint.
Jeg bruger også HW-(GPU-)transkodning, og jeg kører andre programmer, der er GPU-afhængige. Er der en test eller en kamp i MCE Buddy om eksklusiv adgang til GPU’en, som skaber konflikten? Håndterer Windows den eksklusive adgangspolitik for CUDA-applikationer? CUDA er nVidias GPU-API-SDK, FYI.
Jeg kører også Plex, og Plex bruger HW-transkodning til sit. Er der noget i MCE Buddy-loggene eller Windows-aktivitetsloggene, jeg kan kigge efter for at finde synderen?
Jeg kører også SiliconDust HD Homerun DVR-softwaren på samme maskine, men så vidt jeg ved, er det en ren CPU-applikation, og jeg har aldrig tidligere haft konflikter i alle de år, jeg har kørt alle tre på samme boks (SD HDHR DVR, Plex og MCEBuddy).
Hvis tjenesten er startet, blokerer din firewall eller antivirus for porten (23332), som MCEBuddy-tjenesten (motoren) bruger til at kommunikere med klienten (GUI).
Så jeg undersøger port 23332 i Windows-firewallen for at se, om det er et problem.
Jeg ville foreslå at prøve at deaktivere den automatiske firewall-undtagelse og UPnP-indstillingen på siden Systemindstillinger. Det ser ud til, at Windows hænger i forsøget på at få adgang til firewall- og netværkskortinformation.
Det ser ud til at have løst GUI-opstartsproblemet for mig. Jeg kunne ikke komme ind i nogen indstillinger i GUI’en, da den frøs, før hovedvinduet blev færdig med at indlæse.
Dog installerede version 2.5.6 fra 2021-04-27 og poppede op med det samme. Selv med 30% belastning (andre apps – og med 4 kerner betyder det egentlig, at én kerne er i brug) og med en anden GPU-app kørende, indlæste MCEBuddy GUI hurtigt og var klar til brug.
Så tag en kold forfriskning for at have fundet problemet og løst det så hurtigt.
Respekt og bliv rask, @Goose.
Har lavet mere test. Wow! En GPU-opgave kører, en KMTTG dekrypterer og downloader shows fra min Tivo, downloader spilopdateringer, og CPU’en var maksimeret til 95%. GUI’en kom stadig op kvikt og som en rockstjerne. Viste at MCEBuddy kørte en konvertering på GPU’en (udover min GPU-opgave) oven på de 95% CPU-brug. Den fulde GUI kommer op, og jeg kan interagere med den, så hvad det end var, er det bestemt blevet rettet.