Sehr langsam, wenn Handbrake konvertiert

Verwende MCEbuddy 2.6.4 mit einer Nvidia P2200-Karte und hörte, wie mein PC laut summte! Dachte, ich hätte das Problem im Keim erstickt. Bin mir nicht sicher, was es ausgelöst hat! Muss ich auf die letzte Version von Buddy oder den Nvidia-Treiber zurückgreifen – alle sind auf dem neuesten Stand. Aber die CPU wird stark belastet und nichts auf der Grafikkarte.
Diners Drive-Ins and Dives (2007) - 2024-08-16 08 00 00 - From Breakfast to the Boot.ts-Convert to MP4-2024-08-17T00-32-41.log (2,1 MB)

Handbrake fällt aus, es versucht es zweimal, nach dem ersten Fehler wechselt es auf Software-Decodierung statt Hardware-Decodierung, und es schlägt beide Male mit der generischen Fehlermeldung „Encode failed (error 3).“ fehl. Danach fällt es zurück auf ffmpeg anstelle von Handbrake. Aber ffmpeg nutzt Hardware-Encoding, daher ist es seltsam, dass deine CPU so stark belastet wird. Ich bin nicht besonders gut darin, Handbrake-Logs zu entschlüsseln, also fürchte ich, kann ich dir nicht viel darüber sagen, warum es fehlschlägt. Welche Version von MCEBuddy hast du vorher benutzt?

Unabhängig von diesem Fehler finde ich es seltsam, dass es fünf Minuten dauert, Metadaten aus dem Internet zu beziehen. Vielleicht, weil es so viele Staffeln der Serie gibt?

--> Performance Metrics for the Current Conversion
--> 

--> Working video pre-conversion duration (hh:mm:ss) -> 00:22:20
2024-08-17T00:50:14 MCEBuddy.Engine.ConversionJob --> Original file size [KB] 925,726.00
--> 

--> <Start At Date/Time>	<Duration (hh:mm:ss)>		<Activity>
--> <08/17/2024 00:32:46>	<00:00:00>		<Checking for disk space>
--> <08/17/2024 00:32:46>	<00:00:00>		<Running custom commands>
--> <08/17/2024 00:32:46>	<00:05:27>		<Getting show information and banner from Internet sources>
--> <08/17/2024 00:38:14>	<00:00:04>		<Running custom commands>
--> <08/17/2024 00:38:19>	<00:00:23>		<Copying source file to working directory>
--> <08/17/2024 00:38:42>	<00:00:00>		<Trimming video recording>
--> <08/17/2024 00:38:42>	<00:00:12>		<Analyzing video information>
--> <08/17/2024 00:38:54>	<00:03:03>		<Advertisement scan>
--> <08/17/2024 00:41:58>	<00:00:00>		<Running custom commands>
--> <08/17/2024 00:41:58>	<00:00:24>		<Removing commercials>
--> <08/17/2024 00:42:22>	<00:00:12>		<Analyzing video information>
--> <08/17/2024 00:42:34>	<00:01:18>		<Analyzing video information>
--> <08/17/2024 00:43:52>	<00:06:18>		<Converting>
--> <08/17/2024 00:50:11>	<00:00:02>		<Writing show information>
--> <08/17/2024 00:50:13>	<00:00:00>		<Renaming file using show information>
--> <08/17/2024 00:50:13>	<00:00:00>		<Running custom commands>
--> <08/17/2024 00:50:13>	<00:00:00>		<Moving converted file to destination>
--> <08/17/2024 00:50:14>	<00:00:00>		<Running custom commands>
--> <08/17/2024 00:50:14>	<00:00:00>		<Success - All done!>
--> 

INFORMATION --> Total time taken by conversion (hh:mm:ss) --> 00:17:27

Die Version ist im ursprünglichen Beitrag

Entschuldigung, ich habe deinen Beitrag missverstanden. Ich dachte, du hättest kürzlich ein Upgrade durchgeführt und fragst, ob du ein Rollback machen solltest.

Was hat sich seitdem geändert, dass es jetzt nicht mehr funktioniert?

Weiß nicht, wann es sich geändert hat. Ich weiß nur, dass ich dieses Problem nach dem Kauf der neuesten MCEbuddy-Version hatte, damit es mit PLEX/HDhomerun funktioniert, und stellte fest, dass die GPU nicht genutzt wurde, was damals korrigiert wurde. Ich weiß, dass Nvidia kürzlich ihre Treiber aktualisiert hat, also bin ich mir nicht sicher, wann dies begonnen hat.

Hier ist ein weiteres Protokoll von einer anderen Show
The Ark (2023) - S02E07 - It Can’t Be True.ts-Convert to MP4-2024-08-29T02-01-14.log (6,4 MB)

Versuche, auf einen älteren Treiber zurückzugreifen. Hardware-Konvertierungsprobleme sind zu 99% treiberbedingt. Sobald du einen guten, stabilen Treiber für Hardware-Konvertierungen gefunden hast, empfehlen wir dringend, dabei zu bleiben.

Ich hasse Windows 11 so sehr, LOL, nichts ist so einfach wie Win 7. Okay, vor einer Weile kam eine Nvidia-Benachrichtigung im System-Tray, dass es Updates gibt. Habe gerade nachgeschaut und das ist, was ich habe: Treiber-Version 26.21.14.4250 vom 24.02.2020!! Nvidia Quadro P2200 – jetzt kratze ich mir wirklich am Kopf. 2020?

Probieren Sie die Treiber von der Nvidia-Website aus. Hier ein direkter Link zu getesteten Treibern

Okay, es ist bei 31.0.15.5222 4/11/2024

Hier ist die neueste Konvertierung. Für mich klingt sie wie Chinesisch – LOL, hoffentlich sieht das gut aus
Diners Drive-ins and Dives.txt (1,0 MB)

Nein.. Habe es nur in einer anderen Fernsehsendung laufen sehen, GPU lag bei 1 % und die CPU bei 75 %. Muss ich auf eine frühere Version von MCE zurückkehren?

Laut den Logs wird nvenc zum Encodieren verwendet und es ist ziemlich schnell (244 fps). Bist du sicher, dass das Tool die Auslastung korrekt anzeigt? Klingt immer noch nach einem Treiberproblem

2024-09-07T00:38:22 MCEBuddy.AppWrapper.FFmpeg → frame= 5653 fps=244 q=32.0 size= 31744kB time=00:01:34.48 bitrate=2752.2kbits/s dup=7 drop=0 speed=4.08x

Der Treiber ist 4/2024 der neueste von der Website, die du mir geschickt hast
Ja, meine CPU hat keine Probleme, durch die Episode zu rasen. Aber die CPU wird für andere Programme auf meinem Server benötigt, deshalb habe ich die GPU

Um auf deine frühere Aussage zurückzukommen: Wenn es funktioniert hat und dann plötzlich aufgehört hat – das, was sich geändert hat, schien der Treiber zu sein. Darauf würde ich mich konzentrieren. Versuche herauszufinden, welcher Treiber zuvor verwendet wurde.

Du kannst ältere Versionen von MCEBuddy ausprobieren, aber ich wäre überrascht, wenn das einen Unterschied macht. Laut den Protokollen wird die GPU verwendet; wenn sie nicht verwendet wird, deutet das auf ein Treiberproblem hin.

Das andere, was du versuchen kannst, ist, die Hardware-Kodierung in MCEBuddy zu deaktivieren und dann die Konvertierungs-FPS zu überprüfen. Wenn sie gleich bleibt, springt die GPU nicht an; wenn sie sinkt, arbeitet die GPU, aber dein Tool meldet möglicherweise falsch, dass sie für die Kodierung verwendet wird (wiederum würde das auf ein Treiberproblem hindeuten).

Hatte nicht viel Zeit, mich mit der GPU in MCEbuddy zu beschäftigen, aber letzte Woche habe ich einige Fernsehsendungen konvertiert, die MCEBuddy umgewandelt hat, und sie dann mit VideoProc Converter laufen lassen – dabei ist die GPU aktiv und konvertiert sie klein zu MKV H.265; eine 30-Minuten-Show dauert nur ein paar Minuten, rasant schnell. Die Treiber scheinen also in VideoProc einwandfrei zu funktionieren. Im Windows-11-Task-Manager sehe ich die GPU bei 50 % Auslastung.

Führe MCE jetzt mit MKV-HEVC-Einstellungen aus – hier ist die GPU:

Ihre Logs zeigen, dass MCEBuddy 6 Minuten für die Konvertierung der Datei benötigt hat und dabei die GPU nutzt

→ <09/07/2024 00:37:36> <00:06:11>

Wenn Sie sich um das GPU-Diagramm sorgen, handelt es sich dabei um ein Treiberproblem. FFMpeg verwendet nvenc-APIs, um mit dem System zu interagieren und GPU-Encoding zu aktivieren. Ihr Treiber meldet diese Nutzung nicht an Windows. Die andere Software verwendet wahrscheinlich DXVA, um Hardware-Encoding zu aktivieren, was von Windows gemeldet wird. Laden Sie das NVidia-GPU-Monitor-Tool herunter und sehen Sie, was dieses anzeigt. Die Windows-Berichterstattung ist in dem, was sie anzeigt, begrenzt.

YEP! Habe das gestern herausgefunden! Windows versagt da total. Habe einen weiteren Grund gefunden, warum die Maschine so langsam läuft – einfach durch Ausschlussverfahren. Normalerweise läuft PLEX 24/7, zeichnet auf und verbraucht dabei kaum mehr als 30 % meiner Ressourcen – super!

Die letzten paar Tage war der PC fast nicht mehr ansprechbar. Meine C-Festplatte ist eine 2-TB-SSD, von der alles läuft; es sind noch über 1 TB frei, also kein Speicherplatzproblem. Aber die Platte ist dauerhaft bei 100 % Schreibaktivität. Also habe ich die PLEX-Aufnahme pausiert und gewartet – immer noch 100 %. Dann habe ich MCEBuddy pausiert – Aktivität fiel auf 3 %. PLEX-Aufnahme wieder gestartet – Sprung auf 20 %. Sobald ich MCEBuddy starte, geht die C-Platte wieder auf 100 % Schreiblast. MCEBuddy ist eingestellt, 4 von 32 Prozessoren zu nutzen, Priorität „normal“, zwei gleichzeitige Konvertierungen. Irgendein Vorschlag? Soll ich das Programm von C wegbewegen?

Die Datenträgernutzung erfolgt standardmäßig im Temp-Ordner. Das passiert, wenn Dateien remuxt, kopiert, geschnitten usw. werden. Sie können den Speicherort des Temp-Ordners ändern. Sie könnten auch die Priorität auf Lowest setzen; die Konvertierung wird langsamer sein, sollte aber auch die Datenträgerkonkurrenz verringern, wenn sie mit anderen Programmen um I/O-Zugriff konkurriert.