MKV Buddy - Kleiner Helfer fürs tägliche Video basteln... (2 Viewers)

[BlueMax1916]

Hallo Lehmden,

die .nfo heißt bei mir immer so wie die .mkv.
Im Ordner liegen dann zunächst beispielsweise:
Spuren des Bösen - Racheengel (2012) (tt2199536).mkv
Spuren des Bösen - Racheengel (2012) (tt2199536).nfo

Ich habe alles in Ordner sortiert, siehe https://forum.team-mediaportal.com/...che-video-basteln.127298/page-51#post-1143351

Nur im Arbeitsordner des MKV Buddy nicht weil da immer nur ein FIlm reinkommt, der dann getagged wird.

Meine derzeit zu 99% ungetaggte Filmsammlung möchte ich direkt in deren Ablageordnerstruktur taggen, dazu möchte ich eigentlich nur jeweils eine .nfo nach meinem Namensschema sowie die IMDB Nummer darin erstellen. Ich kann jetzt nicht jede dieser .mkv umbenennen so dass die nur die IMDB Nummer im Namen führen. Das ist zu zeitaufwendig. Da das mit der 'leeren' .nfo schon funktioniert hat wräe das super wenn das wieder gehen würde.

 

[Lehmden]

Hi.

Nur im Arbeitsordner des MKV Buddy nicht weil da immer nur ein FIlm reinkommt, der dann getagged wird.

Genau das ist eigentlich nicht der Sinn vom MKV Buddy, auch wenn man durchaus so damit arbeiten kann. Er ist gedacht, um viele Filme auf einmal zu verarbeiten. Zum individuellen Aufarbeiten von Videos gibt es viele andere Tools, die aber alle kläglich versagen oder extremst umständlich zu bedienen sind, wenn es um "Massenproduktion" geht...

Meine derzeit zu 99% ungetaggte Filmsammlung möchte ich direkt in deren Ablageordnerstruktur taggen, dazu möchte ich eigentlich nur jeweils eine .nfo nach meinem Namensschema sowie die IMDB Nummer darin erstellen.

Die .nfo bekommt automatisch den gleichen Namen wie der Film sofern du in den Settings "{movie}.nfo", also den voreingestellten Wert, gesetzt hast. Durch die tt Nummer im Namen sollte der Film auf alle Fälle richtig erkannt werden, ohne das vorher eine .nfo erstellt worden ist. Auch das Problem mit den temporären Ordnern ist keines, da du ja alle Filme bereits in Unterordnern hast. Das müsste eigentlich direkt so funktionieren ohne das du irgendwas ändern musst. Außerdem kann man das Umbenennen ja ganz abschalten, was ich dir für das Aufarbeiten deiner fertigen Sammlung sowieso empfehlen würde. Die .nfo bekommt trotzdem den passenden Namen...

Nur bei neuen Filmen musst du den Ordner selbst manuell umbenennen, denn es gibt bei dir einige Eigenheiten im Namensschema, die sich nicht umsetzen lassen und auch beim alten Buddy nie funktioniert haben können. Für die Namensgebung kann man nämlich nur Werte aus der .nfo Datei und feste Texte/Buchstaben verwenden. In der .nfo steht das Land, das Jahr und auch das Genre drin, aber keine Informationen über das eigentliche Video, also Sachen wie Codec usw. Die kann man also nicht zum Umbenennen verwenden und das ging auch nie. Deswegen kann der Buddy keine Ordner nach solch einem Schema erstellen:

"Rocky Balboa (Sport USA 2006 93 min MKV H.264 HDTV 720p 1280x692 AC3 5.0)".

Sport USA 2006 würde gehen (sofern die nfo das so drin stehen haben). Aber der Rest geht nicht. Mal ab davon, 5.0 ist eher sehr exotisch, müsste das nicht 5.1 sein? Vorhandene Unterordner werden aber nicht geändert, weswegen das Grabben und Taggen funktionieren sollte ohne etwas zu verändern.

Da das mit der 'leeren' .nfo schon funktioniert hat wräe das super wenn das wieder gehen würde.

Sollte das wirklich funktioniert haben, was ich bezweifele, dann war das ein Bug, den ich nicht reproduzieren und durch die neue interne Struktur vom Buddy 2.0 auch nicht wieder einbauen kann. Dass das Hantieren mit den "leeren" .nfo sowieso komplett überflüssig ist und dir rein gar keine Vorteile bringen kann (die tt Nummer im Dateinamen ist ja schon vorhanden und bewirkt genau das, was du mit der "leeren" .nfo erreichen willst), sollte das keinerlei Nachteil sein.

Solche "leeren" nfos hätten nämlich den alten Buddy normalerweise zum Abstürzen gebracht wenn ich das nicht abfange. Der Neue Buddy liest solche Sachen immer in eine SQLite Datenbank ein, die auch dann sicher Ergebnisse liefert, wenn ein Wert nicht verfügbar war. AutoIT mag es nämlich gar nicht, wenn eine Variable nicht deklariert und mit einem passenden Wert (der aber ohne weiteres 0 oder "" sein kann) gefüllt ist. Die SQLite DB füllt leere Felder automatisch mit "Null" auf, so das hier nichts passieren kann. Deswegen sollte der neue Buddy deutlich stabiler und sicherer laufen. Und aus demselben Grund dauert der Start jetzt etwas länger, da SQLite einen Moment zum initialisieren benötigt. Dafür habe ich mir rund 10.000 Zeilen Programmcode gespart, der ausschließlich dazu diente, die unendlichen Varianten der externen Daten zu berücksichtigen und Abstürze deswegen zu verhindern. Der Quellcode ist deutlich kürzer als der vom alten Buddy, hat aber mehr als doppelt so viel "Nutzinhalt"... Das ist ausschließlich der Verwendung von SQLite und somit der drastischen Reduzierung des Fehlerhandlings geschuldet.

 

[BlueMax1916]

Hi.

Nur im Arbeitsordner des MKV Buddy nicht weil da immer nur ein FIlm reinkommt, der dann getagged wird.

Genau das ist eigentlich nicht der Sinn vom MKV Buddy, auch wenn man durchaus so damit arbeiten kann. Er ist gedacht, um viele Filme auf einmal zu verarbeiten. Zum individuellen Aufarbeiten von Videos gibt es viele andere Tools, die aber alle kläglich versagen oder extremst umständlich zu bedienen sind, wenn es um "Massenproduktion" geht...

Die bestehende Filmsammlung auf dem Server soll noch getagged werden. Neue Filme tagge ich erst lokal in einem Arbeitsordner bevor sie auf den Server verschoben werden. Vorher werden sie mit XMediaRecode von .ts in .mkv umgewandelt. Der MKV-Buddy dient bei mir allein zum taggen.

Meine derzeit zu 99% ungetaggte Filmsammlung möchte ich direkt in deren Ablageordnerstruktur taggen, dazu möchte ich eigentlich nur jeweils eine .nfo nach meinem Namensschema sowie die IMDB Nummer darin erstellen.

Die .nfo bekommt automatisch den gleichen Namen wie der Film sofern du in den Settings "{movie}.nfo", also den voreingestellten Wert, gesetzt hast. Durch die tt Nummer im Namen sollte der Film auf alle Fälle richtig erkannt werden, ohne das vorher eine .nfo erstellt worden ist. Auch das Problem mit den temporären Ordnern ist keines, da du ja alle Filme bereits in Unterordnern hast. Das müsste eigentlich direkt so funktionieren ohne das du irgendwas ändern musst. Außerdem kann man das Umbenennen ja ganz abschalten, was ich dir für das Aufarbeiten deiner fertigen Sammlung sowieso empfehlen würde. Die .nfo bekommt trotzdem den passenden Namen...

Nur bei neuen Filmen musst du den Ordner selbst manuell umbenennen, denn es gibt bei dir einige Eigenheiten im Namensschema, die sich nicht umsetzen lassen und auch beim alten Buddy nie funktioniert haben können. Für die Namensgebung kann man nämlich nur Werte aus der .nfo Datei und feste Texte/Buchstaben verwenden. In der .nfo steht das Land, das Jahr und auch das Genre drin, aber keine Informationen über das eigentliche Video, also Sachen wie Codec usw. Die kann man also nicht zum Umbenennen verwenden und das ging auch nie. Deswegen kann der Buddy keine Ordner nach solch einem Schema erstellen:

"Rocky Balboa (Sport USA 2006 93 min MKV H.264 HDTV 720p 1280x692 AC3 5.0)".

Sport USA 2006 würde gehen (sofern die nfo das so drin stehen haben). Aber der Rest geht nicht. Mal ab davon, 5.0 ist eher sehr exotisch, müsste das nicht 5.1 sein? Vorhandene Unterordner werden aber nicht geändert, weswegen das Grabben und Taggen funktionieren sollte ohne etwas zu verändern.

Der MKV-Buddy erkennt die in meinem für die .mkv Datei vorgegebenen Namensschema die IMDB Nummer nicht. Deswegen entweder .nfo Datei mit gestrippten XML-Tags und einem Eintrag für die IMDB Nummer in <ID> ...</ID> oder die .mkv Datei umbenennen, so dass nur die IMDB Nummer drinsteht, was für die bestehende Filmsammlung zu zeitaufwändig ist. Ich hätte gar keinen Stress damit wenn der MKV-Buddy die IMDB Nummer in meinem Namensschema erkennen würde aber das tut er auch in V2.0 nicht.

Ordner erstelle ich immer manuell, das soll der MKV-Buddy bei mir auch gar nicht.

Da das mit der 'leeren' .nfo schon funktioniert hat wräe das super wenn das wieder gehen würde.

Sollte das wirklich funktioniert haben, was ich bezweifele, dann war das ein Bug, den ich nicht reproduzieren und durch die neue interne Struktur vom Buddy 2.0 auch nicht wieder einbauen kann. Dass das Hantieren mit den "leeren" .nfo sowieso komplett überflüssig ist und dir rein gar keine Vorteile bringen kann (die tt Nummer im Dateinamen ist ja schon vorhanden und bewirkt genau das, was du mit der "leeren" .nfo erreichen willst), sollte das keinerlei Nachteil sein.

Solche "leeren" nfos hätten nämlich den alten Buddy normalerweise zum Abstürzen gebracht wenn ich das nicht abfange. Der Neue Buddy liest solche Sachen immer in eine SQLite Datenbank ein, die auch dann sicher Ergebnisse liefert, wenn ein Wert nicht verfügbar war. AutoIT mag es nämlich gar nicht, wenn eine Variable nicht deklariert und mit einem passenden Wert (der aber ohne weiteres 0 oder "" sein kann) gefüllt ist. Die SQLite DB füllt leere Felder automatisch mit "Null" auf, so das hier nichts passieren kann. Deswegen sollte der neue Buddy deutlich stabiler und sicherer laufen. Und aus demselben Grund dauert der Start jetzt etwas länger, da SQLite einen Moment zum initialisieren benötigt. Dafür habe ich mir rund 10.000 Zeilen Programmcode gespart, der ausschließlich dazu diente, die unendlichen Varianten der externen Daten zu berücksichtigen und Abstürze deswegen zu verhindern. Der Quellcode ist deutlich kürzer als der vom alten Buddy, hat aber mehr als doppelt so viel "Nutzinhalt"... Das ist ausschließlich der Verwendung von SQLite und somit der drastischen Reduzierung des Fehlerhandlings geschuldet.

Leer war die .nfo ja nicht nur die XML-Tags darin hatten keinen Inhalt bis auf das <ID></ID> Tag. Und damit hat es funktioniert. War ja nur ein Workaround für das oben beschriebene Problem, dass der MKV-Buddy nur mit dem {IMDBID}.mkv Namensschema zurechtkommt.

Das Namensschema, das ich verwende (für Dateien, nicht für Ordner) kommt nicht von ungefähr, sondern ich habe mich an die Empfehlung eines Forenmitglieds gehalten, das den Filminfo+ Scraper für Moving Pictures geschrieben hat. Damit hatte ich auch über 99% Trefferquote. Deswegen ist das nun über die Jahre bei mir so gewachsen.

Aber dem von Dir oben angeführten entnehme ich, dass der MKV-Buddy die IMDB ID in meinem Namensschema auch finden sollte?
Also z.B. bei Spuren des Bösen - Racheengel (2012) (tt2199536).mkv soll er die tt2199536 rausfiltern und danach taggen?

Das wäre mir am liebsten. Aber ich muss halt sicherstellen, dass alles so funktioniert bevor ich den MKV-Buddy auf emien Filmsammlung loslasse

 

[Lehmden]

Hi.

Aber dem von Dir oben angeführten entnehme ich, dass der MKV-Buddy die IMDB ID in meinem Namensschema auch finden sollte?

Ja, sollte er auf alle Fälle. Falls wieder Erwarten doch nicht, wird da umgehend nachgebessert. Probiere es einfach mal mit ein paar Filmen aus.

Vorher werden sie mit XMediaRecode von .ts in .mkv umgewandelt. Der MKV-Buddy dient bei mir allein zum taggen.

Darf ich fragen, warum? Die Transkoding Engine von XMediaRecode und MKV Buddy (sprich Handbrake) ist die selbe (wie bei eigentlich allen freien Transkodierungs- Tools). Qualitative Unterschiede gibt es deswegen nicht. Nur das Handbrake (und damit MKV-Buddy) zumindest auf Intel Systemen dramatisch schneller ist (sein kann), da die GPU zum kodieren verwendet wird (werden kann). Früher habe ich auch XMediaRecode verwendet und fand es gut, doch das ist schon lange her. Der MKV-Buddy ist um ein vielfaches bequemer zu bedienen. Und der Vorteil bei der Kodierungsgeschwindigkeit liegt auf meinem nicht langsamen i5 System beim Faktor 4. Also geht das Kodieren vier mal so schnell mit QuickSync als wenn die CPU das Kodieren übernehmen muss. Nette Nebeneffekte: die CPU Last bleibt niedrig, die CPU wird nicht so heiß, der Lüfter dreht niedriger und macht weniger Lärm und der Stromverbrauch liegt spürbar niedriger zum einen weil die Last deutlich kürzer erzeugt wird und zum anderen weil die GPU unter Last im Verhältnis zur CPU den Stromverbrauch nicht so hoch treibt...

Das Namensschema, das ich verwende (für Dateien, nicht für Ordner) kommt nicht von ungefähr, sondern ich habe mich an die Empfehlung eines Forenmitglieds gehalten, das den Filminfo+ Scraper für Moving Pictures geschrieben hat. Damit hatte ich auch über 99% Trefferquote.

Das Schema mag ideal für Filminfo+ sein. Darum muss es noch lange nicht ideal für die Such- Algorithmen anderer Tools sein. Z.B. bei MP2 erreicht man eine 100% Trefferquote, und das obwohl es völlig belanglos ist, wie die Dateien heißen, sofern sie nur getaggt sind. Aber alles in allem ist das sicher ein Schema, mit dem viele Tools gut zurecht kommen sollten.

Mir würde das aber ganz sicher nicht gefallen, ist mir viel zu viel Gedöhns, was eigentlich nichts mit dem Film zu tun hat, im Namen integriert. Bei mir heißt der Film "Jurassic World.mkv" und der Ordner "Jurassic World (2015)". Das Jahr habe ich auch nur in den Ordnernamen mit übernommen, weil es ja häufig Filme gibt, die gleich heißen z.B. "Godzilla" von 1998 und 2014. Das Erscheinungsjahr hat dann wenigstens wirklich etwas mit dem Film an sich zu tun und ist kein "Internet- Hilfswert" wie etwa die IMDB- ID Nummer... Den Film und sein Erscheinungsjahr gäbe es ohne die IMDB- ID auch, aber die Nummer niemals ohne den Film...

Anfänglich hatte ich immer eine "IMDBID.txt" mit der tt Nummer drin, im Filme- Ordner liegen, die von MovingPictures erkannt wurde und zum Identifizieren genutzt wurde. Später bin ich dann auf .nfo umgestiegen, die ich heute noch nutze. Allerdings sind heute im MP2 Zeitalter die .nfo nicht mehr nötig, um die Filme zu identifizieren. Das geschieht absolut sicher über die Matroska Tags. Die .nfo sind dazu da, die Datenbank- Felder so zu befüllen, wie ich mir das vorstelle....

 

[Kasselhöfer]

Hi @Lehmden
Heute hab ich mal wieder mit dem Buddy eine Aufnahme umkodiert. Leider friert mit Intel QS der PC (Win10) komplett ein, nur der Reset-Schalter hilft noch. "Normal" h.264 mit DXVA funktioniert problemlos, dauert allerdings etwas.
Hast du eine Idee, woran das liegen könnte?
Gruß
Helios

Hallo,
ich habe genau das gleiche Problem

Ich hatte auch Probleme mit Handbrake, QS und Win10. Ich habe dann die letzte Nightly installiert und nun geht es.
Wäre zumindest eine Idee, sofern du eh nicht schon die Nightly einsetzt

Ich habe die HandBrake-0.10.2-793-466fabc-master-x86_64-Win_CLI.zip runter geladen, entpackt und die darin enthaltene HandBrakeCLI.exe nach MKV_Buddy kopiert und die alte dadurch ersetzt. Leider brachte das bei mir keinen Erfolg. Habe ich etwas falsch gemacht? Hat jemand das Pronlem lösen könne?
Gruß
Andreas

 

[Lehmden]

Hi.
Windows 10 hat massive Grafikkarten- Treiber Probleme, sowohl mit Intel als auch und besonders mit AMD. Am wenigsten ist wohl NVidia betroffen, aber genau weiß ich das nicht.
Handbrake greift auf die GPU Hardware zu um das Kodieren zu beschleunigen. Daraus resultiert, das es unter Win10 häufig zu Problemen kommt, nicht nur mit Handbrake, sondern mit vielen Programmen, die die GPU Hardware verwenden. Eigentlich sollte die neueste Version von Handbrake unter Win10 funktionieren. Steht auch so auf deren Webseite.

Current Version: 0.10.2
...
Windows For Windows Vista to 10
Download (64 bit)
Download (32 bit)

Wenn das auf bestimmten Systemen immer noch nicht der Fall ist, kann ich leider gar nichts tun, da ich keinen Einfluss auf die Entwicklung von Handbrake habe... Übrigens sind ausnahmslos alle Fehlermeldungen im Handbrake Forum letztendlich auf die Grafik- Treiber zurückgeführt worden.
Die erste Option ist also zu prüfen, ob es neue (ggfs auch Beta) Treiber für deine Grafikkarte (egal ob integriert in der CPU oder nicht) gibt und diese dann auszuprobieren. Danach kann man jeden Tag eine neue Nightly von Handbrake laden (das bedeutet Nightly nämlich, es gibt jeden Tag eine neue aber ungetestete Version) und so lange probieren, bis man eine lauffähige Version erwischt hat. Traurig, aber leider nicht unüblich bei Windows Betriebssystemen...

Ich weiß genau, warum ich jetzt noch nicht auf Win10 umsteige. Win10 ist einfach noch nicht wirklich fertig und die User werden als Beta Tester missbraucht. Mein genereller Tipp ist also, Windows 10 erst mal zurückzustellen und zu warten, bis es halbwegs stabil funktioniert.

 

[BlueMax1916]

Hi.

Aber dem von Dir oben angeführten entnehme ich, dass der MKV-Buddy die IMDB ID in meinem Namensschema auch finden sollte?

Ja, sollte er auf alle Fälle. Falls wieder Erwarten doch nicht, wird da umgehend nachgebessert. Probiere es einfach mal mit ein paar Filmen aus.

O.k. ich versuche es noch mal.

Vorher werden sie mit XMediaRecode von .ts in .mkv umgewandelt. Der MKV-Buddy dient bei mir allein zum taggen.

Darf ich fragen, warum? Die Transkoding Engine von XMediaRecode und MKV Buddy (sprich Handbrake) ist die selbe (wie bei eigentlich allen freien Transkodierungs- Tools). Qualitative Unterschiede gibt es deswegen nicht. Nur das Handbrake (und damit MKV-Buddy) zumindest auf Intel Systemen dramatisch schneller ist (sein kann), da die GPU zum kodieren verwendet wird (werden kann). Früher habe ich auch XMediaRecode verwendet und fand es gut, doch das ist schon lange her. Der MKV-Buddy ist um ein vielfaches bequemer zu bedienen. Und der Vorteil bei der Kodierungsgeschwindigkeit liegt auf meinem nicht langsamen i5 System beim Faktor 4. Also geht das Kodieren vier mal so schnell mit QuickSync als wenn die CPU das Kodieren übernehmen muss. Nette Nebeneffekte: die CPU Last bleibt niedrig, die CPU wird nicht so heiß, der Lüfter dreht niedriger und macht weniger Lärm und der Stromverbrauch liegt spürbar niedriger zum einen weil die Last deutlich kürzer erzeugt wird und zum anderen weil die GPU unter Last im Verhältnis zur CPU den Stromverbrauch nicht so hoch treibt...

Ich stehe auf maximal erzielbare Qualität bei minimaler Größe. Das erreiche ich mit CPU Transcodierung - da kann die GPU Transcodierung noch nicht mithalten - und mit den entsprechenden Einstellungen in XMedia Recode wobei extra lange an einem Film gerechnet wird. Also entgegen den Prinzipien des GPU Transcodierens. Dann dauert es halt länger aber es läuft bei mir immer über Nacht wenn ich sowieso schlafe. Ich habe das mit GPU Transcodierung mal ausprrobiert aber die arbeitet für meinen Geschmack so schlampig, dass das Ergebnis verbesserungswürdig ist. QuickSync ist ganz nett und ganz ohne dedizierte Grafikkarte und nur mit integrierter GPU das einzig vernünftige um Videos darzustellen, aber ich verwende beispielsweise eine dedizierte Nvidia Grafikkarte im HTPC. Beim Nächsten vermutlich aber dann nicht mehr weil der möglichst klein werden soll. Mein HTPC ist aus 2011. Damals hat die iGPU beispielsweise auch noch den 24Hz Bug gehabt.

Wenn das Ausgangsmaterial qualitativ besser ist dann ist der qualitativ schlechteren Darstellung mit QuickSync wenigstens etwas entgegengewirkt. So meine Denkweise.

Das Namensschema, das ich verwende (für Dateien, nicht für Ordner) kommt nicht von ungefähr, sondern ich habe mich an die Empfehlung eines Forenmitglieds gehalten, das den Filminfo+ Scraper für Moving Pictures geschrieben hat. Damit hatte ich auch über 99% Trefferquote.

Das Schema mag ideal für Filminfo+ sein. Darum muss es noch lange nicht ideal für die Such- Algorithmen anderer Tools sein. Z.B. bei MP2 erreicht man eine 100% Trefferquote, und das obwohl es völlig belanglos ist, wie die Dateien heißen, sofern sie nur getaggt sind. Aber alles in allem ist das sicher ein Schema, mit dem viele Tools gut zurecht kommen sollten.

Mir würde das aber ganz sicher nicht gefallen, ist mir viel zu viel Gedöhns, was eigentlich nichts mit dem Film zu tun hat, im Namen integriert. Bei mir heißt der Film "Jurassic World.mkv" und der Ordner "Jurassic World (2015)". Das Jahr habe ich auch nur in den Ordnernamen mit übernommen, weil es ja häufig Filme gibt, die gleich heißen z.B. "Godzilla" von 1998 und 2014. Das Erscheinungsjahr hat dann wenigstens wirklich etwas mit dem Film an sich zu tun und ist kein "Internet- Hilfswert" wie etwa die IMDB- ID Nummer... Den Film und sein Erscheinungsjahr gäbe es ohne die IMDB- ID auch, aber die Nummer niemals ohne den Film...

Anfänglich hatte ich immer eine "IMDBID.txt" mit der tt Nummer drin, im Filme- Ordner liegen, die von MovingPictures erkannt wurde und zum Identifizieren genutzt wurde. Später bin ich dann auf .nfo umgestiegen, die ich heute noch nutze. Allerdings sind heute im MP2 Zeitalter die .nfo nicht mehr nötig, um die Filme zu identifizieren. Das geschieht absolut sicher über die Matroska Tags. Die .nfo sind dazu da, die Datenbank- Felder so zu befüllen, wie ich mir das vorstelle....

Das Dateinamensschema habe ich vor Jahren angefangen als es noch keine vernünftige Verwendung für .nfo Dateien bzw. .mkv Tagging gab und weil unter MP1 Moving Pictures die angesagte Filmdatenbank war. Es gab ja nichts besseres. Jetzt im Hinblick auf die bei mir in Zukunft stattfindende Migration zu MP2 muss ich halt die .mkv alle nachträglich taggen. Wenn man immer alles vorher wüsste wäre man ja Lotto-Millionär Das ist ja letztendlich auch eine Sache, die vom MP Entwicklerteam nicht von vorne herein mit bedacht wurde. Deswegen gab es ja so 'Krücken' wie Moving Pictures Und MyTVSeries. Und auch jetzt ist die Implementierung in MP2 ja noch nicht richtig fertig.

Dank Dir gibt es aber den MKV-Buddy und ich muss halt schauen wie ich in meiner Situation damit für mich am besten umgehen kann.

 

[Lehmden]

Hi.

Ich stehe auf maximal erzielbare Qualität bei minimaler Größe. Das erreiche ich mit CPU Transcodierung - da kann die GPU Transcodierung noch nicht mithalten.

Das mag bei deiner Hardware noch der Fall sein. Bei meinem Haswell mit HD4600 ist definitiv kein Unterschied (mehr) feststellbar. Außerdem ist mir das TV Material in aller Regel sowieso zu schlecht, um da anspruchsvoll zu sein... Ist doch meist nur eine Notlösung, bis man "richtige" Qualität (BD oder HD Downloads/Streams) auftreiben kann.

Dann dauert es halt länger aber es läuft bei mir immer über Nacht wenn ich sowieso schlafe.

Ganz ehrlich, da ist es garantiert viel billiger, fleißig externe HDD zu kaufen als den vielen Strom für das langwierige Umkodieren zu verpulvern. Ein Ummuxen der TV Aufnahmen nach MKV ist ja blitzschnell erledigt, und das garantiert ohne Qualitätsverlust. Ein GByte kostet zur Zeit ca 2,5 Cent. Du musst also mit einer KwH ca 12 Gigabyte einsparen um nicht teurer zu sein. Ein System von 2011 benötigt unter Vollast ca 100 bis 150 Watt (grob geschätzt, aber mit dedizierter Grafikkarte ist das durchaus realistisch). Du musst also in ca 10 Stunden 12-15 GByte eindampfen, was bei deiner Umrechnungsgeschwindigkeit wohl kaum zu erreichen sein wird. Bei mir läuft das Umkodieren nebenbei, wenn ich sowieso am Rechner sitze und kostet mich demzufolge so gut wie gar nichts.

Man sollte keinesfalls die Betriebskosten für ein laufendes System unterschätzen. Ich zahle aktuell über 40€ monatlich!!! (also fast 500€ pro Jahr) weniger an Strom als noch vor 2 Jahren mit dem alten System, welches auch dauernd die Nächte durch gelaufen ist, um das langwierige Recodieren zu absolvieren. Außer meiner Computer Hardware und dem daraus resultierenden anderem Umkodierungs- Verhalten hat sich an meinem Stromverbrauch nichts geändert. Mal abgesehen davon, das der Strom eigentlich teurer geworden ist und ich demzufolge eher mehr bezahlen müsste... Für 500€ bekommt man locker über 10 TByte an externen Festplatten (und das jedes Jahr)...

 

[BlueMax1916]

Hallo Lehmden,

ich habe nochmals die Erkennung der IMDB Nummer im Dateinamen getestet und bei mir erkennt der MKV-Buddy diese nicht. Habe auch mal die Datei in einen eigenen Unterordner im Arbeitsordner verschoben. Ebenfalls Fehlanzeige. Einmal hat er außerhalb dieses Unterordners im Arbeitsordner direkt eine .nfo Datei erzeugt, die {IMDB}.nfo hieß also die nur die IMDB Nummer im Namen hatte. Das heißt für mich er hat bei diesem Durchlauf die IMDB Nummer aus dem Dateinamen der .mkv zumindest mal ausgelesen. Aber die .nfo Datei war leer. Auch Backdrops, Cover etc. hat er nicht heruntergeladen.

Ich werde mal weiter testen.

Gruß

BlueMax

 

[Lehmden]

Hi.
Darum kümmere ich mich morgen. Heute war ich den ganzen Tag unterwegs. Das muss einfach funktionieren...