Posts by Lehmden1

Quote from darkside40

im gegensatz zu Alkohol jedoch auch mit einem therapeutischen Nutzen.

Ich trinke so gut wie nie Alkohol. Aber das mit dem nicht vorhandenen therapeutischen Nutzen bei Alkohol ist nicht so ganz wahr. Ich habe einen manchmal sehr starken Tremor (Zittern) in meinen Händen. Sowohl mein Hausarzt als auch ein Facharzt (Neurologe), den ich konsultiert habe, haben mir unabhängig voneinander Alkohol zur Bekämpfung des Zitterns empfohlen. Außer Alkohol helfen nur Betablocker. Da ich wegen meiner Herzprobleme sowieso schon Betablocker nehmen muss, bleibt als einziges Mittel Alkohol übrig. Ich soll mich natürlich nicht volllaufen lassen, aber so ein, zwei Gläschen helfen durchaus. Das Problem ist, wenn ich zum Basteln wirklich ruhige Hände brauche, darf ich eigentlich nicht beschwipst sein, da das ähnlich wie das Zittern, die Ergebnisse negativ beeinflusst.

Aber Cannabis hat schon mehr medizinische Anwendungen als Alkohol, keine Frage.

Alles ist schneller, viel schneller. Der Start des Programms selbst ist viel flotter. Die Navigation wird massiv beschleunigt, Videos starten sofort, so schnell, das ich mich am Anfang richtig erschrocken habe weil die Wiedergabe schon losgeht, bevor ich den Knopf auf der Fernbedienung überhaupt loslassen konnte. Sachen aus dem Cache sind in Echtzeit auf dem Schirm, Listen mit vielen Tausend Einträgen werden so schnell aufgebaut, das man keinerlei Verzögerung spüren kann, die Reaktion auf Tastendrücke, wirklich alles ist deutlich schneller. Es fühlt sich irgendwie fast so an als ob das System meine Gedanken lesen kann und die Befehle schon ausführt, während ich noch dran denke, die entsprechende Taste drücken zu wollen.

Und dieses Gefühl ist bis heute noch nicht verschwunden, obwohl ich den Pi 5 mit NVMe schon seit Mitte Oktober 2024 am Laufen habe. Normalerweise gewöhnt man sich ja sehr schnell an ein schnelleres System und spürt die Verbesserungen nicht mehr (so stark). Aber hier ist das wirklich anders. Vielleicht weil ich ja noch andere Kodi Instanzen habe, die durch die Bank weg erheblich langsamer sind und ich so ständig die extreme Geschwindigkeit im Vergleich zu den anderen Kisten merke. Es wird offenbar permanent auf dem Systemlaufwerk herum gerödelt, wenn Kodi am Arbeiten ist. Die 64 Bit Umgebung und das (relativ) viele RAM des RasPi5 können es alleine nicht ausmachen, denn sonst müsste Kodi auf meinem i5 noch mal deutlich schneller sein. Tatsächlich ist es dort aber langsamer. Was dann wohl an Windows 11 vs. LibreElec liegen dürfte, denn ein Core i5 mit 32 GB RAM von NVMe sollte eigentlich deutlich schneller sein als ein Pi 5 mit 8GB RAM von NVME. Ist er mit Kodi aber nicht, im Gegenteil.

Dabei kommen die Medien immer von demselben NAS und die Datenbank ist auch immer exakt dieselbe MariaDB auf einem Windows 10 Mini PC für alle meine Kodi Instanzen. Das kann also auch nicht der Grund für den Geschwindigkeitsrausch sein.

Bitte nicht falsch verstehen, der RasPi5 ist auch von SD Karte eine flotte Kodi Kiste, keine Frage. Aber der Warp Antrieb wird erst aktiviert, wenn man von NVMe bootet.

Quote from Kvert

ich wollte aber vom Kabel TV Abo auf Magenta IPTV umsteigen.

Wenn du das Magenta Abo noch nicht abgeschlossen hast oder noch problemlos kündigen kannst, lass Magenta TV sausen und nimm lieber Zattoo als IPTV Anbieter. Das kannst du per Telerising in TVHeadend, DVB-Viewer, TVMosaic, NextPVR o.ä. einbinden und somit problemlos aufnehmen, genau wie bisher von DVB-C. Magenta TV wird, so weit ich weiß, von Telerising genau so wenig unterstützt wie Waipu (da weiß ich sicher, das es nicht geht).

Quote from te36

Macht das Leben eh leichter, wenn auf der SSD nur eine Datenpartition ist.

Ich habe beides mit meinem RasPi 5 selbst ausprobiert, LE auf SD Karte und LE auf NVMe. Deswegen sehe ich das ganz anders. Das "Leben" wird dadurch sehr viel zäher, aber sicherlich nicht leichter. Kodi bekommt einen wahnsinnigen Boost, wenn das System von NVMe startet und dort auch alles installiert wurde. Ich habe eine Kodi Installation unter Windows 11 auf einem 11. Gen Core i5 mit 32 GB RAM und trotzdem ist Kodi auf dem RasPi 5 mit 8 GB sehr viel schneller, aber nur, wenn LE auf der NVMe installiert wurde. Von SD Karte gebootet ist von dem Geschwindigkeitsrausch nämlich gar nichts mehr übrig. Dann ist Kodi genau so träge und lahm, wie auf anderen Geräten. Von SD bringt der Pi 5 nur noch den Vorteil, das er mit LE so unglaublich stabil läuft. Von NVMe hingegen läuft Kodi nicht nur unglaublich stabil sondern auch unglaublich schnell.

Aber auf jeden Fall würde ich das ComputeModule 5 mit IO-Board einem RasPi 5 mit NVMe HAT vorziehen. Leider gab es das noch nicht, als ich meinen Pi5 gekauft habe. Die 8 GB RAM Variante (die ich bevorzugen würde) gibt es bis heute noch nicht als CM5, ist bisher nur angekündigt. Aber zumindest steht der Preis schon fest. Er wird mit IO-Board etwas günstiger als der 8GB Pi 5 mit NVMe Hat. Dafür muss man dann für Gehäuse und CPU Kühler zusammen etwas mehr ausgeben als beim Pi5. In der Summe tut sich das überhaupt nichts. Aber dafür hat man anständige HDMI Anschlüsse, eine NVMe Schnittstelle ohne das fummelige Flachbandkabel und eine frei zugängliche SD Karte. Die Vorteile empfinde ich als so groß, das ich höchstwahrscheinlich mein Kodi System im Lauf des Jahres auf so ein CM5 umstellen und den vorhandenen RasPi 5 für etwas anderes nutzen werde.

Hi.

Ich ärgere mich grade mal wieder über den dusseligen Requester beim Herunterladen der aktuellen Widewine CDM. Das dauert bei meinem lahmen Internet immer weit über eine Stunde. In der Zeit ist Kodi völlig blockiert, da man das Ding nicht in den Hintergrund bekommt, um derweil z.B. lokale Dateien abzuspielen. Es gibt ja nur "Abbrechen" zur Auswahl. Das verbietet sich natürlich von selbst. Wenn man den Requester mit dem Back- oder Home- Button verlässt, bricht der Download ebenfalls sofort ohne Nachfrage ab. Das betrifft alle Operationen, die diesen nervenden Requester öffnen, nicht nur den CDM Download. Grade so potentiell sehr lange laufende Operationen muss man doch zwingend im Hintergrund ausführen können, finde ich. Bei dem dusseligen Requester ist man aber völlig aufgeschmissen. Oder gibt es da einen Trick, den ich noch nicht kenne? Wäre super, falls dem so wäre.

Ach, wenn man ohnehin ein Linux auf SD Karte für den Pi braucht, um den Bootloader zu aktualisieren, sollte man dort, nachdem der Bootloader aktualisiert wurde, auch unter Linux die NVMe mit LibreElec bespielen können. Das habe ich nicht selbst ausprobiert, müsste eigentlich aber funktionieren. Dann kann man sich den NVMe auf USB Adapter vorerst sparen, auch wenn das eigentlich eine sinnvolle Anschaffung ist, unabhängig von der Pi Installation.

Hi.

LE wird in der Regel ja auf einem Desktop oder Laptop mit Hilfe einer Software auf eine SD Karte installiert. Dazu muss man einen Kartenleser am System haben. Der kann fest eingebaut sein oder per USB als externes Gerät angeschlossen werden. Genau so funktioniert es auch, wenn man LE auf die NVMe installieren will. Auch die muss irgendwie an dem System, auf dem man das aufspielen will, angeschlossen sein. Man kann die NVMe in einen freien Platz auf der Hauptplatine montieren, sofern da noch ein M.2 Steckplatz frei ist. In den meisten Fällen dürfte der M.2 Steckplatz aber schon belegt sein. Dann braucht man einen M.2 nach USB Adapter, genau so wie es sonst auch mit externen HDD funktioniert. Ich hatte vorher schon eine externe NVMe für USB 3.1, als ich den Pi5 aufgesetzt habe. Um die kleine NVMe (normal ist da ein 2TB Laufwerk drin, für den Pi5 habe ich eine 500 GB NVMe verwendet) nun beschreiben zu können, habe ich die 2 TB Platte kurzfristig ausgebaut und das Pi Laufwerk eingebaut. So ein externes NVMe Gehäuse ist heutzutage keine Geldverschwendung, da die NVMe doch inzwischen sehr verbreitet sind. Die gut 10€ dafür sind, ganz unabhängig von der Pi5 Installation gut angelegtes Geld. Sowas wird man in Zukunft immer wieder mal brauchen.

Die Original Software von LibreElec erkennt keine NVMe als Installationsmedium, weswegen man eine "Fremd- Software" verwenden muss. Das kann wie schon erwähnt Etcher sein. Ich selbst habe Rufus verwendet. Es gibt aber noch zig andere Programme für alle Systeme (man ist also nicht auf Windows angewiesen). Nutzt man die Original- Software, wird bei der Installation die komplette SD Karte für LE in Beschlag genommen. Fremd- Software macht das selbstverständlich nicht. So ist die Haupt- Partition erst mal nur winzig, da das Image auch auf eine 1 GB SD Karte aufzuspielen sein muss. Das wäre natürlich viel zu wenig für den tatsächlichen Betrieb. Aber beim ersten Start von LE wird diese Mini- Partition automatisch auf den ganzen freien Speicherplatz erweitert. Es ist also kein Problem, kein Nachteil hier andere Software zu verwenden.

Die größte Schwierigkeit ist dabei, das es sein kann, das der Pi 5 einen älteren Bootloader in der Firmware installiert hat, welcher nicht in der Lage ist, von NVMe zu booten. Um den aktualisieren zu können, muss man zunächst irgendein OS für den Pi 5 auf irgendeine SD Karte schreiben, davon starten und den Bootloader aktualisieren. Das kann PI OS sein (Lite sollte reichen) oder sogar LibreElec. Unter LibreElec kann man ebenfalls den Bootloader aktualisieren. Mit einem "richtigen" OS kann man auch noch mehr konfigurieren wie etwa die Bootreihenfolge, was unter LE nicht möglich ist. Das beschleunigt den Systemstart, wenn hier die NVMe als erstes Boot Laufwerk eingerichtet wird, da nicht mehr nach SD Karten usw. gesucht wird. Allerdings kann man so nicht mal eben temporär von einer SD Karte oder einem USB Stick booten. Kann man also machen, muss man aber nicht. Nur um die Aktualisierung des Bootloaders wird man nicht herum kommen, sofern noch der ältere Bootloader vorinstalliert ist...

Quote from psychofaktory

Gab es nicht mal die Möglichkeit MagentaTV, Waipu bzw. Zattoo in TVHeadend einzubinden?

Magenta weiß ich nicht, Waipu geht ganz sicher nicht, da verschlüsselt, aber Zattoo läuft über Telerising. Das kann man dann in einer "normalen" TV Lösung weiter verwenden und auch aufnehmen. TVHeadend ist da nur eine von vielen Lösungen. Es geht auch mit IPTV Simple (nur zum schauen), TVMosaic, NextPVR, DVB-Viewer, VDR,... eigentlich alles, was eine m3u für IPTV verarbeiten kann. Man muss sich nur selber um das EPG kümmern. Das wird nicht mit durchgereicht.

Bei Waipu habe ich noch nie Probleme mit dem schwarzen Schirm gehabt. Aber ich habe auch noch kein RTL HD per Screen- Recording aufgenommen. Dafür habe ich Telerising... Allerdings nehme ich von RTL sowieso fast nie was auf, außer wenn die ausnahmsweise mal Formel 1 übertragen. Aber da reicht mir die Cloud Aufnahme von Waipu, denn die Rennen schaue ich mir nicht mehrfach an.

Apropos gehackte Tomaten... Diese Woche gibt es bei Edeka (zumindest bei unserem) grade 12 Dosen gehackte Tomaten für 6€. Ich werde das aber auslassen, da ich noch reichlich Dosen vom letzten Mal (damals von Netto) im Regal stehen habe. Die sollten locker reichen bis zum nächsten Angebot, welches dann vielleicht nicht grade, wenn ich völlig pleite bin (hab diesen Monat zu viel Geld in meine Hardware gesteckt), auftaucht...

Wer aber keine Vorräte hat, dem kann ich wirklich empfehlen, sich so einen 12er Pack anzuschaffen. Die Dosen halten sehr viele Jahre und den Inhalt kann man perfekt zum Kochen verwenden. Inhalt in einen Topf geben, Kräuter, Gewürze und eine Priese Zucker nach Gusto dazu geben, heiß machen und zu Pasta servieren. Super einfach, super schnell, super günstig, vegan (sofern die Pasta vegan ist) und schmeckt köstlich. Aber man kann natürlich auch tausende anderer Rezepte damit zubereiten, nicht nur Pasta Soße...

Quote from PvD

entweder einen Parser selbst baut (urgs)

Das hab ich in Media-Buddy gemacht da die für AutoIt verfügbaren XML Parser nicht anständig funktionierten (vielleicht ja genau wegen dem fehlerhaften "Kodi-XML", weiß nicht mehr, ist zu lange her). Für andere Sachen, wo ich das verwendete Format selbst in der Hand habe, nutze ich dann .json. Da funktioniert der Parser wenigstens einwandfrei. Doch hier muss es eben das Kodi- .nfo Format sein.

Wenn man die XML (den Inhalt generell) von der Struktur her kennt, geht das ziemlich leicht mit String Operationen (StringBetween, StringReplace, usw.) Nur bei "fremden" XML deren Struktur man nicht kennt, wird es sehr viel schwieriger. Damit haben wir hier aber nichts zu tun, da die .nfo immer gleich aufgebaut sind.

Ich würde das in etwa so lösen. Den Inhalt der .nfo als einen großen String einlesen. Dabei ist es völlig egal, ob die Datei "echtes" XML ist oder nicht, so lange sie als String gelesen werden kann. Dann die Bereiche zwischen <watched> und </watched>, <lastplayed> und </lastplayed> sowie <playcount> und </playcount> einfach per StringReplace durch die aktuellen Werte austauschen. Gibt es diese Bereiche nicht, würde ich

"</episodedetails>"

durch folgendes ersetzen:

" <watched>true</watched>
<lastplayed>2025-01-12 15:49:20</lastplayed>
<playcount>1</playcount>
</episodedetails>"

und dann das Ganze als String wieder zurück in die .nfo Datei schreiben. Ganz so, wie man es beim manuellen Editieren per Text Editor ja auch machen würde. Ist vermutlich einfacher, als die ganze .nfo als XML auszuwerten, da man sich nur um die winzigen Bereiche kümmern muss, die man anpassen will. Und so funktioniert das auch mit den "falschen" Kodi- XML Dateien. Wobei ich nicht weiß, ob es (etwas adäquates zu) StringReplace und StringBetween in Python gibt und ob das da auch so funktioniert. Ist leider keine Sprache, die ich beherrsche.

Quote from PvD

bei Mehrfachepisoden ist das doch korrekt (mehrere Episoden in einer Datei)?

Nein, ist es leider nicht, da dann die von "Watchedstate NFO Updater" erzeugten Einträge nicht mehr innerhalb der "<episodedetails>" liegen sondern nach dem letzten "</episodedetails>" und vor dem abschließenden Wurzeltag (wie auch immer der benannt wurde) und deswegen von Kodi nicht eingelesen werden. Kodi liest nur das ein, was zwischen <episodedetails> und </episodedetails> liegt. Es reicht aber wohl aus, wenn der Playcount nur bei einer der Episoden eingefügt wird, egal bei welcher. Das habe ich zwar noch nicht 100% durchgetestet, es macht aber bisher diesen Eindruck.

Quote from PvD

wenn die Wurzel des Übels im wahrsten Sinne an multiplen Wurzeltags liegt. Das ist schlicht nicht xml-konform.

Ja, ich weiß. Das ist nur leider genau so im Wiki beschrieben und es funktioniert auch genau so in Kodi, ist aber kein XML mehr. Es wird ja auch nie behauptet, das die Kodi .nfo "echte" XML Dateien sind. Das ist ein Kodi- eigenes Format, das sich quasi zum Standard für solche Metadaten- Dateien entwickelt hat und von anderen HTPC Programmen übernommen wurde. Selbst die Dateiendung ist ungeschickt gewählt, da .nfo eigentlich Systeminformationsdateien sind, zumindest in der Windows Welt. Aber wir müssen halt alle mit dem leben, was uns da von Kodi vorgesetzt wurde.

Ich muss noch mal ausprobieren, wie Kodi inzwischen selber die .nfo solcher Mehrfachfolgen exportiert. Wie gesagt, als wir das vor vielen Jahren so implementiert hatten, ging es nicht anders. Aber das war noch zu XBMC Zeiten, wenn ich mich recht erinnere und wurde nie geändert, da es ja, von deinem Addon abgesehen, bisher einwandfrei funktioniert hat. Damals funktionierte das mit dem zusätzlichen Wurzelelement, um die Datei XML Konform zu machen, eben noch nicht. Aber seit damals hat sich auch an Kodi so einiges geändert.

Quote from Rastaman

Evtl. ist Trakt Dein Freund.

Nein, ist es nicht. Die können jederzeit die Tür zusperren und man steht ohne Sicherung da. Es gab früher mal ein alternatives Angebot zu Trakt. Ich weiß nicht mal mehr, wie das hieß, ist halt schon viele Jahre her. Das war nicht so überfrachtet mit all diesem Social Media und Community Zeugs, das ich sowieso nicht haben will sondern einfach eine Datenbank für Privatleute. War wesentlich schneller und unkomplizierter als Trakt. Das hatte ich mal statt Trakt genutzt. Eines Tages war der Dienst dann plötzlich verschwunden und mit ihm mein Backup. Was ich nicht zu Hause habe, habe ich gar nicht.

Ich habe übrigens mal ein wenig experimentiert und die .nfo per Hand modifiziert. Am Anfang habe ich ein <root> eingefügt und am Ende ein </root> Und schon ist die Datei absolut valide. Kodi liest das sogar auch problemlos ein. Somit ist daran etwas angepasst worden. Denn das zusätzliche Kapseln hatte ich vor Jahren schon mal versucht, damals aber ohne Erfolg.

Aber auch damit funktioniert das Addon nicht richtig. Es trägt dann

...

</episodedetails>
<watched>true</watched>
<lastplayed>2025-01-12 19:46:14</lastplayed>
<playcount>1</playcount>
</root>

in die .nfo ein. Einfach direkt vor dem letzten schließenden Tag. So wird das von Kodi aber nicht ausgewertet. Damit es funktioniert, muss es vor jedem Mal das "</episodedetails>" auftaucht, eingetragen werden.

Wenn die .nfo so aussieht, ist sie eine valide XML Datei, wird von Kodi akzeptiert und der Playcount wird beim Import in die DB eingelesen:

Wie gesagt, damit Kodi funktioniert, bedarf es des <root> und </root> Tags nicht. Aber nur so wird aus der .nfo eine valide XML Datei, die von jedem Parser akzeptiert wird.

Quote from PvD

In Zeile 48 der betreffenden NFO zur Episode gibt es ein Problem. In der Regel ist das eine fehlerhafte XML-Struktur (nicht abgeschlossene Tags oder ähnliches). Du kannst gerne mal die NFO hier anhängen, dann schaue ich mal rein.

Danke.

In Zeile 48 endet das erste Root Element "<episodedetails>" und das Zweite (das es laut XML Specs gar nicht geben darf, von Kodi aber verlangt wird) fängt eine Zeile später (also in Zeile 49) an. Genau das ist ja das Problem mit den Kodi .nfo bei Mehrfach- Episoden. Dort werden die Root Elemente <episodedetails> für jede in der Videodatei enthaltenen Episode einfach hintereinander gehängt, statt sie noch einmal zu kapseln um nur ein Root Element zu haben, wie es von den XML Specs verlangt wird. Dadurch sind das dann keine gültigen XML Dateien mehr und jeder "normale" XML Parser fliegt auf die Nase. Man müsste für jede Episode eine eigene, separate .nfo machen können, dann gäbe es da kein Problem. Nur leider erlaubt Kodi das nicht...

Meist handelt es sich bei solchen Doppel- Episoden um sowas wie einen Pilotfilm, der entweder als eine 90 minütige Doppelfolge ohne Unterbrechung oder als zwei separate 45 Minuten Folgen, dann mit Abspann und neuem Vorspann gesendet werden könnten. Deswegen sind solche Doppel-Folgen nur schlecht zu trennen, um daraus mehrere Einzelfolgen zu machen. Übrigens sind bei mir gut 170 solcher Doppel- Folgen im Bestand. Im Vergleich zu den fast 50.000 Serien Episoden, die ich lokal verfügbar habe, wirklich Peanuts. Trotzdem würde das schon einiges an Arbeit machen...

Die .nfo zu der für das Debug-Log abgespielten Episode "S01E01E02 - Start ins Unbekannte" aus der Serie "Zurück in die Vergangenheit" habe ich, zusammen mit ein paar Anderen (zum Vergleichen) schon in Beitrag 29 angehängt.

Post

RE: Kodi Datenbank wird nicht richtig bereinigt

Hi.

Heute habe ich meine Kodi Datenbank neu eingerichtet. Das lief so wie geplant und hat alles in allem etwa 5 Stunden gedauert. Allerdings gibt es scheinbar ein Problem mit dem Addon von PvD . Das funktioniert so weit problemlos, scheint aber nicht mit Serien- Doppelfolgen klar zu kommen. Also wenn in einer Datei zwei oder mehr Episoden stecken (und das auch im .nfo gespiegelt wird), dann wird der Playcount nicht in die .nfo geschrieben. Zum Glück sind das bei mir nicht all zu viele…

Lehmden1

January 12, 2025 at 5:57 PM

Quote from buers

Was ich mich frage: Zuvor war die Diskussion, dass die exportierten .nfo nerven, beispielsweise wegen Videoauflösung, für die immer .nfo bevorzugt wird. Reicht es nicht nach dem Import alle .nfo wieder zu löschen und dann nimmt Kodi wieder die korrekte ("zuletzt gesehene") Videoauflösung, auch wenn ein Film mal ersetzt wurde durch einen besserer Qualität?

In meinen .nfo, die nicht von Kodi, sondern von einem externen Programm erzeugt wurden, sind jede Menge individuelle Anpassungen an den Metadaten drin. Teilweise sind die Serien oder Filme Metadaten auch "frei Erfunden" sprich sie sind auf TVDB/IMDB gar nicht gelistet und haben von mir "Fake IDs" bekommen. Dank meiner .nfo werden sie aber in Kodi genau so behandelt, als wären es "echte" Filme oder Serien. Würde ich die .nfo löschen, wären alle diese Anpassungen zum Teufel, sobald ich mal etwas neu einlesen lassen muss. Also ist nix mit Löschen.

Nervig ist, das Kodi selbst, wenn man die DB in .nfo exportiert auch Sachen, die meiner Ansicht nach in den .nfo (die für die Metadaten zum Film zuständig sind) absolut gar nichts zu suchen haben, abspeichert. Sei es der Pfad zur Datei oder die Medien Infos des Videos (Codec, Auflösung,...) Das hat mit den Metadaten absolut gar nichts zu tun und deswegen auch nichts in den .nfo verloren. Und deswegern will ich das auch nicht in den .nfo haben. Speziell, da ich durchaus mal das Video austausche (weil ich eines mit besserer Qualität aufgetrieben habe), aber die Metadaten beibehalten will. Stehen die "alten" Media Infos in der .nfo kann ich die Einträge in der Datenbank niemals mehr aktualisieren, sofern ich die .nfo Datei nicht manuell editiere oder gar lösche, mit all den negativen Folgen, die es so mit sich bringt.

Der Playcount in den .nfo ist auch nur ein Kompromiss. Man muss das Ganze schon sehr großzügig auslegen, um den Gesehen Zustand als zu den Metadaten gehörend zu definieren. Lieber wäre mir ja, man müsste das so nicht machen. Aber ich habe keinen anderen, besseren Weg gefunden, die Playcounts unabhängig von der Kodi Datenbank abzusichern. Sobald man die DB mal neu machen will/muss, sind nämlich sonst alle Gesehen Zustände weg. Die Metadaten werden problemlos aus den .nfo ausgelesen, die Medien Infos (Auflösung, Codec, Audio- Kanäle,...) aus der Datei. Nur die Gesehen Zustände sind dann weg, sofern man sie nicht anderweitig abgesichert hat. Bei Filmen würde das in der größten Not vielleicht noch irgendwie akzeptabel sein. Aber bei Serien geht das gar nicht. Zumindest wird von dem Addon nichts verändert, was in irgendeiner Form mit den Metadaten zu tun hat. Und das Addon von PvD hält diese Einträge stets aktuell. In sofern kann ich damit gut leben.

Danke, kommt gleich...

Es steht auf jeden Fall ein Error im Log. Was der genau bedeutet, weiß ich aber nicht.

Hi.

Heute habe ich meine Kodi Datenbank neu eingerichtet. Das lief so wie geplant und hat alles in allem etwa 5 Stunden gedauert. Allerdings gibt es scheinbar ein Problem mit dem Addon von PvD . Das funktioniert so weit problemlos, scheint aber nicht mit Serien- Doppelfolgen klar zu kommen. Also wenn in einer Datei zwei oder mehr Episoden stecken (und das auch im .nfo gespiegelt wird), dann wird der Playcount nicht in die .nfo geschrieben. Zum Glück sind das bei mir nicht all zu viele Dateien, aber es wäre schön, wenn es auch dabei klappt.

Als Ursache könnte ich mir sehr gut denken, das die .nfo der Mehrfachfolgen zwar genau den Kodi Konventionen entsprechen (also so sein müssen), aber im Gegensatz zu den .nfo der Einzelfolgen keine validen XML Dateien sind. Es gibt dann nämlich mehrfache Root Elemente (für jede Episode eines), was laut XML Specs nicht sein darf. Ich hab mal ein paar .nfo mit Einzel- und Mehrfachfolgen von zwei Serien (Zurück in die Vergangenheit und Kampfstern Galactica) angehängt, die sauber von Kodi verarbeitet werden. Eigentlich müssten alle den Playcout auf 1 in den .nfo stehen haben. Tatsächlich ist das aber nur bei den Einzelfolgen der Fall, die eben valide XML Dateien sind. Deswegen vermute ich da die Ursache für das Problem. Klar, es wäre auf jeden Fall besser, wenn Kodi hier saubere XML verwenden würde, aber daran wird man nichts mehr ändern können. Dazu sind diese .nfo schon viel zu lange in Gebrauch. Ich weiß nicht, ob man das beheben kann. Falls ja, wäre es schon schön.

Quote from te36

Es gibt anscheinend in Deutschland keine Gerichtsurteile gegen den Verkauf von HDCP strippern

Ich sagte ja, das mich der Kram nicht wirklich interessiert. 99% meines Contents kommt per legalem Download bzw. herkömmlichen TV Aufzeichnungen und der Rest wird mit Screen Capture gesichert (sind nur alte Sachen, wo die Qualität ohnehin nicht pralle ist). Ich wüsste aus dem Stand nicht, wofür ich so ein Teil brauchen sollte. Wenn ich das brauchen würde, hätte ich vermutlich so ein Ding. Aber so,...

Andererseits würde ich es im Sinne der Freiheit begrüßen, wenn es generell nicht verboten wäre, die HDCP Stripper zu kaufen und verwenden. Macht einen unabhängig von den Launen der Streaming- Anbieter. Deswegen lade ich ja alles lokal runter, damit ich es auch dann schauen kann, wenn der Anbieter es schon wieder aus dem Programm geworfen hat. Allerdings haben die Sachen, die mich interessieren maximal Geoblocking, aber keinen Kopierschutz.

Quote from PvD

Für Echtzeit-Encoding braucht es dazu Power ohne Ende.

Aber nur, wenn man die GPU nicht her nimmt. Ein Intel N100 schafft es ganz locker einen 1080p Stream in Echtzeit zu encoden, sofern man dafür die GPU mit QuickSync verwendet. Mein i5 11. Gen Desktop System schafft das gleichzeitige De- und Encoden von 1080p Streams problemlos sehr viel schneller, mindestens dreimal so schnell wie in Echtzeit ohne dabei ins Schwitzen zu kommen. Per Software- Encoding würde das allerdings arg knapp für Echtzeit mit meinem i5, stimmt schon. Deswegen verwende ich prinzipiell Quick Sync zum Encoden.

Eine herkömmliche CPU ist einfach nicht grade optimal für solche Aufgaben geeignet. Das können selbst die mickerigsten GPU schneller. Und in diesen Kisten sitzt sicherlich kein gewöhnlicher x86 drin. Da wird schon eine GPU drin stecken, die 1080p on the Fly encoden kann. Sind ja beides keine 4K Recorder...

Netflix macht (oder machte) wohl trotzdem 1080p nur kein 4K, sofern ich das richtig mitbekommen habe. Allerdings interessiert mich das nicht sonderlich, da ich kein Netflix habe und brauche. Bei Prime sind es dann wohl nur noch 576p, was ohne HDCP geht. Aber wie gesagt, ohne Gewähr. Ist nicht mein Interessengebiet und war auch nicht im Ausgangsbeitrag gefordert. Da ging es um RTL HD und Vox HD.

Das AverMedia Teil erwähnt explizit, das man nur nicht per HDCP verschlüsselte Streams aufzeichnen kann. Bei dem anderen Teil steht es nicht dabei, wird aber vermutlich auch nicht anders sein.

Edit:

Es wird sicherlich auch Recorder geben, die HDCP Streams aufnehmen können. Die dürften aber wohl nicht so ganz legal sein, zumindest in Deutschland. Dank WWW dürfte sich da aber wohl drankommen lassen, wenn man will. Welche Geräte genau, weiß ich nicht, da mich das nicht interessiert.