Kennt, bzw nutzt jemand den "Emby Media Server" ?
Sieht mir nach einer Opensource Alternative für den "Plexmediaserver" aus?
Ich habe mir mal testhalber das Docker-Image gestartet. Wer weiß vielleicht ist es eine alternative
Kennt, bzw nutzt jemand den "Emby Media Server" ?
Sieht mir nach einer Opensource Alternative für den "Plexmediaserver" aus?
Ich habe mir mal testhalber das Docker-Image gestartet. Wer weiß vielleicht ist es eine alternative
Ich habe nur darüber gelesen, scheint nach Aussagen anderer etwas ab zufallen gegenüber pms.
Ich wäre aber sehr an deinen Erfahrungen interessiert.
Gerald
Also ich werde nicht warm mit dem Emby...
* In C# Mono/.NET -> ist ok, läuft über Docker von daher
* Braucht relativ viel RAM und CPU gegenüber Plex (die Server App!)
* Träge wie die Hölle, und ich habe nicht wirklich den langsamsten Server...
* Transcoder/Encoder ist ein originaler FFmpeg 2.8, Intel Quicksync wird wohl unterstützt (kann handbrake auch, aber da sind es nur +5% Speed)
* Der Transcoder braucht teilweise wirklich Ewigkeiten, teilweise über eine Minute bis da ein Bild kommt, bei Plex ist das ja teils wirklich Instant
* Ist komplett OpenSource
* Gibt fertige API Libs. Leider nur in C#/Java/JS
* Die Softwarearchitektur ist so wie man es auf der Uni lernt Teils sehr komplex, aber sauber gemacht.
* Als reines Backend für XBMC/Kodi, ohne Transcoding sicher schick.
Ich werde das mal im Auge behalten. Für mich aber "noch" keine alternative zum pms, das muss noch etwas reifen.
Um das in den VDR zu integrieren müsste man sich erst einmal eine C++ lib dafür schreiben. Aber das nach C++ zu bringen ist kein Wochenendprojekt, viel Cryptozeug, viel C#-Spezifische Elemente
wenn ich es richtig überschaut habe, gibt es auch noch kein VDR Plugin.
vdr-box
Man kann im Forum für das nächste TV Plugin voten. VDR hat erst 11 Stimmen und ist damit am Ende der Liste...
Es gibt bereits ein Plugin:
http://emby.media/community/in…1-vdr-plugin-development/
Funktioniert auch recht gut mit dem Transcoding. Nur die Aufnahmen macht er bei mir seit neuestem nicht mehr.
Hallo Leute,
habe mir die dll (vdr plugin für emby) aus der VdrLiveTV-0.3.0.zip mal auf meinen Server kopiert. Das sieht so weit erstmal gut aus. Die Konfigurationseite des Plugins ist vorhanden. Mir fehlt allerdings das restfulapi-plugin für den vdr. Gibt es das schon irgendwo als debian-Paket?
Ich nutze debian jessie 8.4 (openmediavault 3.0.13) und folgende vdr-Versionen:
root@mediatank:~# vdr -V
vdr (2.0.3/2.0.0) - The Video Disk Recorder
xineliboutput (1.1.0) - X11/xine-lib output plugin
vnsiserver (1.3.1) - VDR-Network-Streaming-Interface (VNSI) Server
epgsearch (1.0.1.beta3) - search the EPG for repeats and more
streamdev-server (0.6.0-git) - VDR Streaming Server
live (0.2.0) - Live Interactive VDR Environment
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
quickepgsearch (0.0.1) - Quick search for broadcasts
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
Viele Grüße Hoppel
Du kannst restfulapi von github holen und recht einfach kompilieren.
https://github.com/yavdr/vdr-p…i/tree/stable-0.6?files=1
dpkg-buildpackage sollte dir ein Paket bauen wenn du die Abhängigkeiten installiert hast.
debhelper (>= 8), vdr-dev (>= 2.0.0), pkg-config, gettext, libcxxtools-dev, libmagick++-dev
Ich kompiliere eigentlich immer nur mit make install.
yavdr ist ubuntu. Kann man die Sourcen auch auf nem Debian System kompilieren?
Ich sehe keinen Grund warum das nicht möglich sein sollte. Je nach Alter der Distributionen können eventuell die nötigen Abhängigkeiten etwas Arbeit machen.
Gerald
Hallo Gerald,
vielen Dank für die Info. Ich werde es bei Gelegenheit einfach mal ausprobieren.
Gruß Hoppel
Ich hab Emby hier auch im Docker-Container laufen.
Als TV-Backend nutze ich allerdings tvheadend.
An der Funktionalität gibt es wenig zu beandstanden.
Aber Geschwindigkeit, Speicherverbrauch und CPU-Last sind verbesserungswürdig.
Tvheadend ist für mich keine Alternative so lange vdr aktiv weiter entwickelt wird.
Was gibt es denn an der Geschwindigkeit von emby auszusetzen? Ich kann das nicht bestätigen!
Gruß Hoppel
Hallo Leute,
habe gerade mal alle dependencies installiert und erhalte nun folgenden Fehler.
apt-get install build-essential
apt-get install debhelper vdr-dev pkg-config gettext libcxxtools-dev libmagick++-dev
cd /usr/src
git clone git://github.com/yavdr/vdr-plugin-restfulapi
make
root@mediatank:/usr/src/vdr-plugin-restfulapi# make
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D USE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QU ANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_ 64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o restfulapi.o restfulapi.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D USE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QU ANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_ 64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o serverthread.o serverthread.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o tools.o tools.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o info.o info.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o searchtimers.o searchtimers.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o channels.o channels.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o events.o events.cpp
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_LIBMAGICKPLUSPLUS -c -DPLUGIN_NAME_I18N='"restfulapi"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -I/usr/include/x86_64-linux-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6 -o recordings.o recordings.cpp
recordings.cpp: In member function ‘void RecordingsResponder::replyEditedFileName(std::ostream&, cxxtools::http::Request&, cxxtools::http::Reply&)’:
recordings.cpp:309:37: error: ‘EditedFileName’ is not a member of ‘cCutter’
editedFile = recordings.GetByName(cCutter::EditedFileName(recording->FileName()));
^
Makefile:76: recipe for target 'recordings.o' failed
make: *** [recordings.o] Error 1
root@mediatank:/usr/src/vdr-plugin-restfulapi#
Display More
Was kann ich tun?
EDIT: Bin ich richtig in der Annahme, dass das Problem bei meiner VDR Live Version liegt und mit Version 0.4.0 behoben wurde? https://projects.vdr-developer.org/issues/1757
Viele Grüße Hoppel
Ich würde da eher auf eine Inkompatibilität zum VDR 2.0.x tippen - cCutter wurde laut HISTORY zwischendrin geändert ( https://projects.vdr-developer…dr.git/tree/HISTORY#n7994 ) und mit dem VDR 2.2.x baut das Plugin ohne Probleme.
Hmm... das ja blöd. Kannst du deine VDR Verion aktualisieren? Vor dem Wochenende schaffe ich es nicht, einen Fix dafür zu bauen.
Wenn du die Methode RecordingsResponder::replyEditedFileName nicht benötigst, kannst du die Zeile 309 auskommentieren. Ich gehe davon aus, das die für den Betrieb mit Emby keine Rolle spielt.
Hallo Leute,
Ich würde da eher auf eine Inkompatibilität zum VDR 2.0.x tippen - cCutter wurde laut HISTORY zwischendrin geändert ( https://projects.vdr-developer.org/git/v…e/HISTORY#n7994 ) und mit dem VDR 2.2.x baut das Plugin ohne Probleme.
Danke für den Hinweis. Das war zu vermuten.
QuoteHmm... das ja blöd. Kannst du deine VDR Verion aktualisieren? Vor dem Wochenende schaffe ich es nicht, einen Fix dafür zu bauen.
Möchte ich eigentlich nur ungern. Dann müsste ich ich komplett auf das openmediavault plugin verzichten und es aus anderen Quellen beziehen bzw. den vdr und die plugins komplett selbst kompilieren.
Ich habe immer noch die Hoffnung, dass ich openmediavault3 als alleiniges OS nutzen kann, sobald es offiziell released wurde, ohne für jeden einzelnen Service eine Testumgebung haben zu müssen, weil irgendwas, was ich brauche oder gern nutzen würde, nicht einfach so funktioniert und intensives Testing in einer eigenen virtuellen Maschine voraussetzt.
Ich habe mal einen Request zu einer vdr-Aktualisierung in openmediavault über github gestellt: https://github.com/OpenMediaVa…nmediavault-vdr/issues/16
QuoteWenn du die Methode RecordingsResponder::replyEditedFileName nicht benötigst, kannst du die Zeile 309 auskommentieren. Ich gehe davon aus, das die für den Betrieb mit Emby keine Rolle spielt.
Wenn ich mit dem Request nicht weiter komme, wäre ich dir sehr verbunden, wenn du das bei Gelegenheit fixen könntest. In welcher Datei finde ich diese Zeile 309. Dann kann ich die gern mal auskommentieren und schauen, ob das funktioniert.
Danke für eure Unterstützung und Gruß Hoppel
Hi Hoppel,
ich meine die Zeile 390 in der Datei Recordings.cpp des restfulapi plugins. Die die auch in der Fehlermeldung zu sehen ist.
Einen Fix wird es geben nur komme ich wie gesagt nicht sofort dazu.
Ok, ich schau mir das morgen mal an und melde mich dann wieder.
Ich nutze auch openmediavault mit vdr, die alte version vom VDR war einer der Gründe weshalb ich mir Docker Images mit aktuellem VDR gebaut habe
Gerade bei emby mit seinen ganzen MONO Abhängigkeiten ist auch ein Docker Image praktisch, da wird nichts im System zugemüllt.
Don’t have an account yet? Register yourself now and be a part of our community!