Emby
Emby copied to clipboard
joshuaboniface
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!)
Some updates from reading through the Reddit threads:
- There's always Streama, which has been discussed in the past.
- Airsonic (https://github.com/airsonic/airsonic) can do video, but not very well, since it's more Music-focused. Might be worth helping them out more however.
- There's https://github.com/robinp7720/Oblecto which is NodeJS-based
- There's https://github.com/OwenRay/Remote-MediaServer which is also NodeJS-based.
I'm sure there are a few more as well - please post them here!
Streama is very confusing, I do not think that it can be an Emby replacement, it seems like one has to organize everything to make it usable which is way too much of a work. It is also totally useless for random videos. I never watch a movie or a show or anything so I do not collect them, and Streama had been totally useless to me, I cant even add my videos properly :(
Airsonic is barely a video player without much management features.
I'm using Emby and looking for alternatives now as well. I understand Emby periodically scans directories for shows/movies and intelligently associates them with information from IMDB, etc, and presents it all in a netflix-like web interface. I want to find out the amount of work to duplicate some of its functionality under the hood. Can someone explain what it does in these situations:
- When a device wants to play some media, how does Emby know to transcode or not? What does it do differently for transcoding vs. no transcoding (i.e., does it use ffmpeg for both or only when transcoding)? What protocol is it using to stream the media to the device?
- When my TV connects to Emby, is it doing DLNA stuff? Is there a whole DLNA server in Emby?
- What does Emby do when Sonarr/Radarr notifies it that there's new media?
Thanks for considering Remote MediaServer. I'd love to work with the community to extend it to rival Plex and Emby. If you have questions or hesitations feel free to ask me anything.
Poke around my repo, I have replaced some of binary blobs with compiled versions. Not sure I've sent all the changes into master, though.
@joshuaboniface if you hear wind (or will do anything yourself) regarding future Emby development please keep me in the loop and absolutely feel free to use my patches.
As I said to @joshuaboniface on other channels, maybe there's sort of a hybrid way forward?
-
Make sure there is a buildable, "working" version of Emby somewhere. This will help people who still need to use something now, and don't want to go up to the latest/closed version.
-
Evaluate all current alternatives, even projects that are mostly on their way. The list provided in https://github.com/joshuaboniface/Emby/issues/11#issuecomment-445303110 is a great place to start.
-
Decide how to move forward (arguable the hardest part).
Everyone wants their solution to win out. We just need to put weight behind one thing, and I don't know that it would be continuing the Emby project as it is. There's probably a lot of technical debt in these older versions, and I don't think it's a good idea to be held hostage by depending on someone else's mobile app(s).
If it helps, it might be a good idea to consider what @ekw has said: https://github.com/joshuaboniface/Emby/issues/11#issuecomment-445327721. We need to figure out what is absolutely essential functionality, desired functionality, and eventual nice to haves. MoSCoW if you will. Then, go over these alternatives, see what fits the bill, and if there's something that's good enough to start, go there.
If not, set it all on fire and start fresh, but with a strong focus, or it'll never get anywhere.
Just to bring this up, the more I think about it, the more I like the idea I came across in a Reddit comment.
Why not make the server and client separate, so the server just provides data and media through a well defined set of APIs, and let the clients be their own projects? @joshuaboniface tells me this is the way AirSonic works now.
This has a lot of flexibility, and can be built modularly so we can start with core features (a collection/database), expand into media types (video, eventually audio?), and categories of those types (e.g. movies, tv shows, then music, podcasts).
We can still provide a reference client that is pretty good, but having a strong server foundation makes it so anyone can do what they want with the client. And a good modular architecture would make it easy to expand this core server.
Great points everyone. I do agree, we need more alternatives in the web- and app-based media space. More projects are better! I'm going to spend some time over the weekend trying out the various other options from @OwenRay and @robinp7720 and see where they're at, and go from there. I wouldn't mind starting some backend work in Python myself for another candidate app over the next little while either, following that modular design.
For now, then, keeping a build-able, OSS version of Emby is priority number one, even if there's never another commit to it. @JustAMan I'll test out your repo since it's the furthest along from what I can see, and in #2 @nvllsvm has created the lovely names jellyfin and jellyfyn for the Emby fork, which I love as a totally distinct yet creative and fun name for whatever becomes of this!
Something to consider doing early is to set up an easy way to collect donations. Many of us can only realistically contribute financially. I'm a Data Scientist and would love to contribute code as well, but my toolkit is mostly comprised of R and Python (never touched C#).
I was Plexiled to Emby when they butchered their privacy policy, and vowed to support Emby via Premiere monthly subscription. The idea was that they'd get more money from me over time (compared to a lifetime subscription), but they had to stay the free(dom) software course. I canceled that subscription and would be happy to send that money to a new home.
Radarr and Lidarr take contributions through https://opencollective.com, but admittedly I know little about that platform.
OpenCollective looks like a great idea for a support structure; I'm not as gung-ho about cryptocurrency though. I'd envision something like using @nvllsvm's orgname https://github.com/jellyfin (that he's very graciously made me an admin of as well) as a staging org for those of us who want to help out with the idea of "alternatives to Plex and Emby". I see no reason we couldn't host several different projects (the renamed Emby fork, perhaps my and @anthonylavado 's plan for a modular, backend media management framework, and maybe even alternatives like Remote-MediaBrowser) and make a collective for those of us who want a real modern free-software Video/Audio/Whatever streaming system. Hell, if we support audio too we might make @muff1nman and @joomla's lives vis-a-vis Airsonic's tech debt easier too ;-). One free-software media system to rule them all! How does that sound to everyone? Any feedback on this idea?
@bobberb Ipfs is not a good fit, I wanted to implement ipfs for my mediaserver, and actually at one point had a working proof of concept. But there are quite a few downsides to ipfs.
- ipns is too slow
- there's a way to share data without having a second copy in the ipfs dir but it's still experimental, can not cross filesystem boundaries and there are a number of other caveats.
- You're broadcasting the files you're sharing to the network, and anyone can fetch them from you, this is not secure nor legal in many cases.
I ended up using the bittorrent DHT for peer discovery and writing my own encrypted sharing protocol.
I personally think that neumby as in new Emby should provide a proper protocol for custom client integrations and custom database access. I think that would make it a central piece of software in the foss media management world.
Emby already has Dlna and it kind of generally works.
To me the most important feature of Emby is the ability of each client to control eachother and cast to eachother. I hope that the new branch if there will be one, supports that nicely. I find that feature to be unique among media playes, although I have never used Plex, maybe that one does it too.
@OwenRay At least some way of sharing 1 singular file would be good, I think is the point they mean. So just being able to sharing a url to a specific file by using a token. E.g https://plex.myhomemedia.me/libraries/movies_01/Goodfellas#token=132879587
As I said to @joshuaboniface on other channels, maybe there's sort of a hybrid way forward?
-
Make sure there is a buildable, "working" version of Emby somewhere. This will help people who still need to use something now, and don't want to go up to the latest/closed version.
-
Evaluate all current alternatives, even projects that are mostly on their way. The list provided in #11 (comment) is a great place to start.
-
Decide how to move forward (arguable the hardest part).
In addition to @anthonylavado - a step-by-step guide for current users should be set, such as
- Stop all mainline Emby updates in your package manager
- Downgrade to latest open source, distro-packaged version (follow up with PPA, AUR, Portage patches)
- Wait for community fork/forks to be building and available on package platform.
Dropping their downloads/month is healthy.
@ajmar I am speaking of long term things, I thank you for the clarification. Modules will be good if actualized. So can bounties. I was very ready to buy an Emby license a week ago - happy to not spend it there.
OpenCollective looks like a great idea for a support structure; I'm not as gung-ho about cryptocurrency though. I'd envision something like using @nvllsvm's orgname https://github.com/jellyfin (that he's very graciously made me an admin of as well) as a staging org for those of us who want to help out with the idea of "alternatives to Plex and Emby". I see no reason we couldn't host several different projects (the renamed Emby fork, perhaps my and @anthonylavado 's plan for a modular, backend media management framework, and maybe even alternatives like Remote-MediaBrowser) and make a collective for those of us who want a real modern free-software Video/Audio/Whatever streaming system. Hell, if we support audio too we might make @muff1nman and @joomla's lives vis-a-vis Airsonic's tech debt easier too ;-). One free-software media system to rule them all! How does that sound to everyone? Any feedback on this idea?
I know this is more of a technical discussion, but are you thinking of a sustainable source of funding for a full rewrite? Donation rates are notoriously bad for open source projects, even if usage is significant. If this remains commercialization-free it is going to be a labor of love, which I hope is sustainable for a web interface that will inevitably be exposed to the WAN (unlike say Kodi). Perhaps corporate sponsorship is a path - can the design fit a business use-case? Is dual-license frowned upon? Can this ultimately be funded by businesses seeking say a training video platform while remaining free to non-commercial users? Maybe getting ahead of things here, but licenses aren't always flexible ^_^.
Found this issue on Reddit, thought I'd chip in: I'm willing to invest time and effort in a whole new project, as it is something I've been looking for.
I have been following a few of these repos since the GPL issues over on emby-server started a few months ago. I hadn't heard about Oblecto or RemoteMediaServer until now and they both look interesting. I would also like to contribute to a new project, although it seems there haven't been any decisions yet.
We need to figure out what is absolutely essential functionality, desired functionality, and eventual nice to haves.
I agree with @anthonylavado, if we want to try and throw all our weight behind one project we should really figure out what the focus will be. Plex and Emby are massive projects and it seems like any attempt to replicate all the features would take quite a while. I would rather have a small project with stability and an active community than a project that dies out because the goals were too lofty from the start.
If we decide to work on separate projects it would be great to use a standard API for at least the media, downloads, transcodes, et cetera. That might decrease the risk for people wanting to make clients, although it might be too optimistic. Emby had a client API for years and I don't think I ever saw an unofficial client. It would also be hard depending on the features each project decided to implement.
Yes, @joshuaboniface and I continue to think about this.
He’s going to focus tomorrow on getting a version of JellyFin (formerly the open source version of Emby) to build with as many available community patches as possible. This is step one for sure.
We’ll also be taking a look at @OwenRay’s RMS, to see how it works and how it is set up.
In the meanwhile, I’m continuing to work on writing out use cases/requirements/specifications on what we’ll need, and evaluating how best to go forward.
@anthonylavado we can spin up a room on Riot really quick so everyone has a place to talk about the project other than two or three separate issue threads, unless you'd prefer another service. It's basically an open source discord, might allow for better discussion.
A central place to discuss the project would be helpful. I don't have a strong preference on the location, but something that allows for asynchronous communication is ideal.
Wherever it ends up being, we should close the various discussion threads and redirect folks. A link in the README of this and related repos should be created as well.
Edit: I agree that a stable snapshot of a recent version of Emby is priority 1. I am also happy to start a MoSCoW doc of features.
Jyst a FYI - this is a project that is a 3rd party Emby API client that I use in a regular basis on my webos 2.0 LG: https://github.com/sleuth255/screenplay
So unofficial clients do exist.
As for features and ways of development - my vote is for Python (my favorite language) and highly modular structure to allow fine feature-tuning by plugins instead if trying to build a new monolith feature-packed Plex/Emby alternative.
Oh, and my uses are: watch stuff on my webos 2.0, Tizen something, and browser-based other clients. I want audio track selection, subtitles selection, 3d video support, auto transcode if needed. Fetching metadata like description or posters is optional, but cross-platform clients are a must. That's my 50 cents.
Did someone say Riot? ;) I made a chat room at http://matrix.to/#/#saving-emby:potatofrom.space available for anyone to join, if you all would like to coordinate development there.
I'd love to help out with development/sustaining a FOSS media browser as well.
OK so news on the actual repo front: I've gone over both @dcrdev and @JustAMan 's repos. From the looks of it, I can merge @dcrdev's into my 3.4 copy no problem, but @JustAMan's looks to have large number of upstream changes (858 merge conflicts, mostly related to 3.5 :-1:) So I think, we're best to just use @JustAMan's repo as our base for jellyfin (https://github.com/jellyfin/jellyfin) and re-add anything that might be missing. (Edit: Pushed)
I'm doing some local tests of the build on my systems tonight and tomorrow, and will fix up anything that might be needed for Debian packages, then will push it up that remote repo. We can then move discussion there :+1:
Moving forward and away from Emby, how about taking the unix approach "Write programs that do one thing and do it well" rather than having it all in a one big project? (The UZBL browser comes in mind) A lot of what's needed probably already exists but perhaps needs slight adjustments where we could contribute to those projects to get the adjustments added. It would be interesting to write up what features are needed and to take a look at what projects would fit.
Another approach would be to perhaps expand Kodi into a native server/client kind of solution. Kodi already covers a lot of things that we need and has a pretty solid community behind them, one of the reasons I tried Emby in the first place was because it had a sort of native integration with Kodi unlike the Plex plugin which at the time was horrible. I'm not sure if anyone has had an attempt to do that in the past or if it's something that the Kodi team would not accept into their project.
Hi all. I just wanted to chip in because I too am massively in favour of this. My story is similar to a lot here: disillusioned with Plex, found new hope with Emby, now that's going to sh!t too. I think what gets to me the most is the general attitude of the devs of late. A lot of the time, bugs are reported and they respond with a sort of 'we can't replicate, therefore it doesn't exist' mentality. The client apps are also being massively neglected in favour of seemingly daily server releases. That's all well and good, but if the clients suck, what's the point?
Here are some very incomplete and fragmented comments:
-
In favour of a modular [seperate] client/server approach
-
Debian support is a must
-
I use Android and ATV apps so keeping compatibility would be ideal if possible
-
One thing that I really love about Emby over Plex is the ability to tweak metadata (and choose where it is pulled from). Plex always got it wrong off the bat, and had limited options for tweaking (I think this may have changed now) but metadata fine tuning is essential - in fact, fine tuning everything is essential the more dials, knobs and switches the better. If they are hidden to avoid confusion to non-power users then that's fine but an 'Apple level' of non-tweakery is a massive turn off ;)
-
RasPi's..... Plex did it right, Emby still has not. Putting the 'there are more bang for buck ARM boards' argument aside, the Pi is the go to for a lot of us because of the community. Emby's Pi attempt is extremely poor and laggy - as is the linux client in general. It seems to be plagued with GTK issues. If a decent Linux client could be added to the eventual goals it would be awesome.
One final comment: I totally agree with renaming and the name Jellyfin is very cool. I can see it with a bad fish style logo ;) The only thing is that I noticed that there is another OSS project called Jellyfin. I don't know if this is of any concern, but I believe a change of name should be unused by any other project. As it happens, it a project here on git: https://github.com/jelly-fin/jelly-fin-native.
I rolled in early this morning after a Stag do and am still quite fuzzy so I'll probably think of more as the day goes on and add it :)
Note that some of your conflicts might be caused by me beautifying back uglified js/css/html, which enabled me to fix stuff a bit and allowed for better understanding of the codebase.
@JustAMan That makes sense; @dkanada pointed out on Riot that there's ~300 commits from 3.5.2 that aren't in the repo, are those the ones you mentioned you hadn't added to master yet?
I did not do any upstream merge, I took a version from @h3ge and built upon it.