joshuaboniface / emby

A (hard) fork of the Emby media browser project - OBSOLETE - see jellyfin/jellyfin

Hello, I'm Joshua Boniface

You may remember me from such successful projects as Jellyfin and Parallel Virtual Cluster.

By day, I'm a Senior Systems Architect (a.k.a. Sysadmin, DevOps Engineer, and Python developer all rolled into one fun package).

By night, I contribute to several open source projects. I lead the Jellyfin Project and my own Parallel Virtual Cluster HCI manager solution, as well as many other small projects that tickle my fancy. Check below for some of the more interesting ones.

When I'm not contributing, I'm usually geeking out, drumming, gardening, or biking. I'm a big fan of (big shock) Star Trek & Stargate, Magic: The Gathering, and tabletop gaming. Currently trying to find a decent TNG-era Engineering/Ops uniform.

emby's Issues

Implement LDAP authentication

The authentication system should support authenticating users against and external LDAP database.

help a noob

i really don't know how to run this on windows downloaded mono or am i to use debian

Upstream going closed-source

With upstream going closed source, we have a real impetus to get this going. Here's the current fork situation:

@dcrdev https://github.com/dcrdev/Emby
@JustAMan https://github.com/JustAMan/Emby

Plus the original "unlocked" patches:
@nvllsvm https://github.com/nvllsvm/emby-unlocked

I think all 3 of us are in the same boat, where none of us are really C# devs and, at least until today, weren't really looking to do a full fork or put much time into this. I'm curious if that's changed for you guys - I think it has for me.

As much as a full rewrite/alternative would be best long-term, Emby has momentum, and we already have a whole working project here. Hopefully with the attention this act by the Emby Lead Dev has caused, we can get a few developers on-board to help out. Keeping compatibility with the Mobile apps should also IMO be a focus, since rewriting those would be a massive job. Let's try to come to a consensus on how best to proceed.

First step I think would be to try to rebase our repos together. Based just on commits, I think @JustAMan's repo is the furthest along and has a release that I'm going to try out later this weekend. I think that's our best starting point. I've also chosen to rename mine to "OpenBY" based on feedback in #2, so I'll create a namespace for that project @nvllsvm has come up with the name "JellyFin" that I absolutely love, and created a namespace for it, so we can fork @JustAMan's version into it (unless you would like to do something else there - please feel free to comment!)

Building with Mono fails for 3.4 and 3.3 releases

Trying to build the repo versions of both 3.4.1.18 and 3.3.1.27 result in the same strange error during dh_clideps:

       Looking for ntdll.dll at ntdll.dll                                                                                                                                                                          Looking for libntdll.dll.so at libntdll.dll.so
dh_clideps: Error: Could not resolve moduleref: ntdll.dll for: System.Runtime.InteropServices.RuntimeInformation.dll!
        Ignoring moduleref kernel32.dll (case insensitive)
        running CLI parser command: LANG=C MONO_PATH= MONO_GAC_PREFIX=  MONO_GAC_PREFIX=$MONO_GAC_PREFIX:debian/emby-server/usr /usr/bin/ikdasm --assemblyref System.Runtime.InteropServices.RuntimeInformat
ion.dll 2>&1 > /tmp/dh_clideps.pZhi

[...]

dh_clideps: Error: unresolvable module references or missing shlibs entries, please check above errors!
debian/rules:34: recipe for target 'override_dh_clideps' failed
make[1]: *** [override_dh_clideps] Error 255
make[1]: Leaving directory '/srv/build/emby/Emby'
debian/rules:6: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

However building the version of 3.3.1 from the OpenSuse repo by Carlos Hernandez (https://download.opensuse.org/repositories/home:/emby/Debian_9.0/) works flawlessly.

dh_clideps: Error: Could not resolve moduleref: ntdll.dll for: System.Runtime.InteropServices.RuntimeInformation.dll! seems to be the operative line here, but from what I can gather this error has never been encountered before (nothing useful on the Google), so I'm working via trial-and-error. However, it looks like ultimately the problem is that "System.Runtime.InteropServices.RuntimeInformation.dll" isn't referenced anywhere in that repo, so there must be a change of some kind to eliminate this DLL.

It's worth noting that, so far, aside from this issue which occurs late in the build, using msbuild instead of xbuild from Mono 5.14 seems to work OK so far and successfully build from the repo.

A new name for the project

I'm looking for suggestions for a new project name to separate this project from the parent Emby project.

My current personal thoughts:

• Openby
• Libremby
• OpenMB

docker image ?

I guess a docker image would be more than welcome, since compilation might be tricky, and highly depends on the distribution (load of dependencies).

Thanks for the great work !

Replace Mono with .NET Core

Replace the Mono dependency with .NET Core which is more future-proof.

Can't install on Ubuntu 16.04

I've successfully built the Debian package using the command that you provide in the readme.

But the result is a little bit weird. It gives a ~10MB file when a usual one is ~50MB. When I try to install it, it says something relating dependencies: libc6.0, libc6.1 and libc0.1. Is weird because I've got official emby 3.5.0 (and past versions) installed without any dependency warning. And it's more weird since I was using Carlos Hernandez's ppa in Ubuntu without issues which is the one that you refers on your readme.

Is there anyway to build the package for Ubuntu?

Libsqlite3.so dll not found

After building the fork and installing the package, starting emby-server gives the following error:

Unhandled Exception:
System.DllNotFoundException: libsqlite3.so
  at (wrapper managed-to-native) SQLitePCL.SQLite3Provider_sqlite3+NativeMethods.sqlite3_libversion_number()
  at SQLitePCL.SQLite3Provider_sqlite3.SQLitePCL.ISQLite3Provider.sqlite3_libversion_number () [0x00000] in <98e8b101383146ef85e758cb0be46bea>:0
  at SQLitePCL.raw.SetProvider (SQLitePCL.ISQLite3Provider imp) [0x00008] in <73e712ea9d1b47d7be4afb0c91ae9225>:0
  at MediaBrowser.Server.Mono.MainClass.SetSqliteProvider () [0x00005] in <01dd934abf2246898f24d621d2867615>:0
  at MediaBrowser.Server.Mono.MainClass.Main (System.String[] args) [0x0000a] in <01dd934abf2246898f24d621d2867615>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: libsqlite3.so
  at (wrapper managed-to-native) SQLitePCL.SQLite3Provider_sqlite3+NativeMethods.sqlite3_libversion_number()
  at SQLitePCL.SQLite3Provider_sqlite3.SQLitePCL.ISQLite3Provider.sqlite3_libversion_number () [0x00000] in <98e8b101383146ef85e758cb0be46bea>:0
  at SQLitePCL.raw.SetProvider (SQLitePCL.ISQLite3Provider imp) [0x00008] in <73e712ea9d1b47d7be4afb0c91ae9225>:0
  at MediaBrowser.Server.Mono.MainClass.SetSqliteProvider () [0x00005] in <01dd934abf2246898f24d621d2867615>:0
  at MediaBrowser.Server.Mono.MainClass.Main (System.String[] args) [0x0000a] in <01dd934abf2246898f24d621d2867615>:0

I have both mono-devel and libsqlite3-0 installed on Debian 9

Remove mb3admin.com dependancies

As a stop gap mesure i would at least block it in the dns/router, i redirected it to my webserver and i can see dozens of entrys in the logs every minute, even with all reporting, updating etc disabled!

Note, this will also disable the Plugin-Installer!

Mobile Apps

I am curious as to whether you forked (or know of a fork) of the mobile apps before their source was closed?