Replace the frontend main page to support movies and shows based on a pre-existent open source TMDB frontend

[filipef101]

Just a thought, there are many (react or whatever) TMDB clients out there, no need to do the UI for showing the movies etc.

Is this something that would be accepted?

[diericx]

This is a very interesting idea! I honestly did not like dealing with the front end very much and kind of burned me out, so reducing the work there would be amazing.

Do you have any open source front end clients in mind? I'd be down to scope them out.

[jkaberg]

@diericx Maybe something like this? https://github.com/AbdelhakimMhioul/Movie-App

Demo running here, https://movie-app-vue.vercel.app/

There's several like this one out in the wild

[diericx]

I apologize for the late responses here. I took a bit of a hiatus from coding.

Yeah this would be awesome. It would allow us to offload most if not all the front end work and focus on making a more robust back end.

I have been thinking about a completely different design for this project though if anyone is interested. I just think it may be unnecessary and possibly counter productive to try to flesh out a separate torrent client when it is entirely possible and more convenient to simple connect to something such as qBittorrent. Especially when hosting on a server that already has many torrents. I would not want to transfer to another client myself, so I think this makes more sense.

That design would still require a front end though and this is some awesome advice.

[diericx]

I actually realized some time ago that this experience can be solved completely by combining some existing tools:

• Torrent client that supports sequential downloads
  • qBittorrent
• Torrent fetcher
  • Jackett
  • Sonarr/Radarr
• File hosting
  • SMB/Jellyfin
• Local media player with network support
  • Jellyfin client/Infuse

Now I will admit it's definitely a lot to orchestrate and I don't really use this entire stack for that reason. There may be room for an all in one tool that focuses on the experience of easy streaming from a seedbox... it will just be a lot of reinventing the wheel in my opinion.

[jkaberg]

@diericx absolutely, and I did play with that thought. What if one created an script which downloads and populates an folder which represents trakt's popular and trending list (maybe running as a cron?). Then put an fuse filesystem over this (for instance btfs). Then that way you could point jellyfin at that and use jellyfin clients, would be quite feasble. Only drawback I can think of now is you won't be able to search for additional content (from jellyfin), which would suck UX wise.

Very simple architecture: cron script to pull torrents that trending/popular to folder -> mount btfs which creates an new folder with files streamable via torrents -> jellyfin -> jellyfin client

[diericx]

Yeah I think btfs is such a cool idea and a great option for adding scrubbing support.

As a side note, I think it's important to prioritize compatibility with modern torrent clients and I'm not sure if that is possible or efficient to do with btfs. I just don't think it makes sense to try to build a tool that aims to replace the existing torrent clients used for seedboxes. This is actually the main reason I didn't end up using this tool myself after I got this initial POC working.

It causes resistance for people already maintaining seedboxes and just reduces the usefulness of the project. I feel that a key goal for this project should be to build a tool that acts as a layer on top of somebodies existing torrent client/library.

I also think in general scrubbing-while-downloading support could be something reserved for a second more mature version. I think the momentum of this project would benefit from imagining a v1 that doesn't allow for scrubbing or server side transcoding. While not insanely complex, those are the biggest problems to tackle and most torrent clients allow for sequential downloading which already opens the door for streaming a video/audio file.

But removing transcoding from v1 brings up another issue...

That UX issue you mentioned has bothered me as well. I don't even use the Jellyfin web client because my remote servers and local rpi aren't strong enough for server side transcoding/remuxing of larger files and the web browser client (on Firefox) very often doesn't support the containers I am downloading.

So regarding this project we are stuck with either trying to develop some native app that communicates with a server (so we can run remux locally), or sticking with the experience of:

1. Select torrent from website search dashboard
2. Stream from a separate client that can transcode locally

I can't remember how PopcornTime handles this...

Idk it kind of seems to make sense that the seedboxes should be solely responsible for streaming files and the clients handle transcoding, but I am coming from the perspective of powerful clients. I am generally streaming to a laptop or an AppleTV. I imagine this experience would not work when trying to stream to a weak smart tv or something...

Sorry for the brain dump, while I haven't been working on this a ton I've been thinking about it a lot haha interested to hear your thoughts.

[jkaberg]

I do agree with your sentiment regarding modern clients and if the API is good enough that might very well be the best option

Regarding transcoding, as we are talking about torrents and there are often a lot of different versions one could instead of transcode try to find "common ground" (eg what codecs are most commonly supported) and select torrents based on that (or in Jellyfins instance one could feed jellyfin with several versions of the same media and let user select from the client).

However I do agreed that clients should do the heavy lifting in any case, and in my case I will run such solution from an cheap vps which most likely wont be able to transcode so it really doesnt make sense to support it either. Only constraint in such case is bandwith, which usually isn't a big deal now'a'days.

Anyway I think the first apphroach could be to

1. gather torrents (based on criterias?) and cache them locally - we would need some logic to periodically check health of torrents and remove/update them accordingly
2. create (or find?) an file system which mounts torrent file structure to local filesystem
3. offload (filesystem) read/seek operations to qBittorrent or similar?

I'm thinking of this apphroach as stages/levels:

1. gather
2. present
3. consume

I'm thinking that stage 1 should be a seperate process as to stage 2 and 3. the reasoning behind this is people have different apphroaches to gather content, while stage 2 and 3 tightly coupled and it makes sense it would be the same solution

the big upside with the filesystem apphroach is you're not bound to any server/client at all (it's decoupled). focus on getting this right first (eg streaming torrents), then move on to the UX layer (how do we consume the content) later on?

[jkaberg]

something like this (very HLD and not very thought through)

[diericx]

So to make sure I understand correctly, the goal of gathering torrents (but not starting them, correct?) is done to create a shell of a media library that looks like a file system. The higher level goal here is to populate Jellyfin with all the media we might want to watch?

That is a really cool idea and is probably the only way to truly integrate with programs like Jellyfin, but it just sounds like a lot of work surrounding maintaining a set of active/healthy torrents for media that we will only potentially watch.

If one of the core goals is to directly improve upon the experience of programs like Jellyfin then this would be the way to go, but I think that might hold us back.

The main goal is to provide an on-demand streaming experience, and it seems like it would be easier to simply fetch the best torrent at the time the user wants to watch any given piece of media.

I really like that idea about choosing the container though... but I don't think Jackett or trackers in general provide that kind of information in their queries. If I remember correctly in this project I was connecting to peers and fetching the metadata to make decisions based on the files in the torrent.

Here I add the torrent in the loop searching for the best release, which subsequently calls AddFromFile or AddFromMagnet which both call GetInfo to fetch metadata here.

We could still fetch metadata like this and just offload the downloading to the user's torrent client, I just don't know how trackers will feel about that. It can also take a LONG time if we are searching for a specific container. I remember it taking up to like 20 seconds to fetch metadata depending on how long it takes to connect to a peer... if we had to loop over each torrent to find a specific container it could take forever.

[jkaberg]

So to make sure I understand correctly, the goal of gathering torrents (but not starting them, correct?) is done to create a shell of a media library that looks like a file system. The higher level goal here is to populate Jellyfin with all the media we might want to watch?

Yes (or similar) - for instance you could use Kodi on the client and use SFTP to access the filesystem. Or use VLC locally :-)

That is a really cool idea and is probably the only way to truly integrate with programs like Jellyfin, but it just sounds like a lot of work surrounding maintaining a set of active/healthy torrents for media that we will only potentially watch.

Yes, but I don't believe it's a lot of work. And in my case (HLD above) heavily based on trakt lists which dependent on what the user limits in regards to media items. It mainly consists of looping through the trakt list, looking for torrents corresponding to the media item (where we do some sorting depending on criteria's such as seeders, quality etc) against jackett and the outputting the torrent to folder structure. There's not much business logic here (in my mind :-))

The main goal is to provide an on-demand streaming experience, and it seems like it would be easier to simply fetch the best torrent at the time the user wants to watch any given piece of media.

Yes that's the goal (for me) - however as you noted earlier we're stuck maintaining UX/UI, possibly transcoding, subtitles and other stuff. This way we offload this to existing projects.

I really like that idea about choosing the container though... but I don't think Jackett or trackers in general provide that kind of information in their queries. If I remember correctly in this project I was connecting to peers and fetching the metadata to make decisions based on the files in the torrent.

I was simply thinking of using something like guessit to identify media, which we in turn would offload to client which ideally would present/give options to end user. This is not an optimal approach obviously, but sufficient?

We could still fetch metadata like this and just offload the downloading to the user's torrent client, I just don't know how trackers will feel about that. It can also take a LONG time if we are searching for a specific container. I remember it taking up to like 20 seconds to fetch metadata depending on how long it takes to connect to a peer... if we had to loop over each torrent to find a specific container it could take forever.

yeah absolutely agreed. I think background tasks and cronjobs might do us good here, along with an cache. This might be hit'n'miss sometimes, but overall would outweigh the

[jkaberg]

so just did some research here, if distribyted supported ionotify (that would "hot" reload the watched directory) we'd only be missing the gather part which I think should be quite feasible. the project doesn't seem to be very active tho, but promising.