Performing a full fork? #28
Comments
|
This is a subject I've thought long and hard about over the last few months and just the way Emby is going at the moment and the attitude of it's fans and developers towards the GPL, make me want to participate in something like this. I think if we could get enough skilled people on board, then it's worth exploring but only then. It's one thing to fork the server component, but then the apps need developing from scratch as they have never been open source; you know the moment a fork appears, the Emby team will block it within their own apps. But I think to be more specific, immediate priorities:
What I can bring to the table:
|
|
Also in regards to a name - I was thinking something like EmbéLibre lol |
So that's 2 of us, I know @nvllsvm mentioned he does this for a friend in another issue, but I've also got a friend or two with C# experience who might be willing to help occasionally.
That's a concern of mine as well - given their attitude in general I'd be wary of them taking "retaliatory" action against the fork. It looks like the Android app (https://github.com/nvllsvm/emby-android) is indeed GPL though, which is a start - I'm not sure whether you guys are Android or iOS but I'm Android so that's fine by me to start with.
I like these priority-wise, and think they're easy enough to get done as soon as we have a bit of a community. I've already got a working Debian build setup for the
I like that, but accent aigu might cause trouble ;-) |
|
There's also Streama (https://github.com/dularion/streama). I'm now debating throwing my and my friend's weight behind it instead of dealing with Emby. It's still immature though moving fast and needs more work (it didn't have half the features the last time I checked on it), but it's a good start, and written in Groovy instead of C#. The only breaking issue for me is the requirement to have a theMovieDB.org API key to use it. |
|
I did have a look at that a while back and it's certainly a valiant effort, but for me it lacks something critical - music support. Also I know it's written in Groovy, but it's still Java and to me that's a bit off putting; I have very mixed feelings about Java. Whereas despite C# and .NET Core coming from Microsoft, I feel are generally well designed. |
|
Welp, looks like we need to hard fork. Emby depends upon proprietary blobs else the software won't compile. https://github.com/MediaBrowser/Emby/issues/3075#issuecomment-371021228 |
|
Finally got around to starting a side project I've been thinking about for well over a year. In a few hours of hacking, I managed to hack together:
Feel free to look at the caffeine-fueld wip. Did I mention it's hacked together? Anyway - seems to work so far :)
|
|
@nvllsvm That looks great! On the one hand, building a full replacement streaming server is a big undertaking, but on the other, having another option, written in Python (yay) and without a decade of .NET cruft is amazing! I'm definitely keeping an eye on it and will see if I can help! ;-) |
|
Hi, I would be very happy to help anywhere I can. Most of my experience is in front end web dev although I have done some simple things in C, C++ and C# in the past. I have also got a reasonable amount of linux experience (about 10 years but never in a professional environment). I've only been using Open Source for a while and would love to give something back if I can. I use emby-unlocked a lot so thought this would be a good place to start. Please let me know if I can help. |
|
Not sure how serious this discussion this but I have a couple of thoughts:
Here are a few projects that seem like a good place to start: https://github.com/nmaier/simpleDLNA https://github.com/MediaPortal/MediaPortal-2 (this one might be difficult, since it's already a mature application but this is the closest to what Emby is) https://github.com/TwitchBronBron/PlumMediaCenterSharp https://github.com/einsteinx2/WaveBox Edit: A couple more relevant projects: |
|
Thanks for the feedback everyone! I think @SamAtwell 's point #1 is the big rub - we're hitting the "POSIX filesystem" problem: we can't attract any users until we have a feature-complete system (for a limited feature set, but it must be relatively close to what Streama has now if not what Emby/Plex have), but getting there is a non-trivial amount of work. I'd be more open to doing this for the reasons I mention, but it would need several solid developers (I'm not one) to dedicate to it. @nvllsvm's proof of concept looks really nice as a starting point though! Given what we have today though, and especially with @Jab2870's offer maybe just hard-forking For #2 I agree completely (again, as a non-developer) - client apps are "easy" once there's a scalable API in the backend. I've never heard of any of the projects in #3 so I can review some of them to see where they're at. |
|
I'm contemplating something else at the moment... bear with me: Whilst I have ended my issue on their GitHub page due to them having cleaned up a few things and there no longer being a technical GPL Violation. I still believe that the way they are handling things goes against the spirit of the GPL and the fact that one cannot build it themselves is absurd even if they are claiming those releases to be a "re-licensed version" , they are not highlighting that fact to end users. So what I'm thinking of at the moment is forking it, writing some python to patch the csproj files dynamically and then having some shell scripts merge any changes from upstream. I could then set up builds for Fedora, CentOS/RHEL and OpenSUSE via copr - anyone else would be free to chime in for Debian/Ubuntu/Docker. Then in regards to the propriety blobs, they could be reverse engineered but purely to get the class definitions and any methods would just throw not implemented exceptions. So in effect as a starting point we would have an entirely free version of Emby and that would not be a direct threat to them e.g. we might get away with still using their apps, but they'd have to be purchased on a single device basis due to lack of premiere; that would also continue to bring in an income for Emby. Finally the pièce de résistance... As you may have noticed Emby doesn't really have that many contributors from outside, a large part of this I suspect is down to their CLA. The proposed fork would apply no such restriction - hopefully this may begin to attract interest from developers. At which point it would hopefully have enough traction to warrant the creation of new apps, a re-brand and the re-implementation/re-imagining of some of those premiere features. Thoughts? |
|
Also not ruling out a completely new solution - I too would like something that isn't dependent on netcore as it's a pain to manage a build system on Fedora/RHEL. I like the sound of something in C++ or Rust maybe. But realistically that's going to take a lot of man-power from the get-go and would likely take quite a lot of time before it comes to fruition. But very open to the possibility... |
Would using something like FAKE or Cake help with that? The one benefit to using C# (and .NET) is you get to re-use a big portion of your code for building client apps through Xamarin & Mono. IMO that's a huge advantage compared to other platforms, though I suppose you can do the same JS with React Native, Ionic, etc. |
|
My main concern is that is can be compiled on Linux, sooooo mono support is a must 😉 |
|
I have started work on modifying Emby to build under netcore / scripting the automation to merge changes from upstream. Have 75% of the projects building, a couple I need to iron out the dependencies for. Also need to work out what's supported in netcore in terms of unit testing. |
|
There's a portion of code missing from their repo that would allow you to build a fully working version under .net core. That is the server application itself - in the repo only exists the mono server application and the windows one. I'm re implementing it to the best of my abilities at the moment, but looks like there's also some missing constructors in the 'Emby.ServerImplementations' project to support this. That and the fact every single javascript file (not 3rd party) is minified, really gives me the impression they don't welcome contributions. So whilst I'm probably going to be able to get this working, my dream of automating it has gone swiftly down the drain - I've had to make significant changes. I've also stripped out Windows support entirely because I can't test it, also have stripped out Mono as that will become redundant anyway. Anyone like to chip in? |
|
@dcrdev - Look around in the other MediaBrowser repos. Pretty sure the minified JavaScript files exist as their original forms in other repos. I know Emby.ApiClient.Javascript contains some of the original Javascript files, but not sure if it has them all. |
|
Little taste of what's coming: |
|
I'm excited! |
|
Looking good @dcrdev! |
|
Waiting for this 😀 |
|
Looking good. |
|
I've rewritten the apphost library now and have it up and running, just 3 things to go before I push the missing piece to the repository:
I'm quite shocked at the extent to which what Emby is publishing in their git repo differs from what's coming out of their releases. For instance:
It's so much more than missing build scripts as we had previously thought! Also I discovered that ThirdParty/emby/Emby.MediaEncoding.dll is not open source and that's not even part of premiere, it's integral to the functionality of the core server. |
|
I've been following this for a little while now, got interested in Emby since it was advertised as open and I run on an arm based platform w/ internal/non-standard decode/encode HW. Just a crazy thought on the "new solution" topic above. I've dabbled in Kodi on occasion, how bad would it be to make a server version of it? |
|
As far as I remember, Plex started as a server version of Kodi. Also, I have ended up forking the Emby repo, I am not happy with the current state of affairs with Emby and so would like to try and move away to a fully open source fork. I have taken the last fully open source commit of Emby and gotten it building as a netstandard20 project. I have pulled in the dependencies Emby provides too as I don't want to rely on them going forward, I do need to make attribution and licensing clearer however as some of these components are MIT licensed rather than GPL. I still need to pull in and reproduce the build system for the front end JavaScript and HTML. If interested you can check out the fork at https://github.com/benpye/Emby , as I have included some other non GPL projects from Emby (MIT licensed) I do need to make sure the licensing is clearer. |
|
Looks like the Emby team has completely fucked over open source fans - they've closed up critical components in the latest release. |
|
It looks like this has been rectified. |
|
@voxadam - License is still ambiguous, hopefully just an oversight MediaBrowser/Emby.Common#1 |
|
I don't disagree; I was only commenting on the most recent issue. |
|
@joshuaboniface yes that's what I meant by package definitions above - I've made those changes in my repo: https://github.com/dcrdev/Emby/blob/master/MediaBrowser.Model/MediaBrowser.Model.csproj |
|
Finally just caught up reading this thread! Leaving this as a place holder for now. |
But wouldn't that be the best way for all premium feature in emby? Instead of closing down the source code and build process so nobody can remove the license checks, just make it into a plugin. They could even ship it with their super proprietary binaries if they want. I personally don't mind paying for some features, I think gitlab for example does a great job with their business model. But I'm really dissastified with the move from OSS to closed source software, especially when they don't seem to be able to provide stuff like arm64 packages and there is no way to build the project yourself. |
|
@Kiina Absolutely, and if they hadn't been trying all the scummy stuff regarding nag screens, proprietary licensing attempts, and outright hostility to the free software part of their community, I probably would have just been another happy Premium user personally. But all of that adds up. Besides, their implementation from what I've seen is half-assed (it's an "import from LDAP" not "auth against LDAP") and about 3 years too late. Maybe if Mr Lead Dev had spent time properly implementing the feature instead of constantly trying to obfuscate his code and write anti-features, it wouldn't have been a big deal, but after everything else it is. Auth is a basic part of every web application - why is my choice of where my user passwords are managed a proprietary and premium-locked feature? While I haven't done much of anything on my fork yet (mostly poking around to see how to implement it myself) I want to have the option available in case the whole Emby project goes closed-source like Subsonic did. If anyone following this thread wants to PR against it though I'll accept happily! I've also got an issue about changing the name waiting for more community feedback! |
|
What is more feasible? Bringing streama to reasonable feature parity with Emby or building a self-sustaining fork from Emby? I have to think the former. I'm non-technical and just observing, but streama has a community, active development, committed dev, and MIT license. That compares to building a community from scratch with lots of emby's legacy baggage. This emby fork saga has been going on for too long and there seems to be some "low hanging fruit" for talented devs to pick off at streama that can go a long way to creating wider appeal: transcoding, music, dlna. There has already been work done towards transcoding that someone could pick up and finish: streamaserver/streama#440 Anyhow, just my perspective. I've been using Emby for a while now, but if I'm going to put time into a community, I'd prefer to make a clean break from Emby and streama checks off enough boxes for me to think that the effort wouldn't be wasted. |
|
I've been vaguely watching Streama development for a little while and would love to see the Chromecast functionality actually get developed for that. Sadly I personally don't know Java and am not in any position to help contribute to that project directly. :( |
|
@vfrex, streama is written in JAVA tho, its crappy. |
|
Agreed hate to be that guy but Java is a piece of sh** that should die, it's a syntactical shitsh** that enforces a built in garbage collector that frankly creates more overhead than it helps eliminate. Ironically I've had to start doing some Java/Scala stuff at work recently and have hated every goddamn minute of it. In comparison C# is a beautiful language - it's everything Java should have been, even though I am far from a fan of Microsoft. The way I see it:
Then you have C, C++ and Rust but hobbyist developers are few and far between - well maybe not Rust but that's still quite new. Anyway - are we going to continue with this quite frankly pointless discussion if no one else is willing to step up an contribute some code? Otherwise might as well close this down... |
So I hadn't checked up on Streama in a while, and it does look to have progressed a bit from where it was when I last checked. But TBH it's still got some "drop-in replacement" dealbreakers, especially requiring a TMDB API key, as well as needing to import every file manually. Simply put, it's nowhere near feature parity with Emby and I say that knowing full well that Emby is missing some pretty critical features. I'm not sure what the right answer to this is - if we (meaning myself and any other non-devs who can't contribute much to these projects) have to wait for a long time for Stream to be ready, then forking Emby today makes more sense - we don't have to do anything to it to make it work or build on a technical level (licensing issue aside) and can make some small, incremental improvements as needed. Long-term a replacement would definitely be worth the effort, however is Streama that replacement? And if not, what is? I'm more focused on a fork because of the former reasons rather than the latter - I'm worried about 6 months from now when Mr Lead Dev decides to close down the whole repo and take the project closed source, rather than the hypothetical 2-years-from-now ideal solution of a full feature-complete replacement. Of course others may disagree with my opinion here and that's fine, if Streama becomes viable sooner than all the better. I do agree though that this discussion isn't very fruitful at this point. We've got a hard fork at my repo and @dcrdev is working on the licensing issues in his fork (and sorry I haven't had much of a chance to contact the FSF yet - though in the US it seems APIs can be copyrighted so we might be screwed there either way, but that's a discussion for a separate issue). |
|
Reopening. Emby core has gone proprietary. |
|
Welp, I saw that one coming. I haven't checked up on @dcrdev's work recently, but mine stagnated as I havent had much time to learn. But I'll throw my weight there. "Libreby" here we come! |
|
Well this totally blows. I wish I had more time to help with this but I've now started a new #dayjob so I don't really have enough time to devote to this alone. If you want to use my stuff at https://github.com/benpye/Emby go ahead. It builds but I actually kinda regret the commit I took to base my work off, Emby had already started only publishing minified JavaScript and CSS. To be honest, the web frontend code is Emby could be better anyway, I wanted to try and improve the code but I really struggled. I got half way through undoing their minification - I did this by:
The three remaining files to apply this to are syncsettings.js, tvshows.js and videoosd.js . In addition to this all the libraries used are minified! We need to go and find out what commit was used at the time for each library and grab them from upstream, this should be relatively easy if a little tiresome. Emby has no JS build system, it would be nice to use NPM or something to grab deps. In my fork everything but the web front-end is still open source though this comes at the cost of being a few releases behind the last open source release (3.5?). If anyone has any questions or specific difficulties I will try and help but my time to devote to this is limited! As it stands my repo should build using .NET Core and appears to run just fine. Good luck all. EDIT: Few more thoughts on the possibility of a from-scratch replacement. I can see this being perhaps a better way forward. As shown above getting FFMPEG to transcode video and getting HLS playback to work isn't insanely difficult. Perhaps starting anew would be better - we could leave the crufty web UI behind, maybe use TypeScript + Angular for the front end and personally I would suggest Go on the backend but Python is great too. I like Go because deploying a Go application is trivial, it's easy to consume C libraries and you get small native binaries avoiding the packaging complexity of lots of other languages. If starting from scratch we could ensure that the web API is a strong contract, the front end and back end should be more or less completely seperate. It would be nice if the web app could be a PWA too, it would avoid the need to worry about native mobile applications for each platform. A good API would hopefully enable more third party clients than Emby has ended up with, and hopefully we could expose config etc in the public API, something that Emby seemed to be lacking? |
|
90% of the emby is FFMPEG, the rest is just shimmer and glimmering stuff to make it look good. |
|
Hate to be that guy, but has anyone thought about go? |
|
Damn, shame to see emby finally closing up. Out of curiosity, what are your use cases? Personally I'd want to write a series of APIs, as opposed to a whole web product. That way you could write a nice simple front end to start, then make it more feature complete later. I'm interested in rust, so I'd eventually I might look at replacing the backend with that - or at least the stuff that grabs metadata. |
|
I've opened up an issue on my fork regarding where to go from here and how we're going to acheive it. I'd appreciate input from anyone who has made their own fork or who has opinions on how to proceed from here. |
|
I've been working on an alternative for a while now, it's written in NodeJS and React. Contributors are welcome:) right now I've got:
|
|
@joshuaboniface if you believe your fork to be the most up to date and is building, would you be interested in an arch AUR entry for some sort of "emby-server-forkJB"? |
Just started a project to encapsulate these ideas: https://github.com/djotaku/TransStream |
|
Dang...so it finally happened. I suspected it would happen at some point but I was hoping I would be wrong. As far as next steps go, I hope people consider how big of an investment it is to build a brand new project. Just building a new project alone won't be enough. You need a thriving community if it is to successful. That being said, the best decision long-term is probably to build something new and not carryover any of the baggage or the cruft. It's just going to be a lot of hard work to get there. |
|
@bobberb It builds, but it's quite old and the other guys have done a bunch of work to port it to the newer better Mono. But, I'm more in favour of a new project long-term. (see joshuaboniface/Emby#11) @djotaku Agreed completely on almost every point. My usecase is the same, a 11+TB media library that I want to stream on my various devices (Chromecast, Phone, Web) and give access to various friends and family. I picked Emby a few years ago precisely because it was GPL'd and as good as Plex, which everyone was clamoring to use but I disliked due to preferring Free Software. As I outline in the issue I mention above, I have a plan to write a modular backend media server system in Python with @anthonylavado, and then just let front-ends use that. FFMPEG is indeed the heaviest lifter, but at least to me, the "shimmer" is really important - Metadata management, and a good UI to browse with on multiple devices. There's a couple really great ones out there, tons of up-and-comign projects to provide shimmer, but it seems every one is limited by not having a universal backend, which is something I want to change. I still think keeping Emby around is a good idea, even if there's never another commit, because it works right now, so I'll spend some time making sure that's all set before proceeding with a new project, and we can let the community decide which is more valuable (i.e. if C# coders pop out of the woodwork haha!) |
|
@joshuaboniface Do you have a repo for it yet? I basically JUST learned about this today (even though going through the comments it looks like it's been in process since April (at least)). So my repo is really just a readme with my intentions. I'm fine with you and @anthonylavado being co-owners of the repo since we have aligned goals. It wouldn't be stomping on any of my stuff as I haven't done anything today other than play with FFMPEG a bit to understand how it works for streaming. Alternatively, if you prefer to have your own repo, please let me know when it's up and I'll try and be an active contributor to yours. |
|
Your use case's are exactly mine, and I think my mediaserver already does exactly what you have in mind (albeit a bit rough around the edges at times).
|
|
@OwenRay OK, I had only briefly looked it over. My plan would be to do a solid backend in Python (I hate how fast NodeJS moves, as a sysadmin) that supports arbitrary media so frontends could be written in ehatever language to interface with it. But I'd be happy to ibcubate multiple projects together, no need to compete but help each other build a set of great media server tools. |
|
@OwenRay I think as soon as @joshuaboniface and I get a chance to look over RMS we should be able to comment better on it. We’re also planning on writing, I guess you’d call it a set of specifications/use cases, so we can make sure we’re covering everything the right way. For example, I’m really really interested in making it as modular as possible. If someone wanted to add audio later on, it should be something they can enable, but they don’t have to if they don’t want to. |
|
Ok I agree, I tried setting it up modularly, especially later additions are very loosely coupled. |
and others
In light of the history of this project and its maintainers, and now the (news-to-me) GPL violations, combined with the virulently toxic attitudes of the "community" around Emby (the "stop whining" crowd) - should we do a full fork? Basically, planning to do what Libresonic did when Subsonic went closed-source?
As mentioned in #25 I don't have any experience with C# development, but I know a few people who do and might be willing to get involved, and I can help with build infrastructure/hosting/etc. as that's my specialty. Frankly I don't care that "99% of users won't care", I care, and will ONLY use OSS software, which is why I even went with Emby in the first place. And I care a lot about keeping it that way for everyone else, since Emby is the only reasonable and OSS alternative to Plex. Plus this gives us the flexibility to start adding useful features (for me, LDAP user authentication support and the ability to choose between Air order and DVD order for TV without manually hacking metadata, things with the Emby core devs have ignored for years at this point).
Some short-term goals could be:
Openby?Some longer-term goals could be:
Any thoughts or interest from those here? Do you think it's worthwhile? Could we get enough devs to keep up?
@nvllsvm @dcrdev and anyone else.
Edit 2018-08-10: My fork is at https://github.com/joshuaboniface/Emby and should build a Debian package right now.
The text was updated successfully, but these errors were encountered: