zoriya

This project deserves to be more known!

There is an android app, available as an apk in the release tab of github (I plan on publishing it on the android store this summer).

There is no flatpak and no linux/mac/windows client yet. Right now client support is not a priority, I want to focus on supporting more features and stabilizing bugs before creating clients, but this is definitely in the todo.

There is no plan to support SQLite in the future, Kyoo already uses multiples executables/containers anyway. Postgres offer better scalability with little disaventages.

Yes I agree, ffmpeg handles every video format, codeces and hardware accelerators for us. I don't see how we could replace that.

In C, I was using ffmpeg's functions directly instead of their CLI. I was manually decoding packets, frames and so on. Having to do all of this, I quickly became familiar with how ffmpeg works (and got able to read their source code) ; but this level of control was unneeded to create a HLS multi-variant stream. I made more sense to simply call ffmpeg via it's CLI interface and use a higher level language to manage states.

I then moved to rust, mostly because I was curious about the language. When I decided to use the original's video keyframes I needed to rewrite everything anyway, so I decided to change language at this time. The CLI interface did not change but using golang made state management easier since it has great tooling for (goroutines, concurrent maps, channels...). Rust lacks those tools, and it was hard to handle mutexes and so on.

Some times ago, I introduced my self-hosted media browser [Kyoo](https://github.com/zoriya/kyoo) here (plex/jellyfin alternative). I received great feedback and continued to work in it since. I decided to talk more about how Kyoo works under the scene, so here is my first blog post about that!

This is one of my first blogs, so I'm eager for some feedback!

Thanks for the nice words, I must say I was not expecting that many people to like kyoo. That's really heartwarming <3

i must say I don't know what that is, would you care to explain what that means? you want kyoo to record tv content for you?

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")

yes sorry

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

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.

would love to be available on ios tho x(

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.

For now, I'm not doing anything, websocket is next-release big change. I did not know about soketi tho, i'll take a look.

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).

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.

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.

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.

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.

You technically can, but that's not really the goal of kyoo, you would not need most features.

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)

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.

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.

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.

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

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

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)

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.

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 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.

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"