Support for media in rar archives about jellyfin HOT 64 CLOSED

I'm really not a fan of this, both from licencing, code quality and consistency points-of-view. "Everyone is doing it" isn't a very good reason, and trying to read RARs means we need to include non-free software as a dependency - from Wikipedia:

No (decompression source code is available, but it's not free software due to the restriction that it must not be used to reverse engineer the RAR compression algorithm)

It's worth noting that RAR is a compression archive, and a non-free one that that, while e.g. AVI is explicitly a video container - there's no comparison there. And even ignoring the licensing issue I don't think the media player/library manager should be dealing with decompressing archives.

The administrator should decompress/extract RAR files on their own before importing the resulting media files to their library.

from jellyfin.

So I should preface this by saying I've very opinionated on a lot of this, because I'm a sysadmin first - please don't take this as offence or as a final word as a project leader, just my thoughts:

These reasons all relate to having a very hacky setup for handling the media files themselves, that you'd like Jellyfin/Emby/whatever to work around for you. That's not to dismiss your request, just to point out that, for instance, an "extra step" of extracting RARs on the client side is trivial, while on the other hand adding support for "directly playing" RAR files is definitely not, and I just don't think that's a good use of developer effort, even if we do get a few hundred dollars out of it. I hope you understand where I'm coming from there - there is a lot to do, not just due to the fork but to fix some long-standing issues with the original codebase as well, and this is a feature that wasn't present in Emby either.

I'm happy to leave this issue open and if a developer expresses interest in implementing this and can do so cleanly they're more than welcome to. But if you can provide more specific details on your setup maybe I can suggest a better workaround? For instance:

Not being able to extract, if the files are mounted from somewhere where you can not modify them.

What is the usecase here that the extraction couldn't be done on the server first? Or is this a case of trying to direct play off of a remote (Internet) server? Would download+extract not make more sense long-term?

And in two cases you mention wanting to preserve the original RARs, but for most usecases that is simply a waste of space; why not extract them, play back the extracted file, then recompress it when you want to share it elsewhere or archive it?

Ultimately I just want to understand better why "playback of RARs" is the best solution here!

from jellyfin.

I vote no rar support. It’s not a high priority, rar is proprietary and not well supported on many platforms.

from jellyfin.

So I should preface this by saying I've very opinionated on a lot of this, because I'm a sysadmin first - please don't take this as offence or as a final word as a project leader, just my thoughts:

Absolutely, a healthy discussion from a fellow sysadmin is good :) I'm not taking this personally in any way and I appreciate that this issue has not been turned into a piracy flame war or something else like the original feature request turned out to be at Emby.
However I had hoped this discussion would be more around the technical implementation of supporting media in rars and not a debate on the reasons why some people choose to store their media in rars and why it's not to everyone's taste.
Never the less I'm happy to answer any questions as best as I can. I have my own reasons for storing media in rar's and I know some of the reasons why others choose to store their media in rar's so I can shed a light on that as well as I've tried to do earlier in this thread.
It is not like anyone will be forced into using rars for their media, it's all just a matter of giving people options.

I just don't think that's a good use of developer effort, even if we do get a few hundred dollars out of it. I hope you understand where I'm coming from there - there is a lot to do, not just due to the fork but to fix some long-standing issues with the original codebase as well, and this is a feature that wasn't present in Emby either.

I realize that this might not be a top priority but multiple users have expressed their interest in this feature in the past and it's safe to say there are many others that have looked at emby but looked away because the lack of rar support.
The workaround that exists with rar2fs works just as well with Plex so if Jellyfin/Emby ever got native rar support we could assume that some of those users would move away from Plex.
We could probably try reaching out to some of those users for a head count if you would feel that to be neccesary to see how big of a interest it really is.

These reasons all relate to having a very hacky setup for handling the media files themselves, that you'd like Jellyfin/Emby/whatever to work around for you. That's not to dismiss your request, just to point out that, for instance, an "extra step" of extracting RARs on the client side is trivial, while on the other hand adding support for "directly playing" RAR files is definitely not
I'm happy to leave this issue open and if a developer expresses interest in implementing this and can do so cleanly they're more than welcome to. But if you can provide more specific details on your setup maybe I can suggest a better workaround?

I understand your point of view but I disagree on it being a particularly hacky setup. I'll explain my personal case a little better.
I'm a purist at heart and many years ago my media library was not very organized, I made a few attempts to organizing it and storing it better myself but in the end I did some research on the subject. I looked over the internet to see how I should begin to standardize how I would store and organize my media with respect to screen resolution, bitrate, file format, file names, file paths and so on and so on.
Researching different forums and websites everyone seemed to have a different option on what would result in the best quality of files and the quality of a media library over all.
Eventually I came across standards that groups of media enthusiasts have been able to agree on, those standards are called the warez/scene rules/standards, (unfortunately their roots are tied to illegal activities but we can't argue that the people involved are really passionate about media).
You can gather some further information on the subject here: https://en.wikipedia.org/wiki/Standard_(warez) and here: https://scenerules.org
Funny enough we can trace some of how the media naming and setup in Emby is handled back to those rules, but I also think it's sad that Emby also has is own set of rules, while flexibility is good (I know that not everyone want's to organize the library according to scene standards) there are still some incompatibilties in Emby with the standards, most of them are minor but the rar support is the big missing piece.

Ever since then I have stored my media following those exact rules and so far it has gone pretty well, the media library has in most cases worked good with different software.
I do not want any software to touch my library by placing files in my library or touching my files in any way.
I do not want to re organize my media library around each and every media software that's hot at the time, there is more than one software using my media library right now and I can't have my library organized in many different ways at the same time.

maybe I can suggest a better workaround? For instance:

Not being able to extract, if the files are mounted from somewhere where you can not modify them.

What is the usecase here that the extraction couldn't be done on the server first? Or is this a case of trying to direct play off of a remote (Internet) server? Would download+extract not make more sense long-term?

There can me multiple reasons for preserving the media in the format that it is in right now.
Other software or perons might be using it in the format that it is right now, for some it might be other media libraries, for some it might be seeding a torrent, mounting a ftp, etc.
Today you can get cheap cloud storage and have the same speeds on your wan as you have on your lan, so I don't think in the long term storing locally will make any more sense long-term.

And in two cases you mention wanting to preserve the original RARs, but for most usecases that is simply a waste of space; why not extract them, play back the extracted file, then recompress it when you want to share it elsewhere or archive it?
It is true that it is a waste of space if you keep them both extracted and packed. If you extract it and then pack it again it will not have the same checksum and thus not be the same files. This would mean that software that looks at the checksum and timestamp will identify it as new files, this also means that for those that are sharing the files through some file sharing application they will not be able to share them as the originals.

I'm sorry how long this post has gotten but I hope this explains the situation a little better and that we can now move on.

from jellyfin.

I don't think the cost of doing this is (currently) worth it for the potential benefits.

As mentioned above, compressing video with RAR / other archive formats does very little to save space. It would be relatively easy to script the extraction of a downloaded archive before importing into Jellyfin, but that's outside the scope of the project. This is before thinking about the technical difficulties working with RAR archives.

Mounting RAR files from a read-only filesystem seems like a very niche edge-case to me.

At the very least I'd say this should be very low down on a list of priorities, if not entirely out of scope.

from jellyfin.

Still, the question "what is the usecase?" is very valid. We're not trying to say "you don't need it", we want to understand "WHY you need it" ;)

There are multiple reasons why this is needed, few common ones are:

• Extracting provides a extra step.
• Wanting to keep files untouched from the source, for sharing resons, or just to store things in their original format.
• Not being able to extract, if the files are mounted from somewhere where you can not modify them.
• Limited drive space, extracting requires extra drive space, both while you extract but also if you want to keep the media extracted/unextracted.
• No fuse mounting support for windows, nas boxes, etc.

Exactly - this just seems like a really weird feature to me, and kinda speaks to what I didn't like about Luke's development practice: prioritizing obscure features that people were willing to throw money at, over more general ones that would help everyone, with no explanation as to why aside from the $$$. I'm definitely not saying we can't or won't do this, especially if the "competition" does, I just want to understand why this should be built into the media player and not done by the administrator before importing the media, before it's prioritized.

I understand that point of view, but some of us with limited time/coding skills can only contribute with money. Wanting to pay for a feature can also show a commitment.

I'm really not a fan of this, both from licencing, code quality and consistency points-of-view. "Everyone is doing it" isn't a very good reason, and trying to read RARs means we need to include non-free software as a dependency - from Wikipedia:

No (decompression source code is available, but it's not free software due to the restriction that it must not be used to reverse engineer the RAR compression algorithm)

It's worth noting that RAR is a compression archive, and a non-free one that that, while e.g. AVI is explicitly a video container - there's no comparison there. And even ignoring the licensing issue I don't think the media player/library manager should be dealing with decompressing archives.

As far as I know the only limitation to the unrar license is that you can not use it to create a rar compressor, other than that I believe you can use it and distribute as you'd like.

There are already other things that are strangely licensed and not fully free included in this project, media formats for example: MPEG-2, Nero AAC, DivX, QuickTime, ASF, WMV, WMA
If rar support will be refused on the base that it's not fully freely licensed, wouldn't that mean we should drop all those other not fully free things as well?

The administrator should decompress/extract RAR files on their own before importing the resulting media files to their library.

Shouldn't DVD ISO be dropped as well then? Since the administrator should extract the MPEG-2 files from the ISO before importing the resulting media files into the library?

from jellyfin.

Hello friends!

Just found this project and I'm very surprised that you guys had so much ideas about this issue :) I had an idea and made a prototype, described here: https://emby.media/community/index.php?/topic/71200-rar-file-support-solution/

Sorry for linking to emby, this was my first approach.. I'm willing to use jellyfin now 💃
I just need some advice in the code regions I need to look at for scanning and playing media..

Thanks alot beforehand!

kind regards

from jellyfin.

If you're running Linux (which I assume from shell script) there should be options to just mount your archives (quick search yield an example of https://github.com/hasse69/rar2fs ) and play them as usual folders. I think it should be possible to have a plugin that mounts your media right before you play it, much like iso-s were supported (not sure if they're now).

This is not enough for us right now to include as official plugin as it won't work on non-Linux OSes, but you're welcome to make a 3rd party plugin!

from jellyfin.

From @bauruine on October 19, 2016 9:17

I've added 100$ to the bounty.
https://www.bountysource.com/issues/30765863-feature-request-support-for-media-in-rar-archives

from jellyfin.

From @bauruine on July 28, 2017 6:31

meh. looks like @denim2x is just a troll :-(

from jellyfin.

From @krysstof on August 17, 2017 5:33

as long as we are talking about "media in archives", comics readers use "cbz" and "cbr" files which are simply zip and rar files renamed
this would go well with this feature (and the pinch zoom one #2826 )

from jellyfin.

From @Ryu0 on July 15, 2018 15:2

Is this still wanted? I've been poking through the source to see how this might be done in an acceptable manner. I was thinking something like this could be integrated: https://github.com/bobvanderlinden/sharpfilesystem But then, I am unfamiliar with this project.

from jellyfin.

@Ryu0 sorry about the late reply, there's still a big interest in this.
As you can see on bountysource, we have a 260$ bounty for this feature at now but that could probably be raised if we had some goal posted from a developer.

The sharpfilesystem would definitely be a interesting approach, I did look at how Kodi and mpv are playing rar files as we might have a similar approach, here's the initial commit in mpv for example: mpv-player/mpv@3fc3bf7

Maybe @LukePulverenti could chime in the discussion as to point us to where in the Emby code we would need to look to do the integration properly, just to get things started.

from jellyfin.

Moved this issue from MediaBrowser/Emby#1440
I've also contacted BountySource to move the bounties over to jellyfin.

Hope this gets more attention here than it did over at Emby 😄

from jellyfin.

Are you looking into cross-platform way of doing things? I'm pretty sure Linux has FUSE-based tools that can mount archives as folders (though 10-second googlinng yielded nothing about mounting .rar-s).
Not saying "no" to FR, rather trying to enable your case faster :)

from jellyfin.

@JustAMan, already aware of fuse filesystems for rar, it's what I'm doing now and in fact I wrote a tutorial about it on the emby forums 3 years ago. https://emby.media/community/index.php?/topic/23648-tutorial-rar-playback-with-emby/

The fuse filesystem approach has it's downsides and that's the reason for this feature request.

from jellyfin.

They likely are. The trouble that I see is, most of these archive formats have their primary libraries in C. I don't know if there's any native solutions available for the .NET framework. So, would reliance on a cross-platform C library be an acceptable price to pay for VFS support?

from jellyfin.

@Ryu0 I fear that would needlessly complicate the build process, as well as bring up issues with communicating with the .NET code. Would something like this work?
github link

from jellyfin.

I agree that adding the rar support with C, python, etc would not be ideal.

It would be best if the rar format would be completely native, supported in the same way as any other media file.
I'm not sure how and where in the code emby Jellyfin handles files. Maybe someone here can shed a light on that?

If I remember correctly then Emby did have a strange approach to playing ISO files, I think they were/are shipping some binary blob from a third party (called pismo or something) that mounts the ISO files and it only works with 32 bit windows.
We should definitely NOT take that approach.

from jellyfin.

Maybe this is just me being opinionated, but bug bounties are not, what usecase does this actually solve? Why not just extract your RARs first?

from jellyfin.

Well that's a little bit like saying why support .avi when you can just convert your files to .mkv? 😄
What ever the use case may be is besides the point, this is a matter of having options.

Kodi supports this, so does mpv, etc. Plex once did as well, but they removed it.

from jellyfin.

Still, the question "what is the usecase?" is very valid. We're not trying to say "you don't need it", we want to understand "WHY you need it" ;)

from jellyfin.

Exactly - this just seems like a really weird feature to me, and kinda speaks to what I didn't like about Luke's development practice: prioritizing obscure features that people were willing to throw money at, over more general ones that would help everyone, with no explanation as to why aside from the $$$. I'm definitely not saying we can't or won't do this, especially if the "competition" does, I just want to understand why this should be built into the media player and not done by the administrator before importing the media, before it's prioritized.

from jellyfin.

Media files sometimes come in rar files because of reasons. And because they do and kodi and other software supports that some of us didn't bother to unpack it. I prefer to have them in their original state and having to unpack them first just seems like an unnecessary task.

from jellyfin.

Can I suggest a plugin or something that would unpack the media for you upon import? This could be integrated by utilizing, say, 7zip binary that end user somehow installs in their system (e.g. by package manager).

I mean, I don't think your ultimate goal is to show media from .rar files, your goal is to be able to view media that came in .rar files (that's a bit different, isn't it?).

from jellyfin.

A plugin that is not part of the core code is the best solution if this support is warranted.

I mean, I don't think your ultimate goal is to show media from .rar files, your goal is to be able to view media that came in .rar files (that's a bit different, isn't it?).

Exactly, this is very much an X-Y problem. You want to be able to play (presumably, Usenet-downloaded) content without dealing with extraction. A plugin that does so during library scan is a solution, but if you're already using a download manager to manage this content (which I presume you are), they all AFAIK have an "extract on completion" option that would satisfy that problem.

There are already other things that are strangely licensed and not fully free included in this project, media formats for example: MPEG-2, Nero AAC, DivX, QuickTime, ASF, WMV, WMA

ffmpeg handles these, not Jellyfin itself, so the licensing issues are outside of our scope. Honestly this sort of support should be a feature request for ffmpeg, rather than Jellyfin, so that you can just point ffmpeg at a .rar file and it handles extracting and decoding it on the fly. Building this into Jellyfin will be a lot of work with the aforementioned licensing implications.

from jellyfin.

Can I suggest a plugin or something that would unpack the media for you upon import? This could be integrated by utilizing, say, 7zip binary that end user somehow installs in their system (e.g. by package manager).
I mean, I don't think your ultimate goal is to show media from .rar files, your goal is to be able to view media that came in .rar files (that's a bit different, isn't it?).

There is/was already a plugin for extracting in Emby but that is not what we are asking for, the goal is exactly to play the media from the .rar files, for the reasons stated earlier:

• Extracting provides a extra step.
• Wanting to keep files untouched from the source, for sharing resons, or just to store things in their original format.
• Not being able to extract, if the files are mounted from somewhere where you can not modify them.
• Limited drive space, extracting requires extra drive space, both while you extract but also if you want to keep the media extracted/unextracted.

Would it be acceptable to add optional rar support in Jellyfin, where the user would have to provide a their own rar binary?
In that case Jellyfin would not be touching anything regarding licensing of rar.

from jellyfin.

Out of curiosity, what media type is usually stored in rar-s?

from jellyfin.

The biggest problem for me is

Wanting to keep files untouched from the source, for sharing resons, or just to store things in their original format.

The files are in that format and i'm not able to change that. This is a killer feature for me and i'm not using jellyfin at all because this feature is missing.

Out of curiosity, what media type is usually stored in rar-s?

What do you mean with media type?

from jellyfin.

I mean what is this media - videos (movies, series episodes, etc), music, audiobooks, something entirely different?

from jellyfin.

videos (movies, series episodes, etc)

from jellyfin.

I cannot understand the point of keeping videos in archives - they don't compress... But that is your decision to make, not mine.

This feature request now looks to me like a plugin request more, though...

from jellyfin.

The only reason people want this issue is that when torrenting media, most early releases are in rar format because reasons (or so I'm told). I'm not arguing that this is a good idea, but since people aren't giving the real reason for this I thought I'd chime in.

from jellyfin.

I don't think the cost of doing this is (currently) worth it for the potential benefits.

As mentioned above, compressing video with RAR / other archive formats does very little to save space. It would be relatively easy to script the extraction of a downloaded archive before importing into Jellyfin, but that's outside the scope of the project. This is before thinking about the technical difficulties working with RAR archives.

We are not talking about any compressed rars, the media is packed in the rars using the "store" compression level so it is not compressed at all.

One potential option would be if Jellyfin could recognize the rars as media and add it to the library.
Then when a client requests media that's inside a rar file the rar would be extracted temporarily on the fly and fed into ffmpeg which would handle it just like it does handle other media files right now.
(btw, ffplay can play rar files to some degree, audio works)

Mounting RAR files from a read-only filesystem seems like a very niche edge-case to me.

At the very least I'd say this should be very low down on a list of priorities, if not entirely out of scope.

My setup is definitely a niche edge-case but there are a lot of users that have some media in rar files, I was simply trying to explain different reasons.

from jellyfin.

Just trying to get a better understanding - would "transcode" in terms of unpacking to transcode-temp directory work? Jellyfin could wipe temp files it extracted after you stopped playing them. This would enable real transcode to happen as well, as I very much doubt that e.g. ffmpeg can take media from rar-s as input.

from jellyfin.

Just trying to get a better understanding - would "transcode" in terms of unpacking to transcode-temp directory work? Jellyfin could wipe temp files it extracted after you stopped playing them. This would enable real transcode to happen as well, as I very much doubt that e.g. ffmpeg can take media from rar-s as input.

Yes that would definitely work!
Even better would be if it would just unrar to stdout and then pipe stdin to ffmpeg, I think the rar support in mpv is something similar.

Another way would be to use some library that can mount the rar file temporarily and feed that to ffmpeg rather than extracting it temporarily.

from jellyfin.

Piping to ffmpeg is only one problem, another is when you, for example, "direct play" a file in your browser (that is, serve media file as-is via http) and want to seek in that file. It's pretty much impossible to seek in unrar throwing stuff to a pipe...

from jellyfin.

Ah, so ffmpeg does not touch the files at all when they are served with "direct play"? I always assumed everything went through ffmpeg...
If the files are served directly, I guess that means extracting temporarily or more ideally mounting the file temporarily would be a better solution.

btw. If I remember correctly Emby does/did at some point support subtitles that are packed in rars, I'm not sure how that was done but probably they are just extracted temporarily.

from jellyfin.

Subtitles are usually text which could be extracted anywhere as it's size is typically negligible compared to the video file...

Yes, in "direct play" mode the file is served as-is without ffmpeg being launched (and that's the best mode IMO as it generates the lowest load on the server - allows you to host Jellyfin on a 5-year-old Atom netbook or Raspberry Pi and it should work just fine).

Mounting archives is a tricky part - I'm sure Linux has something to say about that, but doing it in a cross-platform way would be a nightmare, that's why all this fuss :)

from jellyfin.

I just had a look at the Kodi implementation and it seems that they have moved it to a addon.

Perhaps it is something that could be used to base a Emby addon on?
I have not read through the sources but it looks like what it does provide is a cross platform file mount or a "virtual filesystem" for rars.
Am I understanding it correctly @JustAMan ?

Edit: whoops, forgot the link: https://github.com/xbmc/vfs.rar

from jellyfin.

Seems like so. The problem there is that it's C++, which means we'll have to build it for each target platform separately, where .net allows you to "build once run everywhere" approach.

I still stand on my point of making this an addon - build a small addon for several OSes is easier than building the whole project (though I suppose we'll soon come to the point where we will be doing those builds... but I think that most of these could be done by cross-compiling from some Linux, and that could be hard to achieve with native - read C/C++ - code).

Also the repo you linked does not contain any license, so I doubt we'd be able to integrate it right now - we're trying to be extremely pure on licensing. I'll raise an issue about license in that repo.

Edit: license seems to be permissive enough for addon - GPLv2 + unRAR license (see here for more details: xbmc/vfs.rar#35)

from jellyfin.

I was thinking a little bit about this, and assuming you may have multiple media files in the rar archive, I would think that the rar would need to be extracted to a temporary folder before ffmpeg could handle it. This could be done upon import or with some kind of cache algorithm (Delete inactive files, extract on request), but the temporary/cache folder where the rars would be extracted to need to have a ton of space available.
To make it work across platforms, either a native decompressor would need to be used (GPL compatability issues? Performance issues?) or to just call unrar like it calls ffmpeg, and rely on unrar to be available on every platform.

I would like to see this as a plugin if anything...

My personal opinion here is neutral..

from jellyfin.

thanks for the info, I understand and you are right, I'm using Linux and other wont have a profit from it. Problem is now, I dont know where to start when building this 3rd-party-plugin.. Which part of the code is responsible for scanning and playing? please help me

from jellyfin.

@platinum55 please use one of non-Github-issue channels, as they're way more suited for discussion of development things.

from jellyfin.

I realize I was thinking mostly about playback when I made my previous comment. If that idea was implemented you'd have all your rars extracted upon scan. I think some kind of fuse overlay driver could work better, that could present the rar file as a directory and would enable random read access into the rar archive. This would unfortunately not work with windows

from jellyfin.

@platinum55, appreciate the effort, I am not sure where the plugin would hook into and if that's even possible at the current stage, perhaps @JustAMan or someone else can give a better insight.

That being said, have you looked at the kodi plugin? Afaik it is cross platform. https://github.com/xbmc/vfs.rar

from jellyfin.

Streaming from an unrar source would need to support seeking too, since ffmpeg will need input seeking sometimes (for some formats), so really the C library should be integrated into ffmpeg (or own build). That is the only correct way to do it with all seeking and stuff. But I am sure you will never get that upstream.

from jellyfin.

The more I think about this, the more obvious it becomes that the only reasonable solution here is to use fuse. Either via jellyfin mounting each rar on demand, or by some overlay. Windows based users with this need would have to run a vm.. The first option would avoid all data going through a layer of fuse.

Implementing rar support in ffmpeg and having the server also inspect rars sounds like too much work to be feasible.

Unrar on demand to a temp folder could also be an option but that introduces a very large amount of copying that would need to get done, with some risk one could start playback before it was completely unarchived. Maybe eagerly unpacking all rars would be the option, but the user would need to set aside the total disk space as their rar files use for jellyfin unpacking. All the rar files would be unpacked during a scan.. The unrar binary would need to be packaged with jellyfin appropriate to the architecture and os, or jellyfin could use a library, at the risk of being inefficient

from jellyfin.

you are right, I tried rar2fs with "--seek-length=1" and its working like a charme.. thanks! I think we can close this issue. Because with rar2fs even seeking forward works!

from jellyfin.

@platinum55 No this issue can not be closed, I am fully aware of rar2fs and even wrote a tutorial on it myself few years ago on the emby forums.

The rar2fs solution is just a workaround and is not as good a solution as if rars were supported natively or through a plugin.

Fuse is not the only solution for seeking, both mpv and Kodi have full seeking support without extracting rars.

from jellyfin.

We're keeping this issue open as a call for someone to implement it, should they desire, in a 3rd party plug-in/add on for Jellyfin.

Gardar has transferred a bounty that they originally created at the Emby project and transferred here: https://www.bountysource.com/issues/67390707-support-for-media-in-rar-archives

As of right now, we don't have any intention to officially support it in the server's core code. or in our project repositories. This is for a variety of reasons, the largest being the RAR format's proprietary licensing.

from jellyfin.

An important difference between mpv and jellyfin is that jellyfin does not link with ffmpeg and instead relies on the ffmpeg command line interface, which to my knowledge does not support it. I don't know about kodi but expect to see about the same there... With this and a windows platform constraint I really don't see other solutions than the server actually unpacking it somewhere

from jellyfin.

There is also libarchive which is under a New BSD License and also supports rar. Kodi has also a plugin with it https://github.com/xbmc/vfs.libarchive/.

from jellyfin.

Doesn't link with jellyfin unfortunately.. Dotnet is like Java and ideally it should be written in dotnet and use dotnet depemdencies.. I'm sure a wrapper could be made but no idea how it would work on different architectures and platforms.. Plus the binary ffmpeg would need changes too.. Unless one instead was to link directly with the ffmpeg libraries

from jellyfin.

Google tells me it's called P/Invoke, maybe that can be used? But no idea how to pass that on to ffmpeg other than switching to the ffmpeg libraries too..

from jellyfin.

PInvoke means we'll need native builds for each supported platform, which increases complexity a lot. Switching to ffmpeg as a library is a prerequisite for going without FUSE for Windows, but that is hard.

All these are the reasons for

As of right now, we don't have any intention to officially support it in the server's core code. or in our project repositories.

from jellyfin.

It would mean the same thing as we currently need for sqlite and skia. Doable but then we might as well start linking with ffmpeg for example. Mayor complexity in the build system and generally very fragile.

from jellyfin.

I think the general consensus of contributors is that this will not happen and that we will not accept code into the server that does this. Folks can correct me if they want, but for now I'm closing this.

from jellyfin.

Just came across this. Pretty sure people have used my sharpcompress project to stream data out of rar and multi-part rar archives before. All native C# without decompression to a file beforehand. CPU might have been an issue compared to native as the C# is unoptimized.

from jellyfin.

Just came across this. Pretty sure people have used my sharpcompress project to stream data out of rar and multi-part rar archives before. All native C# without decompression to a file beforehand. CPU might have been an issue compared to native as the C# is unoptimized.

Do you have any time/interest in giving it a shot as a plugin for jellyfin? Even just a proof-of-concept from someone knowledgeable such as you would be greatly appreciated to get things going.

from jellyfin.

Not sure I have time to learn and make a plugin from scratch. I can provide reviews and code samples though.

I'd think Jellyfin would have file(s) or stream(s) given to the plugin and need a decompressed stream from a file in the archive out from the plugin.

Converting a list of RARs as file names or streams, would look similar to:

        public void Rar5_Multi_Reader() {
            DoRar_Multi_Reader(new string[] { 
                "Rar5.multi.part01.rar",
                "Rar5.multi.part02.rar",
                "Rar5.multi.part03.rar",
                "Rar5.multi.part04.rar",
                "Rar5.multi.part05.rar",
                "Rar5.multi.part06.rar"});
        }

        private void DoRar_Multi_Reader(string[] archives)
        {
            using (var reader = RarReader.Open(archives.Select(s => Path.Combine(TEST_ARCHIVES_PATH, s))
                .Select(p => File.OpenRead(p))))
            {
                while (reader.MoveToNextEntry())
                {
                    using (var entryStream = reader.OpenEntryStream())
                        {
                            string file = Path.GetFileName(reader.Entry.Key);
                            string folder = Path.GetDirectoryName(reader.Entry.Key);
                            string destdir = Path.Combine(SCRATCH_FILES_PATH, folder);
                            if (!Directory.Exists(destdir))
                            {
                                Directory.CreateDirectory(destdir);
                            }
                            string destinationFileName = Path.Combine(destdir, file);

                            using (FileStream fs = File.OpenWrite(destinationFileName))
                            {
                                entryStream.TransferTo(fs);
                            }
                        }
                }
            }
            VerifyFiles();
        }

More tests for examples can be found here: https://github.com/adamhathcock/sharpcompress/blob/master/tests/SharpCompress.Test/Rar/RarReaderTests.cs

from jellyfin.

Just wondering how come this isn't a thing. I've just set jellyfin up. I started with an emby setup before learning about jellyfin.
It took me quite a while to figure out what the issue was.
Many years ago i used xbmc which worked just fine with packed content, so i just assumed it would work.

from jellyfin.

Any updates here?

from jellyfin.

Never going to happen

from jellyfin.