Bower has been dead a long time - we should replace it with something more robust for managing out Javascript dependencies.

Suggestion: Webpack

Bring in the configured submodules from @JustAMan 's repository.

https://github.com/JustAMan/Emby.XmlTv.git
https://github.com/JustAMan/ImageMagickSharp.git
https://github.com/JustAMan/Emby.IsoMounting.git

We call out the Wiki in the readme, but there's nothing there yet.

I've added the default "welcome" page, with a note that more details are yet to come.

Need to quickly sketch out what will go in there, and start adding content.

I'm thinking:

• Project overview (same as readme)
• Quick Goals (point to code of conduct)
• Currently known/supported builds/packages list
• Install instructions for supported builds

As part of the overall renaming, lots of links direct to https://emby.media for no particular reason. Those should be redirected to either a website for jellyfin (long term, to enable using them as documentation and proper service links) or to this GitHub project (short term, just to prevent confusion)

Please add ARM docker versions.

Here are links to the closed source Emby versions.

https://hub.docker.com/r/emby/embyserver_arm32v7/
https://hub.docker.com/r/emby/embyserver_arm64v8/

Also, Emby dockers are quite a bit smaller. Not sure why that is.

As mentioned in #3 a forum might be a good idea, to have a more stable place to discuss than the chat long-term. I can spin up something basic to get going, but feedback welcome before I do.

Hi

It would be nice if we can watch Youtube videos from Jellyfin. It does not have to have some kind of Youtube account management, just basic channel listing with a the Youtube Api key.

thanks

Removing all connections to emby.media has broken the plugin installation system. We should either launch or own one or come up with an alternative, perhaps more manual plugin installation method.

I know this is just starting out and this may take a long time to be implemented but I would love it if you guys could implement DVR like plex or emby. I would instantly switch if that happened

One of the reasons I couldnt use emby was because of the inaccurate subtitle rendering. After seeing this project I spun up and tried it again but still subtitles are incorrectly rendered. Especially when dealing with more complicated subtitles like .ass and fonts included inside the mkv files.

Here are some examples

Plex:

Jellyfin/emby:

These were taken with these settings on the server:

Plex: Nothing, works out of the box

Jellyfin/Emby:

Maybe I'm missing some other setting that will make it work.

Help much appreciated ❤️

Good initiative on the fork btw!

On a fresh Debian9 VM, after having installed Jellyfin from the repo, I am unable to get the Music library to scan correctly. Here is a tail -n 50 of server.txt: https://paste.pound-python.org/show/GzsZomKLjz8W2bWvmrJv/ (that repeats over and over during scan)

Songs show up but nothing in Artists at all.

The ability to federate a Jellyfin server with other Jellyfin servers would allow for multiple libraries to be utilized from a single pane of glass. Shared content residing on different servers does not have to be hosted on every single server, and in order to access different content, a user does not have to log into separate servers. The implementation would be different from a shared database as this could operate over the Internet where exposing a database or network share (CIFS/NFS/etc.) is not recommended. The workaround would be a VPN or IPSEC tunnel, but that adds a higher barrier of entry for this functionality, whereas federating would only involve adding an IP address/hostname of a remote server plus a key ID on both ends.

Also having the ability to download from federated servers to the local storage directory corresponding to media type (Movies, TV, etc.) would be valuable, along with some sort of monitoring/auto download function for specific content would be useful, albeit maybe out of scope as content could be manually downloaded from Jellyfin and added to the local directory.

Duplicate content (not necessarily identical quality) would be handled as some form of hashing implementation would have to be added for quick comparison of same files between libraries, which may be out of scope for an initial implementation of this.

I'd like to put in some significant time this weekend to development on this, but I feel the direction at the moment is slightly fragmented -

Have we considered creating a roadmap and pushing feature requests to something like:
https://feathub.com ?

Additionally have some questions that I'd like some feedback on:

• I see at the moment there's work being done migrated startup preferences to an App.config file. The App.config concept isn't really used in .NET Core, would it not make more sense to migrate this to a platform agnostic json manifest and store this in /etc/default and %\AppData in windows?

• Since clearly there is significant interest in WIndows builds, what is the plan for the service daemon here. Since .NET core does not support the service controller API is windows only and therefore does not exist in .NET core. I've been using this wrapper around the .NET Core compatibility layer for months at work: https://github.com/PeterKottas/DotNetCore.WindowsService . Thoughts?

• Any reason we can't get rid of ImageMagick and solely use Skia? Upstream are already doing this on their .NET Core builds.

• Packaging - what's the plan here? So many distros don't have the .NET Core runtime and SDKs in their core repos (I'm mainly talking RHEL/CentOS and Fedora) , so is the plan here to just provide instructions on where thes dependencies can be sourced from? Or is providing self contained packages a consideration as upstream is already doing?

• Packaging - again, for the benefit of packaging systems that require valid upstream source urls - again mainly rpm. Can we split packaging off into another repo within this Org?

Cheers

This is a big issue in Emby, if we can get this to work before they do, I'll guarantee that there will be a very significant increase in people switching away from Emby.

Any communication with external Emby resources (URLs) needs to be removed.

Hi, I'd love to see audiobook support with mp3, ogg, and m4b. Chapter markers, bookmarks, etc. Thanks!

I'm trying to set up live tv guide data and when I click on xmltv or Schedules Direct I get this error:

Could not find file '/dashboard-ui/components/tvproviders/.template.html'.

I don't see a point to having the submodules exist in separate repos. We're not releasing them separately so it only makes source control more complex.

We should move the code into this repository.

From @gardar on February 11, 2016 16:52

I would like to see Emby support media that's inside rar files natively.
Preferably in a similar way that Kodi does currently.
This means that the media is not extracted from the rar but rather accessed directly from within the rar files.

Few requirements:

• Support for multi-part rar files.
• Emby would need to look at time stamps on the directory rather than the media file in the rar archive, since the time stamp in the archive can't be changed since creation.

Further details on the requirements of this feature request:
http://emby.media/community/index.php?/topic/10765-support-for-media-in-rar-archives/
http://emby.media/community/index.php?/topic/23648-tutorial-rar-playback-with-emby/

Copied from original issue: MediaBrowser/Emby#1440

Hello,

I tried to compile the source with the Readme file commands and install the .deb file on my debian (stretch), but it does not work.

root@jellyfin:~# dpkg -i jellyfin_3.5.2_all.deb 
(Reading database ... 28432 files and directories currently installed.)
Preparing to unpack jellyfin_3.5.2_all.deb ...
Unpacking jellyfin (3.5.2) over (3.5.2) ...
dpkg: dependency problems prevent configuration of jellyfin:
 jellyfin depends on at; however:
  Package at is not installed.

dpkg: error processing package jellyfin (--install):
 dependency problems - leaving unconfigured
Processing triggers for systemd (232-25+deb9u6) ...
Errors were encountered while processing:
 jellyfin

• Rename "Emby" to "Jellyfin" in all user-facing text
• Replace all Emby logos
• Replace all emby.media links with jellyfin.media

In a few different areas, there are API keys for TheMovieDB and The TVDB. We should probably remove these.

Since there doesn't appear to be any better alternative metadata providers, I feel we should continue using these, and we can get API keys of our own for the project.

There are a few concerns however:

• TheMovieDB allows use in non-commercial projects without cost, but there is a rate limit (see FAQ)

• TheMovieDB is created by user contributions, but there are terms to agree to in order to use the data (see API - Terms of Use)

• The TVDB does have data available with less onerous terms (all I could find was the line at the bottom of their website)

• The TVDB doesn't appear to rate-limit, or if they do, it's not obviously mentioned (see API)

We can avoid hits on the TMDB API by following a similar approach to Firecore for their Infuse program. See: https://firecore.com/forum/topic/18385

Another option is to go all out and not include API keys, but make this user configurable somehow. That might be a future goal however, and I don't know if anything in the terms of either provider discourages/prohibits that type of use.

https://medium.com/@ewoutterhoeven/dav1d-0-1-0-release-the-first-benchmarks-5404360e44e3

Master branch has had dav1d for some time now. Better codec support than emby could be very simple as I believe this is only a compilation switch away from being enabled.

Open a pull request to add jellyfin to https://github.com/Kickball/awesome-selfhosted

Might be a decent idea to be forking all the apps we can while they're still open source.

The android app went under ages ago, but this I've found a repo that seems to be the latest.

• Android: https://github.com/hatharry/emby-android
• Emby Theater (Electron): https://github.com/MediaBrowser/emby-theater-electron
• Kodi Addon: https://github.com/MediaBrowser/plugin.video.emby
• Emby Theater (Windows): https://github.com/MediaBrowser/emby-theater-windows
• Emby Theater (Pi): https://github.com/MediaBrowser/emby-theater-pi
• Windows Media Centre: https://github.com/MediaBrowser/MediaBrowser.Classic
• Samsung Smart TV: https://github.com/MediaBrowser/SamsungSmartTV
• Roku: https://github.com/MediaBrowser/Emby.Roku
• Chrome App (Seems unused?): https://github.com/MediaBrowser/emby-chromeapp
• Windows Phone (lol): https://github.com/MediaBrowser/Emby.WindowsPhone
• Emby Theater Plugins: https://github.com/MediaBrowser/Emby.Theater.Plugins

Building packages often requires multiple steps and customized environments. Having a Dockerfile to build the Debian package:

• Creates portable, reproducible build environments.
• Allows one to build the Debian package on any system.
• Documents how exactly to build the package. Our ancestor project was notoriously bad at this.

In other words - one should be able to build a Debian package doing nothing more than this. This example assumes #18 has been implemented.

$ git clone https://github.com/jellyfin/jellyfin
$ cd jellyfin/jellyfin
$ docker build -f Dockerfile.debian_package .

I've thought for a while know that the logging mechanism has been somewhat lacklustre - it's impossible to read, has no rotation options and is not rendered in any significant way within the interface.

Therefore I propose we replace logging with Apache Log4Net which is probably the most widely used logging framework within the .NET community.

Specifically this would allow for 3 things:

• Easy logging to a SQLite database
• Strict formatting conventions
• Easily abstracted and extractable through a common interface - we could display this in a filterable datatable in the admin interface as oppose to a link to a text file.

With this fork being named jellyfin, we'll need to differentiate this repo by renaming anything we reasonably can. This might just be the README for now, but long-term anything referencing Emby should be updated.

It looks like there aren't any (at least, no open-source) test suites for the codebase, I think we should look at what to prioritise in terms of testing the existing codebase, and perhaps implement a policy that all future PRs require tests? At least the problem can be addressed going forwards, then.

With that in mind, it may be a good idea to decide on a testing library/toolset and then create test projects for each of the C# projects in the solution, so that it's easy for future contributors to add tests to their PRs.

I've personally had good experience with NUnit as a unit testing framework, Moq for mocking and Autofixture for resolving dependencies easily, but I'm happy to accept whatever is popular nowadays.

The docker image can't build these two projects correctly as they have .Net 4.5 targets, and the Docker image is missing Mono.

I think our options are either:

1. Remove .Net 4.5 targets from ImageMagickSharp, TagLibSharp (and see if anything breaks)
2. Find an argument for dotnet build to specify targets to build
3. Add Mono to the Docker image

In my opinion, those are also listed in order of most to least preferable.

I'll have a go at removing .Net 4.5 targets shortly.

Debian build configs are present, but we should support as many others as possible. This would include:

• Docker - jellyfin/jellyfin
• RedHat/RPM
• AUR - jellyfin-git

Other suggestions welcome!

Possibility to add mysql/mariadb to replace or as an option to use instead of sqlite?

i think you'd get like 30% of emby users if you could make it so our wives could download subtitles w/o their accounts having to be admin accounts.

Playback on LiveTV not starting in chrome browser, server running Ubuntu 18.04 LTS, jellyfin installed via readme instructions.

HD Homerun tuner added successfully, SchedulesDirect added successfully, still not able to playback live tv at the moment. It works in emby premiere.

Any ideas on what I should be looking at settings wise?

This shouldn't be too hard, seems to just need for someone to edit the relevant files and click a couple buttons.

I know it's a dumb requests, but I would love a dedicated Live TV app for Roku that would upon start up start playing the last played channel. I used to have DirecTV now and that's what I love about it is it was like a STB where it would just continue with the last played channel upon start up. With my harmony it makes it great for launching a LiveTV activity.

Hi

I transitioned from Emby to Jellyfin on Debian. Almost everything works, except that I lost all my video positions, all the played videos with resumes now look like they were never played, or started at all.

I do not remember my Emby version unfortunately.

Edit: I am already using the Emby database/resources

I'm going to set up a simple Debian package repository for Jellyfin. While eventually the goal should be to get ourselves included in upstream Debian, this will help make installing the server easy for users today, to avoid them having to build it themselves.

If I'm not mistaken, Emby supports LDAP authentication but only through a paid plugin. LDAP support would streamline authentication and allow Emby to be used in larger deployments working better with #42 in a multi-server environment.

Plus, even with a small setup, LDAP dramatically reduces the administration load around managing user accounts.

I'd like to follow the development of this. Can a mailing list for developers and users be created (assuming one doesn't yet exist)?

I have already replaced some binary blobs with compiled from source files, but there are some more to go. We need them to be built from source with good enough license, as now they're taken from a repo with missing license, thus their legal state is unclear.

Also we'd have to fork here the repos I used via git submodules (I guess submodules still point to my personal repos).

Remove:

• ThirdParty/emby/Emby.Server.Connect.dll #22
• ThirdParty/emby/Emby.Server.Sync.dll #22
• ThirdParty/emby/Emby.Server.MediaEncoding.dll #154, #171
• ThirdParty/taglib/TagLib.Portable.dll #41

Not sure I have a solution, but the configuration could jellyfin could do with an improvement. I would like to use my Kubernetes cluster to host Jellyfin. The "correct" way to configure it would be ConfigMaps or environment for Jellyfin's config. However, currently, the config volume contains 11785 files.

[chris@ovirt01 emby]$ find config/ -type f | wc -l
11785

Even ignoring the config/metadata folder and I have nearly 300 files.

This includes a huge amount of stuff that is simply cache, metadata and defaults. These have no place in the config directory.

By all means this directory can be mounted as a volume, but should be called something else (metadata?). Config needs to come from a (ideally) a single file and/or environment variables.

@JustAMan wondering if you've hit this:

dotnet publish --configuration Release /var/home/joshua/Projects/Emby/jellyfin/MediaBrowser.sln --output='/var/home/joshua/Projects/Emby/jellyfin/usr/lib/jellyfin/bin'

ImageMagickEncoder.cs(2,7): error CS0246: The type or namespace name 'ImageMagickSharp' could not be found (are you mis
sing a using directive or an assembly reference?) [/var/home/joshua/Projects/Emby/jellyfin/Emby.Drawing.ImageMagick/Emb
y.Drawing.ImageMagick.csproj]
PercentPlayedDrawer.cs(1,7): error CS0246: The type or namespace name 'ImageMagickSharp' could not be found (are you mi
ssing a using directive or an assembly reference?) [/var/home/joshua/Projects/Emby/jellyfin/Emby.Drawing.ImageMagick/Em
by.Drawing.ImageMagick.csproj]

etc.

I suppose the debian/rules config is missing a step, any thoughts?

The more I think about it more I think/feel the ports should be change from the default 8096 & 8920 to something else instead of the user having to do it. This is a common practice amongst 99% of forks of other projects.

Maybe change them to 9880 & 9943, just an idea.

Documentation the HTTP API in OpenAPI 3.0 format.

https://swagger.io/specification/

In various spots, there are references to Premiere and Connect. Some of these were just links for more info (see #32 where I changed some of these).

We should look at how we can effectively “remove” these entries/links from the UI, so users don’t encounter them.

I imagine the underlying code can be left as is for now (if there’s no way to call it, is it really there?). That way if we opt to rebuild connect somehow, we have somewhere to start from.

1. i've read here and on reddit that most of the devs use linux. what are you guys using for a development environment? my exp trying to do some emby dev with mono was not good. has it become better
2. related to #1, i also tried to write a plugin, but had quite a few issues, and feel like it was probably a mix between my VM running windows with visual studio and me just not getting the environment right, as well as the Plugin API "documentation" not being great. Since this is striving for openness and contrib, can we try to somehow get a nice "guide" on getting jellyfin dev environment going and plugin api docs/examples
3. any chance jellyfin moves to gitlab instead of github

As reported in the Riot room, there are some commands for .NET Core that send back telemetry to Microsoft (see reference: https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry)

At present, the commands that do this are believed to be:

• dotnet build
• dotnet pack
• dotnet restore
• dotnet run

According to the reference page, there is an environment variable that can be used to disable these. We should include this in our instructions/package/build so that we don't accidentally send out details without permission.

(thanks to qurqar in #jellyfin for reporting this.)

Unhandled Exception: System.AggregateException: One or more errors occurred. (Access to the path '/var/lib/emby/logs/server.txt' is denied.) ---> System.UnauthorizedAccessException: Access to the path '/var/lib/emby/logs/server.txt' is denied. ---> System.IO.IOException: Permission denied
   --- End of inner exception stack trace ---
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at Emby.Server.Implementations.Logging.FileLogger..ctor(String path) in /var/home/joshua/Projects/Emby/jellyfin/Emby.Server.Implementations/Logging/SimpleLogManager.cs:line 172
   at Emby.Server.Implementations.Logging.SimpleLogManager.ReloadLogger(LogSeverity severity, CancellationToken cancellationToken) in /var/home/joshua/Projects/Emby/jellyfin/Emby.Server.Implementations/Logging/SimpleLogManager.cs:line 52
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.WaitAllCore(Task[] tasks, Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at MediaBrowser.Server.Mono.MainClass.Main(String[] args)
[1]    3169 abort (core dumped)  dotnet /usr/lib/jellyfin/bin/EmbyServer.dll

Temporary workaround is to start server manually with sudo dotnet /usr/lib/jellyfin/bin/EmbyServer.dll
Ubuntu 18.04 using the apt package, dotnet version 2.1.5

When adding a user, currently functions such as those referenced by nice titles in src/jellyfin/MediaBrowser.WebDashboard/dashboard-ui/strings/en-US.json such as DeleteMedia (being the most dangerous) are flagged positive by default. This has always entertained me regarding emby - superuser is default user!