I started working on Kyoo almost 5 years ago because I did not like the options at the time. It started as a "sandbox" project where I could learn about tech I was interested in, and slowly became more than that.
Looks very pretty and the demo is nice. Congratulations on the launch. I'm a happy Plex user, via Plexamp for audio and the Plex app for Apple TV for video, and I'm not interested in switching. That said,
> It started as a "sandbox" project where I could learn about tech I was interested in, and slowly became more than that.
This is a fantastic reason to build something. Looks like a wonderful project.
In case you‘re into audiobooks, I suggest to check out Bookcamp too. I guess Plexamp works for that as well, but Bookcamp is just like Audible in a way.
I love ABS but I use it mainly for podcasts since it downloads each episode to my server which I then stream from. It’s awesome. My only gripe is the iOS app, which is a pretty slow webapp wrapper.
I second the other suggestion for Prologue on iOS as a Plex frontend for audio books. It’s such a good experience that I’m now listening to more audio books than before and they also just launched an Apple Watch version.
Seconded! (Or thirded?) Prologue is so much better than Audible. I’m using Libation to liberate my copy protected audiobooks, not to share them but to avoid that godawful Audible app
> not to share them but to avoid that godawful Audible app
It’s sad how true that is for many things these days. I usually download shows to have them in Plex even though I have many paid streaming accounts. Just because it’s a better UX and it also automatically scrobbles to Trakt.tv.
The biggest hurdle I've run into when trying to manage an audiobook library with Plex is the metadata source. There are a few plugins that try and gather from Audible, I assume by scraping, but it's always minimal and very flaky. I haven't revisited this for a while now though, so hopefully things have improved - I would love to start archiving my Audible collection.
I've noticed that in general, a lot of selfhosted-adjacent apps tend to get negative reviews. Without having looked at bookcamp specifically, I've noticed that a lot of times, it's because those apps require a minimum level of competence from their users, and those users that miss the threshold generally leave negative reviews.
Not OP, but I just stream from it as a better Spotify alternative. It uses opus codec for encoding, which works really well even with a slow CPU. The playing is instant.
Jellyfin uses AAC, which then spins my homelab fans when I try to encode anything. With opus the fans stay silent.
I'm admittedly unfamiliar, but have appreciated the effort the developers took to make Plexamp a native CarPlay app. What's your perceived limitations of Plexamp on Apple CarPlay and Android Auto?
I admittedly have a car with lots of road sound, so maybe I'm not the target audience for lossless car audio.
I don't have either of things you mentioned, so it's just Bluetooth, but the UX tends to be better with Spotify/Tidal connect. No drop outs, no battery drain, etc. (generally speaking, not just car)
I mean, you usually should not spin down your NAS drives. They add wear and also consume more energy that way.
We use plexamp with Android Auto, and with the usual car sound system 128 kbps opus is transparent. You can stream with the original flac quality of course, but I've found it to be way too much in our trips.
Streaming music with plexamp has never been an issue for us. It just works.
(On spinning down) Well that's what everybody parrots but this isn't a business and it's for my own pleasure. It's idle unless I'm engaging with content.
It would be silly to burn that energy just because it's the status quo?
I mean, I would prefer to avoid those stalls but still
--
If I had CarPlay I'd be happy car-wise. But Spotify/Tidal Connect means all of your devices become remotes. They all behave as if they're the player and have the ability to change where the output goes. It's really slick.
I have Jellyfin setup in parallel for the day Plex enters an「enshittification」phase, but the lifetime membership I paid for in 2012 has served me well.
I tried switching from Plex to Jellyfin, and one of the greatest limitations that I noticed with Jellyfin is that it doesn't seem to really give a shit about managing libraries, and seems overly opinionated about file structure. There's whole sections of the wiki dedicated to naming your files right that I don't have to deal with with Plex.
Does Kyoo take a similar approach, or is it more user friendly? Plex's monetization efforts are silly, but Jellyfin seems very much not ready for prime time.
I find this extremely silly too. The goal of kyoo is to organize your library for you, you should be able to use your download folder as your library folder, and it should work right away without having anything to rename.
There are still some edge cases, especially with extra which are not handled very well right now.
It works even for weird anime naming, things like "[SomeGroup] Jojo's bizzare adventure - golden wings 12.mkv"
Just a question, why do you guys want sn unopinionated media server? I love that I click some buttons in jellyfin and it just does it's thing, I don't have to think of my own structure
I hate having to rename my files on an arbitrary pattern to have items show up in the media browser. I want a media browser to organize my media, not to ask me to organize it myself.
Maybe I'm not understanding, but they only organization I do is put each movie and related files like cover and SRT into its own folder named after the movie. Seems to work fine.
YMMV of course but Jellyfin supports manual tagging well enough for my uses. No need to change filenames and break folder structures you set up for easier navigation in file browsers (as I did), you can click the "Identify" option on a file/folder and search your enabled databases by title or IMDB number. Once you tell it what TV show a folder is for, all the episodes seem to get automagically recognized. It's just that first step that doesn't happen by itself when the folders aren't named "correctly", and you could probably get around it by using Tiny Media Manager to mass-write NFO files (which Jellyfin recognizes).
They used to have an auto organize plugin which was doing that very well - but sadly it is no longer maintained (and no longer working on current versions). I did have quite a few things not correctly recognized with Plex which went away after going to Jellyfin and letting auto organize do its thing.
On the plus side, lack of auto organize made me properly setup the complete arr stack, which throws things into correctly named directories, does support batch renaming for existing stuff, and handles a lot of other stuff on top of that.
Out of curiosity, why are Plex's monetization efforts silly? Sure, the freemium model is less than ideal compared to OSS, but I gladly paid for a lifetime subscription to Plex Pass 4 years ago and haven't regretted it at all since.
I think the main issue is that the monetization efforts have resulted in blunted focus on the core product, resulting in things like long-standing unresolved bugs and technical oddities. For example the Plex installation on my home server will break itself in odd ways every so often and sometimes the only way to fix it is to nuke all cache, config, etc and start over which gets frustrating.
It’s also brought privacy concerns, because there’s incentive for Plex to harvest and sell data from users paid and unpaid alike.
I’m currently subscribed, but all of this has me on the lookout for viable replacements.
I've been using Plex forEVER and the only time this kinda thing happened to me was when the scratch space Plex was using for transcodes and things got full
Nah there’s at least a few hundred gigs available at any given time. Usually the breakage has to do with plugins just ceasing to function or Plex somehow forgetting its library exists, which results in only the free-stream-crap channels showing up in clients.
Also, everything in my library can be direct-played by the clients I use (primarily Apple TV 4k) too, so transcoding pretty much only happens when I’m loading up my iPad for a trip (once or twice a year tops).
I think part of it is that the efforts are all going to be kind of dodging bullets, in that everyone knows that a popular use case of Plex is for pirated media. So all monetization efforts have to be carefully designed to not risk implicating the project directly into that use case. Which means that monetization efforts mostly lean slightly differently from what the users would want to pay for.
The only monetized features that have decent overlap with user desires are the player features, mobile apps, plexamp and its sonic analysis stuff.
I don't quite follow here. Assuming a common use case is personal consumption of pirated content, doesn't it make sense that the monetization strategy focuses on the server/client software itself?
More importantly, that monetization strategy is a great fit for legal self-custody. I have a pretty large library of content I bought on DVD and ripped for personal use. I don't share it our as torrents and watch videos locally on my own network, there's nothing wrong with that and I like that Plex is still paid for the software that makes it work well for my use case.
I mean, their monetization strategy has lately been more focused on service provider type stuff like advertising and movie streaming, not server/client stuff.
They are pushing their free with ads offerings and data gathering (Discover) far more in the past year or two, to the point where I have to give instructions to some of my friends because the defaults are exclusively their own offerings.
That's because your friends are independent, separate Plex users from you, even though you and they don't want to think they are. Just because they can use the Plex app to connect to your server doesn't mean that they are not separate.
I get the frustration - Plex didn't do it in the past, but if you look at it from 1000 ft, and are ignoring history, Plex isn't doing anything crazy here. If you install the app on your phone/Roku/whatever, it's on you to understand how to use it/customize it.
Except that it’s a massive change in behavior from what they have done for over a decade, which is to prioritize the product they built: a streaming media platform intended for personal collections.
It isn’t about the users being Plex users “even though I and they don’t want to think they are” (an incredibly presumptuous way to phrase that, honestly) it’s about a fundamental change in behavior and execution in their product.
Nobody said they weren’t within their right to do what they’re doing, but people should be allowed to point out when this happens. They are fundamentally changing the way their app works. That is an user-hostile action regardless of how you slice it. And that might be fine from their point of view, but it clearly is an issue for existing user, as this entire thread of comments shows.
Out of all the things to take issue with about their monetization model that is such a wild take. Do you also have issues about paying for a videogame that uses your GPU? Probably not.
Any paid software you can run on your own hardware by definition is paying to use "your own" resources(CPU, GPU, storage, etc), what you're paying for is their effort in creating and maintaining the software. If they want a gatekeep features for a premium version that's their right, if you have a problem with it find something else or make it yourself.
Of course it's their "right", but it's also not very smart to gate a feature that determines whether or not the product actually functions. The potential customer is faced with a non-playable video and a promise that paying will make it play.
Both Plex and Jellyfin refused to import my fairly standard and accurately tagged music library last time I tried, and Plex is definitely opinionated about structure in video libraries.
Jellyfin wasn't happy with my music library either until I realised wanted the ReleaseGroup field to be set. I set Picard to work and an hour later it imported perfectly.
I saw discussions on GitHub where it was suggested that they refuse to match based on metadata over folder structure because they don't trust people to tag files properly. With my library, it generates multiple album entries per multi-disc album because I have them organized with a subfolder per disc, which not only makes no sense considering when you could easily match on disc number and parent folder, but is also a regression. "Short on developers" is a good excuse for lagging in features, not for poor design/implementation. Finally, relying on non-standard fields for matching is unnecessary and is in line with the "overly opinionated" complaint.
I'd probably use Jellyfin if it got the basics right and lacked a thing or two, or if its opinionated implementation was limited to trivialities like how Plex refuses to use local images not named cover.jpg. But it's too opinionated, too inflexibly, about too many things, and I think its opinions are stupid, so it crosses the line as far as I'm concerned. Doesn't help that the code is convoluted and I couldn't figure out how to make changes to the way it analyzes files easily.
I think my problem was that I used Beets to organise my mp3s a long time ago - maybe 2011. It didn't write the ReleaseGroup because that might not have been present for all albums on MusicBrainz at the time.
It still did a great job and Picard nicely filled in the blanks.
Nobody has mentioned Emby yet. I switched from jellyfin to Emby and I am overall happier with the UX. I don't know if your specific grievance will be addressed but it's worth looking into.
I wish they would add a feature to clone the metadata database (including pictures of movie covers and actors). My fear is that imdb will disallow scraping especially for people like "my friend" who has thousands of movies.
Looks nice. One thing I’ve noticed is that media server projects seem to have a disposition towards C# specifically, which I find interesting. Is there a technical reason for this or is more of a big project setting norms situation?
Most related software too (the *arr family) are written in .net. It's a decent platform offers good performance without sacrificing developer experience.
c# shines for webserver stuff so it's no wonders, I like it less and less tho
Kyoo also uses python/golang for some of it's components (and typescript for the frontend)
I don't like the closed environment where you are not a first-class citizen if you are not using vs or rider. I always work on vim and linux, and I am getting tired of fighting with whatever new stuff microsoft makes that does not work out of the box (their latest LSP that does not follow the spec they created themselves as my latest example).
they are definitely making progress but that's clearly not the most open ecosystem. for example there is no open source debugger available (there is netcoredbg which is community maintained and lack important features or there is the vscode one which is licensed as "you need an official vscode version to use it, even vscodium can't use it")
It’s what I run on my home server. Most of my interaction with a command line is with macOS, which makes BSDs more familiar, and jails are nice for containment that works without external tools. First class built in ZFS is nice too.
I wonder if publishing for FreeBSD without one is problematic if you use either single-file JIT (trimmed, self-contained) executables or NAOT ones.
But given it's a server, such workloads generally favour JIT so it should not be an issue but I understand what you are getting at. With that said, it certainly doesn't seem to be as easy as `sudo apt-get install dotnet-sdk-8.0` but not as bad as building everything from source (which should not be too bad still, build.sh in dotnet/runtime does a lot of work for you to be able to just clone and build and the repo also has instructions for building for FreeBSD).
This one looks like it's written in several different languages. I see some C#, Go, Python. Maybe there's some front end stuff too, but I'm allergic to that.
Having both postgres and rabbitmq strikes me as overkill - I wonder if they'd be open to a PR to harmonize to just PG, slimming down the ops burden. I'll have to dig into it when I'm back on my desktop to see what exactly RMQ is doing for a media server
rabbitmq is used to communicate between services. I just introduced it but it will be used to:
- handle websockets communication with the client
- create workqueues for new items creation/rescan requests
- Watch list syncing with external services
- and to synchronize different replicas when deployed on k8s (still need work on this point tho)
I'm not here to talk you out of rabbitmq now that you've already added it for this project, but IMO it's worth taking a look at PG notify/listen and keeping it in mind for simple use cases.
It's not nearly as powerful but it can be a pretty good starting point before pulling in more dependencies.
If you're in dotnet land, I'd recommend looking at magic onion [0] or memorypack [1]. It'll be much nicer to work with once you have a decent pile of message types. Otherwise it's easy to end up in an entity framework like situation where you're constantly serializing and deserializing, generating serializer wrappers, doubling up on dtos and schemas, etc. Although any of the cysharp libs are great in dotnet, definitely recommend checking out their back catalogue.
I run ffmpeg on small segments of video and when you seek too far from the current transcoded position, i create another ffmpeg process. The hard part is making sure those segments can be watched without gaps or issues and no audio/video segment is repeated.
If there is enough interest about it I might make a blog post explaining this in details
I'm using the time skip/seek functions more than I should and Plex, Jellyfin, Emby are really not good in that department. I was WAITING for somebody to fix this problem. Plex, Jellyfin, etc. None of them came close to the youtube experience. It always felt very slow and clunky. I can't thank you enough for this really. Thank you very much for addressing this issue and creating this amazing project!
Pity that they don’t handle music. That’s my primary use of Plex: managing a music library. I feel like that’s a secondary focus for Plex, too, but it’s good enough.
Just the other day I was setting up Jellyfin and tailscale on an n100.
It worked fine locally but sharing via tailscale with a family member across the world somehow broke things. It took about a minute for the stream to start despite a fast enough upload speed. Might be ping related?
I had this problem too! Jellyfin behind a reverse proxy over Wireguard. For intercontinental visitors (high latency), there would be an initial burst of reasonable transfer speed, but within seconds, slow to an unusable crawl. It took a long time to identify the problem as relating to packet congestion.
Try changing Linux's default congestion control (net.ipv4.tcp_congestion_control) on your Jellyfin & reverse proxy servers to 'bbr'. I don't understand the details- there might be negative consequences [1]- there might be better congestion algos- but for me, this completely solved the issue. Before, connections would stall out to <10%, sometimes even 1% line rate. In quiet/optimal network conditions.
Also, Caddy enables HTTP/3 by default. I force it to HTTP/2.
I should probably investigate using later versions of bbr, though.
My issue ended up being the auto-bandwidth negotiation being sorta shitty in jellyfin, i set my remote over headscale web browser to 10mbit and the tv shows play very quick though could maybe be a bit faster.
Wish I could say it was more sophisticated than slow trial and error. I tried changing many different aspects: MTU, forcing different routes/peering through different VPSs, various reverse proxy configurations.
I guess what started leading me down the right path was a more methodical approach to benchmarking different legs of the route with iperf: Client <-> reverse proxy, reverse proxy <-> jellyfin server. I started testing those legs separately, w/ and w/o Wireguard, both TCP and UDP. The results showed that the problem exhibited at the host level (nothing to do with Jellyfin or the reverse proxy), only for high latency TCP. The discrepencies between TCP and UDP were weird enough that I started researching Linux sysctl networking tuneables.
There might be something smart to say about the general challenges of achieving stable high throughput over high-latency TCP connections, but I don't have the knowledge to articulate it.
Not yet, I plan on having that available in the next 6 months since it's pretty important, but I want to have most client features finished before that
The Jellyfin Android TV app had a lot of improvements over the last year or so. But they're still working on a new playback approach that works better with transcoding of audio and HDR/4k for compatibility with devices. Because it works now maybe 95%, but that really annoys users when they try to watch some of that 5%...
But I'm not aware of what the equivalent would be for Amazon-type casting
I wrote a wrapper around catt for playing music to my house speaker-groups. It also works with video but I don't cast video as often so that part might be buggy--in that case better to use catt directly
I'm glad more options are cropping up with the direction plex is heading. I'd like to see someone build a hook/connect straight into SONARR/RADARR where you can just click on a calendar entry and jump to a player. They're probably weary of doing it themselves due to legality. But combining self hosted media with... pirate management into one interface would be convenient.
Looks good. I went to the demo page and clicked on a few movies and scrubbed through at random. Everything worked flawlessly.
I'm curious to know about scaling. How many users does a server (and of what kind) support? What's backing your demo page and how many users would overload it?
Thanks a lot.
The demo is the docker-compose from the README on an oracle's VPS always free tier.
I never tried to benchmark the server, but the limiting factor will certainly be the encode speed of the machine. If your clients all needs transcoding of different h265 8K movies at the same time, you would need vastly different GPU/CPU power than for the same amount of users with direct play.
it's good when you watch things from outside your home network. you can transcode things to watch on the train/subway or somewhere you don't have stable internet access.
probably not in a close future since it requires paying $100 a year per app to publish to the app store. i also dont have any apple device so i cant even test it.
i dont know how hard/easy it would be to port the app in itself tho, its written in react native so it should be pretty straightforward but you never know.
It can direct play whatever your client supports, for now only android and web are supported clients.
Web browsers aren't great with media compatibility tho, I think you will face the same limitations as with Jellyfin.
Jellyfin is compatible with the Infuse media player on Apple TV. I don't have one but have used it on other Apple things and love it, it's actually a bigger issue with Windows because I haven't found anything nearly as good on Windows as Infuse is on Mac.
It's very pretty, and the demo is very fast. Is there series tracking to continue watching to pick up where you left off? It doesn't seem like there is on the demo.
My only concern is that your screenshots on the github include copyrighted movies. I know that unlike popcorn time (or whatever the name was), it's only a player and not a way to download things, but maybe change them out for your copyright-free movies on the demo? I'd hate to lose another project to overzealous copyright enforcement.
There is a series tracking (which can be autosynced to simkl if you want) but you need to login to use it. Since the demo allow you to access everything as a guest without account you probably missed it.
The screenshots are pushed on a secondary branch, so I can remove them completely without rewriting the git history. Thanks for worrying <3
vau. after having used plex, jellyfin and emby, the video player seems very responsive and good designed. Time skipping is almost instant and the interface seems fairly clean. Thanks for the great work!
No, I want to stay focused on movies/series/anime. There's already a lot to handle for me alone working on this, and ebook/music is just different enough that supporting it will need a good amount of efforts.
This looks great, but it makes me very sad and annoyed through no fault of its own.
I started building a Plex/Jellyfin clone in 2019 (around the same time it looks like!), got pretty far into it as well, using a pretty similar messaging system and everything (using ZeroMQ instead of Rabbit).
I was working for Apple at the time, and I wanted to open source it, so I had to talk to a bunch of management, eventually someone just two levels below Tim Cook, who told me that it was a "competitive" product, because it served video, and Apple sold video. He also informed me that if it's found out I open sourced it, I would be promptly terminated and would potentially face legal action as it would be in direct violation of my non-compete, and moreover since I was working for Apple they legally owned it anyway. He then explained that there's no such thing as "my own time", as Apple really wants me to be focused on Apple, and nothing else
I genuinely had to hold back tears in that managers office, because it really felt like a punch in the gut. I went in optimistic that I'd be able to open source my passion project, and I instead was threatened with termination and a lawsuit. I was so upset that I just left the office at 2pm and drove back to my hotel (I live in NYC but was visiting the California office).
Anyway, </rant>, this is cool and I will be playing with it tonight.
ETA:
I have no doubt that some people might be able to figure out the specific individual in this story, and that's fine, but I humbly ask that you do not post that person's name publicly here. I wasn't fired from Apple and I didn't have to sign a non-disparagement clause as far as I am aware, but I still don't want any extra drama from the company.
> I still don't want any extra drama from the company
Yeah, they are really good at that. I had a friend discover a vulnerability once, and behind the scenes they took it very seriously. But publicly, they disparaged him mercilessly and even got DaringFireball in on it.
I mean, I get it from the company's perspective. They have a product that serves video, you were building a thing that served video.
The thing that irks me is that since they build multiple operating systems and a wide range of software, literally anything you write and publish on the public internet is theirs simply because they will fire you and sue you into oblivion. Even if you _technically_ slip through a loop hole, they have more money and time than you do.
Stories like this remind me that I have to be careful about who I work for, the scope of that work, and where I publish it. Thankfully, I think I'm in the clear as long as I don't invent a thing that solves the traveling salesman problem.
I personally don’t really think Plex/Emby/Jellyfin are really “competing” with Apple. Jellyfin and the like require a geeky person to maintain and supply video files of their own, Apples products are easy and streamlined by design.
They’re superficially kind of similar but, like, depending on how abstract we wanted to get we could basically say that anything is competitive with anything e.g. “Your product has text, and we sell books that contain text, so it’s competitive”
Regardless, I guess what they said worked, because despite me not having worked for Apple for more than three years now, I still don’t want to open source I am still a bit worried about being sued (especially since I didn’t leave on the best of terms with them).
That said, my current job is much more reasonable about this stuff (and also much more domain-focused), so maybe I’ll be able to dust off my public GitHub again some day.
(Again, I am sure you can figure out which company I work at (I have public profiles) but I ask that you don’t post it here.)
BTW, OP's anecdote is how it's always been at Apple. Definitely in the early 00's, and probably all the way back to the 80's. I've known a bunch of great open products die because the person behind them got a job at Apple and was not allowed to work on it while employed.
I'm getting less and less impressed with the company, so I started diversifying. I got Linux installed on my desktop and started using it more often. Switched from Apple Music to Spotify. Got rid of my Apple Watch Ultra and switched to Garmin. Went from Things to TickTick since it's cross platform. From Notes to Notesnook for the same reason. I know it's a drop in the bucket and I'm still pretty invested, but they are steps towards independence should I decide to abandon their ecosystem altogether at some point.
I didn't catch this until you called it out. While I reading I was anticipating an argument that would convince me that I need Kyoo. I'm not convinced that its setup once and forget it -- especially since it also says that its not afraid of adding more services (complexity). Further, the hard stance on cinema only instead of books, games, etc made me think that the project was rigid. Making me potentially add more services to manage all of my entertainment media.
As a user, you don't really need to care about the number of containers since everything is managed by docker-compose or k8s (soon).
The advantages of having more containers is that you can have specialized softwares. For example, the search system is based on meilisearch which makes it way better than what could have been done by just using postgres/sqlite.
It also makes distribution or replication built-in (for example, to have a transcoder on a remote computer), jellyfin/plex does not support this natively and users have written their own remote transcoder for that.
Only half kidding, but you've heard of processes right? :)
Plex for example starts many transcoder instances within a single container for scalability. You don't _need_ to scale at the container level.
There's pros and cons to each approach, but for the self-hosting crowd keeping the deployment simple may broaden your audience.
A good example I have experience with is vaultwarden: people use it because it's a single container deployment as opposed to the complex and resource intensive setup bitwarden provides.
Not sure yet, I'm a beginner at k8s and just started writing a helm chart on a branch/reading the documentation. I have devops friends to help me with my skill issues tho x)
I was also surprised by that bit about adding more services:
> We're not afraid to bring in additional containers when it makes sense
That is one of the last things I'm thinking about when I choose a media organization and streaming app, and if I do think about it, having more containers is a red flag more than something that sets my mind at ease, because of that added complexity. I experienced this with Photoprism when I wanted to customize it a bit, because I then had to figure out the roles of the containers and which containers did and did not need the customization bits I was adding, etc..
You're right, but in today's github if you want to stand out you need this kind of readme or an existing community. To be fair, the important features are in bold and the philosophy/why another browser is handwritten.
I'd still recommend reviewing the output more closely, particularly in top-level paragraphs.
> Designed from the ground up, Kyoo stands out as a powerful alternative to Plex and Jellyfin.
This sentence doesn't really mean anything - designed from the ground up to do what? Plex and Jellyfine were both designed as well, so part of the first hype paragraph has me sitting here wondering what information was supposed to be conveyed here.
Project looks nice, though, and I have been wanting to move away from Plex for a while. Lack of TV/iOS apps is unfortunately a blocker for me, but bookmarking to check out 6 months from now. Good luck!
I’d be interested to know the status for the player apps on various platforms. For example, this is a nonstarter for me until it supports Google TV and iOS/iPasOS.
This is unfortunately a deal breaker for most home grown media browsers. They need to maintain apps on all the walled gardens their users are using, which is a ton of work IME.
Couldn’t this be addressed by standardizing around a protocol? That way client and server are decoupled and existing clients can work with new media server projects.
Well maybe, but smart TV and streaming box browsers are unlikely to implement all the functionality pertinent to a high-grade home theater experience. Apps are better here, so what I had in mind was closer to standardization around existing popular protocols like that currently used by Kodi and Plex, both of which have high quality clients for just about every platform out there.
There is some interoperability between other clients today. For example, I have a Jellyfin server but in order to connect to it on my Apple TV I use the Infuse Pro app. I think that works more because of a standardized file structure that each app creates its own indexes for, so an actual protocol that they share would still be an improvement.
Infuse implemented code specifically for jellyfin and it uses jellyfin's own API. The only common protocol is dlna, but it's pretty limited and only really used on local networks.
That would slow down development and new idea down a lot, I don't think it's even worth considering. It's probably easier to implement it on Kodi/Infuse/any other clients.
> It's probably easier to implement it on Kodi/Infuse/any other clients
Yep, it's definitely easier to get third party clients to implement your protocol. Kodi you can write your own plugins for, Infuse... requires their devs to care about your implementation. Chicken, meet egg?
That said, I also fully admit I have no knowledge of your codebase, nor any knowledge of how extensive / complicated the jellyfin (or any other comparable media server) client api looks like, and I assume you have a better idea!
Android and web only for now. I do agree that Google tv/chromecast is extremely important. ios/ipad/tvos is even harder since it's 100$ a year for a dev account to push it to the apple store and I don't own an apple device to write the app.
I want to focus on features before writing more clients, I hope to write Chromecast support in less than 6 mounts and google tv in less than a year.
I'm sure there's enough interest on HN to cover the $100 for a dev account for you and maybe get you a reasonable device to test on from Swappa. Maybe setup a donation link for an iOS/tvOS app? I think iOS/tvOS app would really make usage increase dramatically. People generally aren't against paying for software that works and makes things easier. Plex has become bloated and over-featured. Infuse is ok, but not great when trying to watch remotely, even over TailScale.
I do agree about the value of tv/native apps but for now I have a tiny user base, we are only 20 on the discord. I think it's still too early to have any kind of financial support on the project.
Because it's a great programming language, not sure about Mono, but .NET 8+ is now cross-platform (has been since sometime in 2016 actually), so I personally am choosing C# for some of my projects lately as a result.
C# is just a nice all-around language and the runtime is really nice.
By comparison every time I have to look at Java I just want to run away as quickly as possible. All the resources Oracle has, and instead of investing them into making Java a viable platform they shut down the one project that was giving Java an edge in Desktop Development (JavaFX) and basically leave Java in this weird limbo state its in.
It took Java forever to implement lambdas meanwhile C# had them in since .NET 3.5? (2007?)
Microsoft on the other hand, made all of .NET MIT licensed. Even if they change the license 10 years from now, you can pick any of the rich versions prior to use where the license was in fact MIT.
Just my own conjecture, but it's pleasant to write, the NuGet package ecosystem is very well populated, and it combines a great web framework with the ability to drop down into low level code when necessary.
In recent years cross platform support has gotten fairly good as well
I think (and I could be misremembering here) is that Emby started off as C# and both Plex and Jellyfin are forks of it. Also a lot of folks in this sphere seem to be on windows as their primary platform, and C# along with visual studio is pretty on that stack
but there aren't as many IDEs, NAS/homelab manager, backup, games, graphic editing or visualization tools, ... Is it something about codecs availability?
Great to see more competition in this space. I found it interesting that every component seems to be written in a different language. The only one that surprised me a bit was the backend in c# instead of go or node/deno. A bit odd for the scanner to be in python too...
That looks -very- nice. What's your experience been with it, do you use Plex or anything like that? What do you mean 'can't go back to transcoding'? What have you been using that doesn't transcode?
I’m using Infuse as well, and it’s pretty amazing.
The main thing that Infuse does differently from all the others is that it always does Direct Play (in Plex parlance) so you don’t need anything powerful or power hungry to be hosting the video.
Most devices that will play video these days are powerful enough to do the decoding themselves and have the bandwidth available.
I use Jellyfin and it defaults to direct play unless you need transcoding (e.g: the client device doesn't support the chosen format, Firefox with h265 for example, due to licensing) and it will just remux if the container is the only issue. The desktop client just uses mpv so it supports basically everything directly.
> Most devices that will play video these days are powerful enough to do the decoding themselves and have the bandwidth available.
IME this varies a lot between devices. Google TV dongles for example, even the 4K versions, are built with extremely weak SoCs (as in early 2010s phone weak) and lean hard on hardware acceleration. If you want to play back a format that isn’t hardware accelerated on one of these, you’ll have to rely on media server transcoding.
In my memory of Plex on my Apple TV device it was off by default and hidden in an advanced menu or something. Not impossible by any means, just annoying.
It can also direct play a lot of formats too though, because Apple TV boxes since the 2017 4K model have enough muscle for problem free software decoding.
Most audio streams are 'direct stream' when you use plex/jf/emby as backend, but your receiver/soundbar only gets the PCM stream, without any object data (yes, you loose atmos, not that it is a lot of loss when using a soundbar, but if you have atmos speakers in your ceiling you want that data)
in an ideal world, the appletv will simply passthrough the audio upstream, so you receiver can do what it does best.
Kodi is my favorite open source project, but I did start it up the other day and thought it felt outdated. I will look into Jellyfin-Kodi. Using Kodi's Games/eBooks/Podcast playing ability with Jellyfin (Streaming, transcoding) features might be exactly what I've been missing.
Classic rust fan :p I tried to write the transcoder in rust before rewriting it in rust. You can call that skill issue, but I did not like the language and needed a rewrite because I was taking a fundamentally broken approach anyway.
> It started as a "sandbox" project where I could learn about tech I was interested in, and slowly became more than that.
This is a fantastic reason to build something. Looks like a wonderful project.