Jump to content

Support for media in rar-archives


korvgryta

Recommended Posts

Deathsquirrel

Hello,

 

I would not say it has 0 value for people with legitimate media. In my own case, for instance, I would have appreciated to store all my files in a single archive. For instance, the MKV file + JPG files + SRT files. It has nothing to see with legitimate media or not at the moment you decide to put all of them onto your local network :)

 

Eric

 

If that's true I think you'd find yourself in a vanishingly small group that doesn't merit the time to build this feature.

 

If  you only want to see the video file, set the metadata and images to be hidden or don't cache them with the media.

Link to comment
Share on other sites

edejaeger77

WoW ! If I am vanish then I am in the good place to get some also-so-so-vanished answer.

I am happy that you, who do mot make any effort to understand why it could be nice to have a feature to do something more practical for the end user because he has his own reasons, are here to give unpleasant and aggressive answers.

 

I do not salute you.

Link to comment
Share on other sites

denz

I am surprised people still use RAR for anything let alone video files. 

Link to comment
Share on other sites

olehj

I want to add that I can legally download a copy from a movie I own on a physical medium from a torrent side, regardless of which. Even piracy trackers are ok to use for a backup of a movie I own. Often these movies are packed in rar, and I'd like to keep them that way so I can help other getting their backups as well. I can also choose to RIP my own DVD's and BluRay and pack them in rar files to share.

 

Because something is illegal in some countries, doesn't mean that it is like this everywhere. Packing movies in a rar file isn't piracy on any level either, it's just a choice.

 

I have mainly worked around this problem with rarfs, but it is not optimal as you have to implement in manually. But it does work very well when it is configured. I would still have it native built-in.

 

I don't see the point why someone would be -against- this, it is just a nice feature you can ignore if you don't like/use it.

 

And it would get another thing which Plex hasn't!

  • Like 1
Link to comment
Share on other sites

Deathsquirrel

I want to add that I can legally download a copy from a movie I own on a physical medium from a torrent side, regardless of which. Even piracy trackers are ok to use for a backup of a movie I own. Often these movies are packed in rar, and I'd like to keep them that way so I can help other getting their backups as well. I can also choose to RIP my own DVD's and BluRay and pack them in rar files to share.

 

No, you almost certainly can't.  Sure, downloading an exact copy of a disc you own MAY be legal in some countries, though not many, but uploading happens at the same time and that isn't legal pretty much anywhere that has copyright laws at all.  Your ownership of a disk doesn't convey distribution rights.

 

That's irrelevant to this feature request, but I'd hate to think someone read this and actually thought they couldn't get in trouble for uploading movie rips to other users through torrents simply because they own a disc copy.

Link to comment
Share on other sites

Deathsquirrel

...to do something more practical for the end user...

 

Yesterday I got a Fairy Tail set for my youngest.  That's 4 discs I need to run through the following steps:

 

  1. Rip the discs.  I use MakeMKV for this so it's pretty easy but I do need to manually edit what tracks are grabbed due to the structure and contents of these discs.
  2. Click though each extracted file to determine what it is and if I want to keep it.
  3. Rename the files to match TVDB since this is TV content.
  4. Organize the files into appropriate season folders.
  5. Upload the new episodes to the appropriate folder on my NAS so it will end up in the correct library.
  6. Scan my library for new content.
  7. Update the posters for any new shows or seasons as needed since the defaults may not match my existing shows/seasons.
  8. Backup the results so I don't have to repeat steps 1-7 again in the future.

You're proposing there is some undefined 'practical' reason why I'd add the extra steps of RARing each episode and its metadata up, deleting the original files, and rescanning the library.  The resulting files will take up more space than the originals did.  Bluntly, that's nonsense.  That's why in this entire thread the only reason for this feature is ease of torrenting.

 

RARing your own content would reduce compatibility in general while offering you zero benefits that I can recall anyone pointing out.

  • Like 1
Link to comment
Share on other sites

noybman

Anywhoo, back to the feature request. I bought Emby. I like Emby. This is a feature I want, for numerous reasons, but I have a twist on the feature request. Can (or has) Emby released a Web-based-like API that allows a plugin to hand a file or stream of file handles to Emby to be processed for library/playback? Where I am going with this, is that if Emby were to reelase this as an API for example, addon developers could write a wrapper from some other file system, (including cifs, ext4, zip, rar, lha, iso, or whatever 'insert file system of the future here') And as long as a developer or community was to develop an addon, Emby could handle it without needing to be modified at all.

 

True OOP with stubs! :D

Edited by noybman
Link to comment
Share on other sites

noybman

......

 

You're proposing there is some undefined 'practical' reason why I'd add the extra steps of RARing each episode and its metadata up, deleting the original files, and rescanning the library.  The resulting files will take up more space than the originals did.  Bluntly, that's nonsense.  That's why in this entire thread the only reason for this feature is ease of torrenting.

 

RARing your own content would reduce compatibility in general while offering you zero benefits that I can recall anyone pointing out.

 

No, I think he is saying he doesnt feel like doing steps 1-7 at all when he can obtain it via other means (torrent, newsnet, ftp, copy from someone else, unload it off of 1.44MB floppies?)... whatever. It doesn't really matter what the motivation is (or isn't) and all conjecture from you, I, or anyone does not belong because judgement is being passed; maybe unfairly.

 

Either the Emby team wants to support it or does not. It would seem the "feature request noted" could have been the nail in the coffin on this thread and thread be closed like OP asked, or voting buttons be added, or leave it open and have people arguing morales and intent. If Emby has no intent to ever include it, which seems to be the case, it could be added as a sticky in big bold letters.

  • Like 1
Link to comment
Share on other sites

No, I think he is saying he doesnt feel like doing steps 1-7 at all when he can obtain it via other means (torrent, newsnet, ftp, copy from someone else, unload it off of 1.44MB floppies?)... whatever. It doesn't really matter what the motivation is (or isn't) and all conjecture from you, I, or anyone does not belong because judgement is being passed; maybe unfairly.

 

Either the Emby team wants to support it or does not. It would seem the "feature request noted" could have been the nail in the coffin on this thread and thread be closed like OP asked, or voting buttons be added, or leave it open and have people arguing morales and intent. If Emby has no intent to ever include it, which seems to be the case, it could be added as a sticky in big bold letters.

 

Don't get this misconstrued. Piracy has no meaning to RAR. 100% do not care if it can be used with piracy. A car can be used to kill. Do we ban the use of cars? no. We educate users about the potential that the car can be used. To kill. Piracy doesn't kill. But it is bad. RAR isn't bad. RAR is just a container used to contain things that may be inside it. Whether that container uses no compression and the RAR is just used to span and contain or whether it is used with compression is meaningless. So to argue about semantics of use is pointless. We will be here all day. In fact all year. In fact our entire lives. The debate will have life beyond our lifetimes and never end. So we can let that just go. It isn't anything we care about. yawn.

 

The reason Emby doesn't support it is cost. Maintenance. Ease of use for users. Simply put it is about value to the consumer. You may find value that Emby adds RAR today. What the hell it may take about a month or so to work out all the bugs. Maybe a full week of digging to get it fully implemented. But it is worth it. Now you factor in the audience with media in RAR containers. Now the argument falls apart. The time and effort required to make this have the value you desire is monumental. It isn't free. Time isn't free. Money doesn't grow on trees. As users spend money on Emby it is then spent on where users will get the most value. The most bang for your buck. RAR is not bang for your buck.

 

Now if people were to contribute to a fund called "Get Emby RARFS support" and put that on patreon or whatever. After it gets where you think it is substantial enough to cover the time spent to get RARFS added pass that to Emby. Emby can then use it to fulfill your request. But it can't be at the expense of everyone else who doesn't want the feature. You can't take their payments to Emby and do something like this. You have to put value in the software where users find value. 

 

If I am wrong in any of this please point me in the right direction where I made a mistake but this is how it really is. There is only so much you can do with the resources you have available. You have to set a road map of the future. You have to keep yourself focused on not introducing major changes that may influence maintenance costs and time related to maintenance. This is where you have to juggle what users want and why feature request threads and liking the first post of these is important. Otherwise it is hard to judge reality of what users want.

 

In this case, this thread has 3 likes on the first post. It isn't moving the needle. There isn't a mass rush to agree. If there were it would be more than 3. This is the brutal truth. Sorry but the truth cannot lie. It cannot be friendly. It is just bare and doesn't allow debate. I apologize this is the reality.

 

Why does this thread have to be closed? It has a valid purpose and its existence is to gain traction for a feature request. It isn't political. We aren't deciding which power hungry nations we align with. This is just a small feature request that needs more users to "like" the first post of this thread. Without doing that all the +1 and "Yeah me too" mean nothing. You really think people go through those threads counting the people saying yes or no inside the thread? No one is doing that. It is expected you like the first post. Some forget. Some don't care and keep doing the +1 and "me too" inside the threads. They obviously aren't being counted. They either don't know they should like the first post. Don't care and just do it to add noise to the thread. Or they just can't read and are blind in which case the person typing onto the forum for them isn't doing them any favors. We can keep the thread open and see where this eventually goes. Maybe tomorrow 200 bots like the first post. Then wow.. 

Edited by speechles
Link to comment
Share on other sites

noybman

@speechless, did you read mypost #133? Your reply to my post #134 completely ignored #133 and what I proposed in #133 answers the bill on your rant akin to "The Emby team will do what features it wants with the paying members money because remiss of any indisputable measureable or statisitcal proof of what they want, we know what they want, and what the majority needs."  --- Now, sincerely, I don't disagree with your stance (at least in part). The Emby team has made a solid pleasing web based engine with media playback and solid support for the client server model. Thus why I paid lifetime flat out. I like it quite a lot. So I supported it. The team is making good design decisisons!!!

 

All feature requests are akin to cost (whether it is time, money, or something more, e.g., licensing, server fees, etc.). The moment a feature or capability exists in Emby that wasn't there before, WHAM - opportunity for maintenance. If the OS, or ffmpeg transcoding, or HTML5 changes, Emby may have to do updates. So, if this feature were to be considered, do not make it a core part of Emby. Then, someone else can develop it. If EXT9 comes out, a developer could create addon support for it. I didn't vote on the first post, no rule, ettiquite, or note is or was clear to me that I was supposed to. Sure, I'll go vote it up.

 

The people who want an RARFS feature are using Kodi. They are using Kodi, blissfully unaware (or uninterested) in Emby. If it was stickied that Emby does not plan to do this, (as people could be looking to leave Kodi, would likely "google search: emby and rar support") would see the sticky and know the answer. Instead of reading 7+ pages of banter on the topic and people arguing about why they want to do it and why it is valid or ok. But I guess they will still know the answer (if they look). If it said "vote here for this feature" they would probably vote and move on just contuinuing to use Kodi. If someday Emby supported it, they would probably give it a second look.

 

In the meantime, since people pay for Emby premium, and these monies fund further development, there should not be a bounty for RARFS support. If this bounty were to be created, the Emby team should not be able to cash in on it. It creates a conflict of interest. It sets a bad precedent where Emby dev's could pick and choose to only do features they were paid extra to do, which gets gooey when users wouldconsider, "of all of these new features the Emby team worked on, was the time & money spent correctly, or where (they) wanted it, in the eyes of the end users? It just gets yucky. (BTW< I'm not suggesting the team does or will do this, just that this precedent would allow it).

Link to comment
Share on other sites

@speechless, did you read mypost #133? Your reply to my post #134 completely ignored #133 and what I proposed in #133 answers the bill on your rant akin to "The Emby team will do what features it wants with the paying members money because remiss of any indisputable measureable or statisitcal proof of what they want, we know what they want, and what the majority needs."  --- Now, sincerely, I don't disagree with your stance (at least in part). The Emby team has made a solid pleasing web based engine with media playback and solid support for the client server model. Thus why I paid lifetime flat out. I like it quite a lot. So I supported it. The team is making good design decisisons!!!

 

All feature requests are akin to cost (whether it is time, money, or something more, e.g., licensing, server fees, etc.). The moment a feature or capability exists in Emby that wasn't there before, WHAM - opportunity for maintenance. If the OS, or ffmpeg transcoding, or HTML5 changes, Emby may have to do updates. So, if this feature were to be considered, do not make it a core part of Emby. Then, someone else can develop it. If EXT9 comes out, a developer could create addon support for it. I didn't vote on the first post, no rule, ettiquite, or note is or was clear to me that I was supposed to. Sure, I'll go vote it up.

 

The people who want an RARFS feature are using Kodi. They are using Kodi, blissfully unaware (or uninterested) in Emby. If it was stickied that Emby does not plan to do this, (as people could be looking to leave Kodi, would likely "google search: emby and rar support") would see the sticky and know the answer. Instead of reading 7+ pages of banter on the topic and people arguing about why they want to do it and why it is valid or ok. But I guess they will still know the answer (if they look). If it said "vote here for this feature" they would probably vote and move on just contuinuing to use Kodi. If someday Emby supported it, they would probably give it a second look.

 

In the meantime, since people pay for Emby premium, and these monies fund further development, there should not be a bounty for RARFS support. If this bounty were to be created, the Emby team should not be able to cash in on it. It creates a conflict of interest. It sets a bad precedent where Emby dev's could pick and choose to only do features they were paid extra to do, which gets gooey when users wouldconsider, "of all of these new features the Emby team worked on, was the time & money spent correctly, or where (they) wanted it, in the eyes of the end users? It just gets yucky. (BTW< I'm not suggesting the team does or will do this, just that this precedent would allow it).

 

 

Maintenance would be the #1 issue the apps would all have to be updated to work with RARFS. Most of them will never work with it. Notably Roku. So right off you cripple the movement since now it reduces the playfield of devcies. Once you restrict that playfield closer to just a PC. Well. Why does Emby need to support it again? See.. It makes it hard because to get this moving takes maintenance in every single app that could support this because there will be issues with these files. Undoubtedlly there will be growing pains. There will be adjustments. There will be others going why did you even add this crap! Yet others praise it is there. So you get sort of in this mud. You have to walk through it and just wear mud on you for awhile. It will be messy. Then once you get through that initial stage it might be brighter ahead.

 

As far as bounties, it would require having some sort of person in charge of implement that feature. That person doesn't need to be part of Emby team. Just needs to have available time they can commit to it and the expertise/knowledge to get there. I say that person because that is what it would be. One person would add it while the others all do what they normally do. That is how the bounty could work. It would require them having inside knowledge of things so might require some sort of non disclosure or similar. Who knows. This is all conjecture. I am just trying to understand how it would be possible with time constraints and road maps how presently it could happen.

 

It indeed would take more dialog to get there. It may be possible in the future. I am simply stating today. Tomorrow changes everything. Maybe tomorrow. Nobody said no. No one said never. They just never said when.

 

I agree someone could "pin" this topic with a star so it floats at the top so others don't miss it. Perhaps it might gain traction and get likes if it had more exposure. It gets buried pretty quickly.

Edited by speechles
Link to comment
Share on other sites

noybman

@@speechles, Other than to answer the assertion @@Deathsquirrel made (to be fair, I'm not so sure people enjoy the seven easy steps he outlined, he kinda made the case for why letting someone else do the extraction work is so interesting, lol - but again, not that it matters), I was confused you chose to reply to that particular post of mine instead of the previous one. This thread is inunndated with people arguing intent, morales, or my way is better than yours. I want to see if we can find a solution.

 

My actual post in favor of this feature request was to ask that if Emby doesn't already, that if they support an ability to hand arrays/lists of file handles via their own API over say a web port, specifically designed to treat the content like a file/series of files, that some other tool adhering to a "special Emby API" could be written to support zip, rar, iso, ext9, swapping of floppies, samba7, apple-air-play-6G, (I'm making up future I/O interfaces) and hand Emby the extensible info it needs to do what it does best.

 

This would mean the core of Emby doesnt have to change, and the bonus is that other programmers could develop handlers for whatever whacky file system or file type they have, as long as they can hand Emby the Name info needed to generate the library entries, and pass the expect files 10101010101000010010101 data in the format that was handshaked on, (eg, avi, mkv, mp4 whatever).

 

I guess as long as this special service was ran on another machine and the file handle was handed to Emby like the expected 10100101011, then Roku would never know the difference? I dont have Roku yet, still a dinosaur running Win 8.1 HTPC with my cable card.

Edited by noybman
Link to comment
Share on other sites

I think this discussion has played out for the time being.  There are a lot of complexities to doing this that make it not a slam dunk and on  top of that the reality is that RARed media has an immediate association with torrenting.  Whether that is 100% the case or not is irrelevant.  To people like the app stores, that is exactly what they will think.  And, they control everything.  They don't have to prove anything illegal. They don't have to prove anything at all.  They get to decide who they do and do not allow on their platform for any reason they want.  So, that simple association is a very dangerous one for us.

 

Thanks.

  • Like 2
Link to comment
Share on other sites

  • 9 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...