Jump to content

Metadaten-Bearbeitung in SQLite - Import von Genres - guid / PresentationUniqueKey?


sf53892
Go to solution Solved by hein,

Recommended Posts

Hallo,

 

ich mache gerade meine ersten Gehversuche mit Emby nach Umstieg von Synology auf FreeNAS. Da ich eine ziemlich große Sammlung von TV-Beiträgen (technisch also: home video) nach emby umgezogen habe, würde ich mir gerne die Arbeit ersparen, alle Metadaten (vor allem Titel, Kategorien) manuell erneut eingeben zu müssen, und wollte stattdessen die Metadaten direkt durch Bearbeiten der SQLite-DB ergänzen. Mit den Titeln hat das schon funktioniert (Zuordnung über den Dateinamen).

 

Nun habe ich eine Frage zur Speicherung der Genres in Emby 4.0.1.0. Gibt es da "best practices", Genre-Einträge per SQL zu importieren?

 

Wenn ich es recht sehe, werden Genres bei "Home Video"-Inhalten an zwei Stellen in der Relation "MediaItems" abgelegt:

  • Einmal in der Spalte "Genres" beim jeweiligen Dateieintrag, jeweils getrennt durch pipe-Symbol | ;
  • und dann nochmals für jedes Genre ein eigener Eintrag mit Type 21.

D.h. wenn ich zu den Dateieinträgen Genre-Angaben in SQL ergänzen möchte, muss ich wahrscheinlich sowohl die Genre-Spalte des Eintrags füllen als auch einen eigenen Eintrag mit MediaType 21 anlegen? Punkt 2 (eigener Eintrag) macht mir Kopfzerbrechen, da hier noch zwei Spalten zu befüllen wären, von denen ich nicht weiss, wie man hier die Werte manuell generieren kann: guid und PresentationUniqueKey. Kann ich die Werte hierfür irgendwie im Rahmen des SQL Insert generieren, oder geht das zuverlässig nur über das Web-UI?

 

Bin für jeden Tip dankbar!

Edited by sf53892
Link to comment
Share on other sites

This is not going to be easy to do. I'm guessing you don't have local nfo metadata files?

 

No, currently i don't have nfo files. Architecture is as follows: Media data resides in a FreeBSD/FreeNAS dataset (to control access and quota). Emby is installed inside a FreeNAS jail, accessing the media files read-only via a mount. I would prefer to keep the media files outside of emby, restricting emby to read access outside the jail.

 

Maybe i can "import" the synology metadata by creating nfo files manually from the SQL data? Would it be possible to point emby to a path inside the jail to look for / create nfo files? Anyway, currrenty i only have the media data in library.db, with the old synology metadata in single SQL table, imported into library.db. I've already managed to update the media file entries in library.db with the names from the synology import, matching the data by the filename. Now, i only need a way to update the Genres field of the home video media files. Just updating the Genres field seems to be insufficient, since emby seems to need an additional genres entry in MediaItems, and i don't know to create that entry without breaking the complete thing.

Link to comment
Share on other sites

you could enable nfo saving on the server, then do refreshes of metadata and that will cause nfo files to be written. then the new server will see those and import the information during the library scan.

Link to comment
Share on other sites

Ich bin momentan an einem ähnlichen Problem im Rahmen der Datenbankmigration auf Version 4.x.

Möchte Emby auch ungerne Schreibrechte auf meine eigentlichen Daten einräumen.

Bei vergangenen Versuchen Metadaten als NFOs zu speichern, wurden mir reihenweise meine eigenen NFOs überschrieben.. blöderweise hatte SnapRaid schon gesynced, bevor ich das gemerkt habe..

Dann gab es mal einen Bug, der mir meine selbst erstellten Subs vernichtet hat.. etc.

Will sagen: Trau, schau, wem..

 

Für die reine Datenmigration von 3.x auf 4.x würde wahrscheinlich ein Snapshot, ein kleines Kopierscript und ein anschließendes Restore reichen.

Wobei das reine Theorie ist. Bin mir nicht sicher, ob Emby tatsächlich bei einem Refresh manuell veränderte Metadaten zuverlässig rausschreibt.

Leider kein ZFS auf dem Fileserver um das mal eben ohne viel Overhead zu testen.

 

Aber eine dauerhafte Lösung ist das halt auch nicht, wenn man Emby auch zukünftig keine Schreibrechte geben will und ggfs. beim nächsten Update das gleiche Spiel beginnt..

Denn scheinbar sind eigene Metadaten im Emby Kosmos nur als (halbwegs) sicher zu betrachten, wenn man sie als NFOs mit den entsprechenden Medien speichert.

Alles andere kann bei einem major release aufgrund von DB Umstellungen wieder raussfliegen und man muss manuell pfuschen oder schaut in die Röhre.

Diese Tatsache und das scheinbar fehlende Problembewusstsein der Devs dazu ist bei professioneller Software gelinde gesagt ein wenig ernüchternd.

 

Mein aktueller Gedankengang geht in Richtung eines eigenen CoW OverlayFS Layers für Emby, damit es Daten lesen und seine NFOs schreiben, aber ansonsten nichts verändern kann.

Link to comment
Share on other sites

you could enable nfo saving on the server, then do refreshes of metadata and that will cause nfo files to be written. then the new server will see those and import the information during the library scan.

 

I'm not sure if i understand correctly. I don't have the complete metadata on an old server, so i can't use such a server to create nfo files. The complete metadata is only available in a PostgreSQL DB filled by Synology's VideoStation. Synology also creates metadata files in the file system, but they're using a proprietary, binary format (*.vsmeta). So my starting point is SQL data, and the task is to import that data into emby's data store. Hmm, maybe i'll try to understand how emby fills the guid / PresentationUniqueKey.

 

Ich bin momentan an einem ähnlichen Problem im Rahmen der Datenbankmigration auf Version 4.x.

Möchte Emby auch ungerne Schreibrechte auf meine eigentlichen Daten einräumen.

Bei vergangenen Versuchen Metadaten als NFOs zu speichern, wurden mir reihenweise meine eigenen NFOs überschrieben.. blöderweise hatte SnapRaid schon gesynced, bevor ich das gemerkt habe..

Dann gab es mal einen Bug, der mir meine selbst erstellten Subs vernichtet hat.. etc.

Will sagen: Trau, schau, wem..

 

Für die reine Datenmigration von 3.x auf 4.x würde wahrscheinlich ein Snapshot, ein kleines Kopierscript und ein anschließendes Restore reichen.

Wobei das reine Theorie ist. Bin mir nicht sicher, ob Emby tatsächlich bei einem Refresh manuell veränderte Metadaten zuverlässig rausschreibt.

Leider kein ZFS auf dem Fileserver um das mal eben ohne viel Overhead zu testen.

 

Aber eine dauerhafte Lösung ist das halt auch nicht, wenn man Emby auch zukünftig keine Schreibrechte geben will und ggfs. beim nächsten Update das gleiche Spiel beginnt..

Denn scheinbar sind eigene Metadaten im Emby Kosmos nur als (halbwegs) sicher zu betrachten, wenn man sie als NFOs mit den entsprechenden Medien speichert.

Alles andere kann bei einem major release aufgrund von DB Umstellungen wieder raussfliegen und man muss manuell pfuschen oder schaut in die Röhre.

Diese Tatsache und das scheinbar fehlende Problembewusstsein der Devs dazu ist bei professioneller Software gelinde gesagt ein wenig ernüchternd.

 

Mein aktueller Gedankengang geht in Richtung eines eigenen CoW OverlayFS Layers für Emby, damit es Daten lesen und seine NFOs schreiben, aber ansonsten nichts verändern kann.

 

So weit bin ich leider noch lange nicht - ich kann emby erst dann nfo's schreiben lassen, wenn es die Metadaten kennt... Danke trotzdem!

Link to comment
Share on other sites

  • Solution

Uff.. sorry.. da habe ich ja im Eifer des Gefechts halb am Thema vorbeigelesen -_-'

 

Ich würde bei Deinem Problem folgendermaßen vorgehen:

  • Testverzeichnis mit Schreibrechten und einem der TV-Beiträgen / Home Videos für Emby anlegen
  • Bei Emby das Speicher der Metadaten als NFO aktivieren, die besagte Filmdatei hinzufügen und die Metadaten manuell so bearbeiten, wie sie am Ende aussehen sollen
  • Die entstandene NFO auf ihre Struktur und Deine gewünschten Felder hin untersuchen
  • Die vorhandene Postgres DB beispielsweise als CSV exportieren
  • Ein Shellscript schreiben, welches:
    • zeilenweise die Werte splittet
    • gemäß der NFO Konventionen formatiert
    • und als NFO Datei im jeweiligen Dateiverzeichnis abspeichert
  • Anschließend die Verzeichnisse read-only mit Emby einlesen

 

Mühselig, aber mit etwas shell magic durchaus machbar.

  • Like 1
Link to comment
Share on other sites

Uff.. sorry.. da habe ich ja im Eifer des Gefechts halb am Thema vorbeigelesen -_-'

 

Ich würde bei Deinem Problem folgendermaßen vorgehen:

  • Testverzeichnis mit Schreibrechten und einem der TV-Beiträgen / Home Videos für Emby anlegen
  • Bei Emby das Speicher der Metadaten als NFO aktivieren, die besagte Filmdatei hinzufügen und die Metadaten manuell so bearbeiten, wie sie am Ende aussehen sollen
  • Die entstandene NFO auf ihre Struktur und Deine gewünschten Felder hin untersuchen
  • Die vorhandene Postgres DB beispielsweise als CSV exportieren
  • Ein Shellscript schreiben, welches:
    • zeilenweise die Werte splittet
    • gemäß der NFO Konventionen formatiert
    • und als NFO Datei im jeweiligen Dateiverzeichnis abspeichert
  • Anschließend die Verzeichnisse read-only mit Emby einlesen

 

Mühselig, aber mit etwas shell magic durchaus machbar.

 

Hmm, klingt sehr gut - leider bin ich auf ein weiteres Problem gestoßen (mein TV kann von emby keine Videos per DLNA abrufen, ging unter Synology noch..), und FreeNAS scheint insgesamt nicht ganz das Passende für meine Bedürfnisse zu sein. Daher setze ich jetzt erst mal das ganze System auf einer anderen Basis neu auf und sehe dann weiter. Trotzdem nochmals vielen Dank für die Tipss, vielleicht werde ich nochmal drauf zurückkommen (oder sie sind für andere Nutzer hilfreich)!

Edited by sf53892
Link to comment
Share on other sites

Np.

 

Habe auch lange an DLNA als offenem Standard gegenüber der ganzen proprietären Lösungen festgehalten.

Aber seit die sich aufgelöst haben und niemand mehr das Zertifikat wirklich enforciert, habe ich die Hoffnung aufgegeben, dass es in zukünftigen Geräten saubere Implementierungen geben wird :(

Hast Du Emby zufällig in einem Docker laufen? Da bedarf es nämlich einiger Workarounds, damit Broadcasts (und damit UPNP/DLNA) funktioniert.

 

Ich schätze externe Plugins wie KODI oder die Emby Clients sind auf dem TV nicht möglich?

 

RE: NAS

Kommt natürlich sehr auf die eigenen Bedürfnisse an, aber falls noch nicht gesehen, wäre OpenMediaVault eventuell einen Blick für Dich wert.

Auf Debian Basis, open source, gute Community und großteils schöne Umsetzung.

Link to comment
Share on other sites

Np.

 

Habe auch lange an DLNA als offenem Standard gegenüber der ganzen proprietären Lösungen festgehalten.

Aber seit die sich aufgelöst haben und niemand mehr das Zertifikat wirklich enforciert, habe ich die Hoffnung aufgegeben, dass es in zukünftigen Geräten saubere Implementierungen geben wird :(

Hast Du Emby zufällig in einem Docker laufen? Da bedarf es nämlich einiger Workarounds, damit Broadcasts (und damit UPNP/DLNA) funktioniert.

 

Ich schätze externe Plugins wie KODI oder die Emby Clients sind auf dem TV nicht möglich?

Läuft inzwischen - mein TV (Toshiba L63...) war ziemlich wählerisch, was die Transkodierung betrifft. Und dann musste man noch auf wechselnde HTTP-Header (siehe https://emby.media/community/index.php?/topic/17208-force-dlna-to-apply-dlna-profile/ ) reagieren... Nach zwei Stunden trial and error läuft es jetzt einwandfrei! :D:wub::)

 

RE: NAS

Kommt natürlich sehr auf die eigenen Bedürfnisse an, aber falls noch nicht gesehen, wäre OpenMediaVault eventuell einen Blick für Dich wert.

Auf Debian Basis, open source, gute Community und großteils schöne Umsetzung.

Jupp, OMV hatte ich bereits im Blick.

Edited by sf53892
Link to comment
Share on other sites

  • 2 weeks later...

Uff.. sorry.. da habe ich ja im Eifer des Gefechts halb am Thema vorbeigelesen -_-'

 

Ich würde bei Deinem Problem folgendermaßen vorgehen:

  • Testverzeichnis mit Schreibrechten und einem der TV-Beiträgen / Home Videos für Emby anlegen
  • Bei Emby das Speicher der Metadaten als NFO aktivieren, die besagte Filmdatei hinzufügen und die Metadaten manuell so bearbeiten, wie sie am Ende aussehen sollen
  • Die entstandene NFO auf ihre Struktur und Deine gewünschten Felder hin untersuchen
  • Die vorhandene Postgres DB beispielsweise als CSV exportieren
  • Ein Shellscript schreiben, welches:
    • zeilenweise die Werte splittet
    • gemäß der NFO Konventionen formatiert
    • und als NFO Datei im jeweiligen Dateiverzeichnis abspeichert
  • Anschließend die Verzeichnisse read-only mit Emby einlesen

 

Mühselig, aber mit etwas shell magic durchaus machbar.

 

Nochmals ein kurzes Feedback: Das Erstellen der nfo-Dateien war relativ einfach, da PostgreSQL XML exportieren kann. Dann muss man nur noch das resultierende XML (eine XML-Datei mit allen Datensätzen) mit XSLT in Einzelteile zerlegen, ggf die Felder entsprechend den nfo-Gepflogenheiten umbenennen und die Datensätze in separaten XML-Dateien speichern. Da XSLT den Dateinamen und den Pfad anhand der XML-Inhaltes setzen kann, hat man im Handumdrehen einen Satz nfo-Dateien in einer Verzeichnisstruktur, in der auch die Medien abgelegt sind. Das einzige Problem: ich konnte noch keine exakte Beschreibung der nfo-Dateistruktur finden. Im Kodi-Wiki gibt es einiges, aber die verschiedenen DLNA-Server scheinen unterschiedliche Erwartungen an die nfo-Dateien zu haben. Beispielsweise ignoriert Serviio nfo-Dateien, die Emby ohne Probleme verarbeiten kann.

Link to comment
Share on other sites

Cool, dass das so gut geklappt hat :)

Hmm.. laut ihren Docs sollte Servioo ja eigentlich mit entsprechend benannten und KODI konformen NFOs harmonieren.

Hast Du mal in deren Board angefragt?

Link to comment
Share on other sites

Ich habe es quasi schon angekündigt - aber zuerst muss ich mir noch die Serviio-Logs vornehmen, vielleicht findet sich schon dort ein Anhaltspunkt.

Link to comment
Share on other sites

Nur als Ergänzung: Falls jemand selber gern Synology-Metadaten exportieren und nach nfo wandeln möchte - ich habe die SQL-Abfrage (für den Schritt SQL  -> XML) sowie das XSLT-Stylesheet (für den Schritt [generisches] XML -> .nfo) mal als gists bereitgestellt:

Noch einfacher geht es übrigens mit tinyMediaManager - ich hoffe, mit den Hinweisen jetzt nicht gegen die Foren-Regeln zu verstoßen. Aber gerade tMM hätte mir einiges Kopfzerbrechen erspart, wenn ich es früher gekannt hätte... und es ist m.E. eine gute Ergänzung zu Embys Metadaten-Editor.

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...