Sover før konvertering er færdig

i løbet af de seneste par versioner ser det ikke ud til, at MCEBuddy når at færdiggøre en konvertering, før computeren går i dvale. Jeg har altid haft sluk for dvale aktiveret. Her er det mærkelige: det sker på begge mine systemer, men KUN på optagelser fra min HDPVR2 og ikke fra WinTV Quad på noget af systemerne. Min konverteringslog fra sidste gang det skete er vedhæftet. På forhånd tak.

SwampPeople-S10E15-VoodooPython-35895966-0.ts-Convert to MP4-2019-05-24T07-34-38.0890139-05-00.log (765,4 KB)

Der har ikke været nogen ændringer i det modul i meget lang tid. Det er muligt, at en nyere Windows-opdatering/-indstilling får systemet til at ignorere anmodningen om ikke at gå i dvale.

Når MCEBuddy aktivt konverterer, underretter det operativsystemet om ikke at gå i dvale, men det er i sidste ende op til operativsystemet, og det kan vælge at ignorere appen. Jeg tror, at Windows nu har en indstilling, som kan få det til at ignorere appens anmodning og stadig tillade, at det går i dvale. Du bør tjekke dine Windows-søvn-/strømindstillinger.

Alle søvn-/strømhændelser/-anmodninger logges desuden i mcebuddy.log-filen.

tak wingman, jeg kiggede på den fil og kan ikke se noget om sleep ud over indstillingen; kan du se noget her, der måske forårsager det? Kan jeg også anmode om en flyby?mcebuddy.log (3,3 MB)

Loggen ser fin ud ved første øjekast; jeg kan se, at MCEBuddy beder systemet om ikke at gå i dvale og genoptage normal drift, når der er aktive konverteringer henholdsvis når konverteringerne er færdige.

2019-05-24T13:04:09 MCEBuddy.Engine.Core → Starting new conversions, preventing system sleep
2019-05-24T13:11:29 MCEBuddy.Engine.Core → No conversions running, allowing system sleep

Du skal tjekke Windows-loggene for at se, hvad der foregår. Første skridt er at finde ud af hvornår systemet går i dvale. Typisk vil det, når det går i dvale, også sende anmodningen til MCEBuddy. Hvis du klikker på Events-linket øverst til højre i hovedvinduet, henter det en liste over Windows-begivenhedslogposter, som MCEBuddy-motoren har oprettet. Kopier og indsæt disse logge omkring det tidspunkt, hvor du så systemet gå i dvale (jeg gætter på, det vil være mellem de to tidsstempler i loggene, jeg har udtrukket ovenfor).

image

Derfra kan du åbne Windows-begivenhedsloggene omkring det tidspunkt og se, om du kan finde flere oplysninger om, hvorfor Windows gik i dvale (om en applikation sendte kommandoen, eller om det blot var den interne dvaletimer, der udløb). Hvis det er inkonsekvent, som du beskrev i dit første indlæg, formoder jeg, at en applikation muligvis sender dvalekommandoen.

her er MCEBuddys log på samme tidspunkt, som Windows sætter den i sleep:

Information 5. juni 2019 23:39
MCEBuddy OnPowerEvent kaldet af systemet, Begivenhed → Suspend

Systemet går i sleep.

Sleep-årsag: Systemet er inaktivt

men 1 sekund senere viser Windows:

Systemet har genoptaget fra sleep.

Det ligner, at Windows ignorerer anmodningen fra MCEBuddy om at forhindre dvale. Tjek dine Windows-strømindstillinger – der er et eller andet sted en overstyring, hvor du kan konfigurere, hvordan Windows håndterer dvale (aldrig, inaktiv, kritisk osv.). Desværre er dette et Windows-indstillingsproblem, og jeg gætter på, at noget er blevet ændret under en Windows-opdatering eller ved et uheld.

mærkeligt, Windows lytter til SageTV for at våkne til optagelser og forbliver vågen, indr udsendelsen er færdig, men det ignorerer tilsyneladende kun MceBuddy.

Det kan være et timet problem; MCEBuddy beder Windows om at stoppe med at sove, og en anden app sender et signal om, at det er i orden at sove, efter at MCEBuddy har sendt signalet.

Jeg tror, jeg har løst det – tak for at pege mig i den rigtige retning; punkt 4 her:

ser ud til at have virket for mig