mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Support for media in rar archives #48
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gardar on GitHub (Dec 12, 2018).
From @gardar on February 11, 2016 16:52
I would like to see Emby support media that's inside rar files natively.
Preferably in a similar way that Kodi does currently.
This means that the media is not extracted from the rar but rather accessed directly from within the rar files.
Few requirements:
Further details on the requirements of this feature request:
http://emby.media/community/index.php?/topic/10765-support-for-media-in-rar-archives/
http://emby.media/community/index.php?/topic/23648-tutorial-rar-playback-with-emby/
Copied from original issue: MediaBrowser/Emby#1440
@gardar commented on GitHub (Dec 12, 2018):
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
@gardar commented on GitHub (Dec 12, 2018):
From @bauruine on July 28, 2017 6:31
meh. looks like @denim2x is just a troll :-(
@gardar commented on GitHub (Dec 12, 2018):
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 )
@gardar commented on GitHub (Dec 12, 2018):
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.
@gardar commented on GitHub (Dec 12, 2018):
@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:
3fc3bf70f9Maybe @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.
@gardar commented on GitHub (Dec 12, 2018):
Moved this issue from https://github.com/MediaBrowser/Emby/issues/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 😄
@JustAMan commented on GitHub (Dec 12, 2018):
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 :)
@gardar commented on GitHub (Dec 12, 2018):
@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.
@ghost commented on GitHub (Dec 12, 2018):
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?
@RazeLighter777 commented on GitHub (Dec 12, 2018):
@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
@gardar commented on GitHub (Dec 12, 2018):
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
embyJellyfin 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.
@joshuaboniface commented on GitHub (Dec 12, 2018):
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?
@gardar commented on GitHub (Dec 12, 2018):
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.
@JustAMan commented on GitHub (Dec 12, 2018):
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" ;)
@joshuaboniface commented on GitHub (Dec 12, 2018):
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.
@bauruine commented on GitHub (Dec 12, 2018):
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.
@joshuaboniface commented on GitHub (Dec 12, 2018):
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:
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.
@RazeLighter777 commented on GitHub (Dec 12, 2018):
I vote no rar support. It’s not a high priority, rar is proprietary and not well supported on many platforms.
@gardar commented on GitHub (Dec 12, 2018):
There are multiple reasons why this is needed, few common ones are:
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.
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?
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?
@JustAMan commented on GitHub (Dec 12, 2018):
Can I suggest a plugin or something that would unpack the media for you upon import? This could be integrated by utilizing, say,
7zipbinary 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
.rarfiles, your goal is to be able to view media that came in.rarfiles (that's a bit different, isn't it?).@joshuaboniface commented on GitHub (Dec 12, 2018):
A plugin that is not part of the core code is the best solution if this support is warranted.
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.
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
.rarfile 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.@gardar commented on GitHub (Dec 12, 2018):
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:
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.
@joshuaboniface commented on GitHub (Dec 12, 2018):
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:
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!
@JustAMan commented on GitHub (Dec 12, 2018):
Out of curiosity, what media type is usually stored in rar-s?
@bauruine commented on GitHub (Dec 13, 2018):
The biggest problem for me is
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.
What do you mean with media type?
@JustAMan commented on GitHub (Dec 13, 2018):
I mean what is this media - videos (movies, series episodes, etc), music, audiobooks, something entirely different?
@bauruine commented on GitHub (Dec 13, 2018):
videos (movies, series episodes, etc)
@JustAMan commented on GitHub (Dec 13, 2018):
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...
@CountMurphy commented on GitHub (Dec 13, 2018):
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.
@BnMcG commented on GitHub (Dec 14, 2018):
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.
@gardar commented on GitHub (Dec 14, 2018):
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 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.
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.
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.
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.
@gardar commented on GitHub (Dec 14, 2018):
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)
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.
@JustAMan commented on GitHub (Dec 14, 2018):
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.
ffmpegcan take media from rar-s as input.@gardar commented on GitHub (Dec 14, 2018):
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.
@JustAMan commented on GitHub (Dec 14, 2018):
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...
@gardar commented on GitHub (Dec 14, 2018):
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.
@JustAMan commented on GitHub (Dec 14, 2018):
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
ffmpegbeing 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 :)
@gardar commented on GitHub (Dec 14, 2018):
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
@JustAMan commented on GitHub (Dec 14, 2018):
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: https://github.com/xbmc/vfs.rar/issues/35)
@hawken93 commented on GitHub (Dec 31, 2018):
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..
@platinum55 commented on GitHub (Mar 12, 2019):
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
@JustAMan commented on GitHub (Mar 12, 2019):
If you're running Linux (which I assume from shell script) there should be options to just
mountyour 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!
@platinum55 commented on GitHub (Mar 12, 2019):
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
@JustAMan commented on GitHub (Mar 12, 2019):
@platinum55 please use one of non-Github-issue channels, as they're way more suited for discussion of development things.
@hawken93 commented on GitHub (Mar 12, 2019):
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
@gardar commented on GitHub (Mar 13, 2019):
@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
@EraYaN commented on GitHub (Mar 13, 2019):
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.
@hawken93 commented on GitHub (Mar 13, 2019):
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
@platinum55 commented on GitHub (Mar 14, 2019):
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!
@gardar commented on GitHub (Mar 14, 2019):
@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.
@anthonylavado commented on GitHub (Mar 14, 2019):
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.
@hawken93 commented on GitHub (Mar 14, 2019):
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
@bauruine commented on GitHub (Mar 14, 2019):
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/.
@hawken93 commented on GitHub (Mar 14, 2019):
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
@hawken93 commented on GitHub (Mar 14, 2019):
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..
@JustAMan commented on GitHub (Mar 15, 2019):
PInvoke means we'll need native builds for each supported platform, which increases complexity a lot. Switching to
ffmpegas a library is a prerequisite for going without FUSE for Windows, but that is hard.All these are the reasons for
@EraYaN commented on GitHub (Mar 15, 2019):
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.
@sparky8251 commented on GitHub (Jul 18, 2019):
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.
@adamhathcock commented on GitHub (Sep 12, 2020):
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.
@gardar commented on GitHub (Sep 17, 2020):
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.
@adamhathcock commented on GitHub (Sep 17, 2020):
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:
More tests for examples can be found here: https://github.com/adamhathcock/sharpcompress/blob/master/tests/SharpCompress.Test/Rar/RarReaderTests.cs
@fusk-l commented on GitHub (Mar 5, 2021):
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.
@Ondjultomte commented on GitHub (Oct 31, 2022):
Any updates here?
@cvium commented on GitHub (Oct 31, 2022):
Never going to happen
@scotjam commented on GitHub (Jan 16, 2026):
@gardar @Ondjultomte (and others who are interested) https://github.com/scotjam/Jellyfin.Plugin.RarArchiveReader - have built something quickly over the last 24 hours that works for my purposes, i.e. plugin that mounts rars using rar2fs when running jellyfin as a docker container on openmediavault. In each folder that has rar'd media it creates an UNRAR folder that jellyfin can look in when you refresh library. Let me know if anyone decides to try it and whether they get it working.
EDIT: It's working on windows now as well - works slightly differently, creating a strm file which then can be recognized and played by Jellyfin.