+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: Xbmc to unpack a big file. Why? (/showthread.php?tid=118220)
RE: Xbmc to unpack a big file. Why? - SiliconKid - 2012-10-12
spiff is right though, that is the entire point of the dialog.
Just saying.
I found this thread extremely interesting because I really didn't even know you could play movies from inside a RAR archive. It never even occurred to me to ever try doing that in 20+ years of being a developer.
Far as I knew, RAR was for compression and / or file splitting to get stuff from one place to another, often over the internet, or back in the good ol days via stiffy disks.
But once you've got it on the other side you ALWAYS extract the contents and put it all back together and check the integrity at the same time.
Leaving it in the RAR containers just seems really strange to me. It's like you just never finished the job properly.
It's kind of like buying groceries, bringing them home in packets, but then just shoving the packets straight in the fridge without unpacking anything. Then later, you go to eat something, you open the packet, and you discover stuff is missing from the packet! Or, you realise you need a bunch of stuff from the packets and you have to unpack them anyway before you can cook dinner, which sucks, because you're really tired after writing software all day and you really don't feel like unpacking at that point and you realise you really should have just unpacked everything when it arrived at the house in the first place.
RE: Xbmc to unpack a big file. Why? - hasse69 - 2012-10-12
(2012-10-12, 12:51)flyingrat Wrote: I do concur it's rather stupid to compress already compressed data streams. But it still happens quite often thus it would be nice if xbmc could deal with it. Technically it should be possible to randomly seek within a compressed rar archive (like rar2fs, WinArchiver, WinMount, etc) but I don't know if it's worth the effort to implement it.Randomly seeking in a compressed archive is not really feasible without first extracting the entire archive to some temporary storage or RAM.
rar2fs (as you mention) can seek *forward* in an archive but it can not seek backwards more than the size of the I/O buffer. The compression algorithm as implemented by RAR is based on a "block neighboring" technique. That is, one block is dependent on the block before that to get its unique decompression key/state. So simply, randomly choosing a block is not possible. But, it is theoretically possible if the result of each block was to be stored and cached for later. Then that metadata could be used to extract from a random block location. But again, it would still require post-processing of the file and complete extraction of it. But only once. Problem is that the cache needs to be big and would require a lot of temporary storage since an archive may consist of a huge quantity of blocks. So, theoretically possible but in practice hard to implement. You would waste resources you probably intended to save by keeping the file in the RAR archive in the first place.
RE: Xbmc to unpack a big file. Why? - jmarshall - 2012-10-12
I think the only thing that could be done to improve things is for non-user-initiated file interaction to be done without prompting.
It seems odd that it pops up when you browse your library (I assume in a library node). This implies that the compression flag wasn't detected during scan and that the file was added to the library. It really shouldn't be, as we should basically be completely ignoring compressed rars during scan.
I suspect, based on the unrarlibx code, that this is non-trivial to detect. Perhaps once libarchive is solid we'll be able to do something nicer.
RE: Xbmc to unpack a big file. Why? - bannedlabel - 2012-11-16
Is there a way to turn off the automatic unpacking that starts every time you enter the movie library, without unpacking the movies? (I can keep on seeding when it's unpacked/unchanged)
RE: Xbmc to unpack a big file. Why? - jmarshall - 2012-11-17
Don't seed stuff that is packed. That's the only way to break the cycle.
RE: Xbmc to unpack a big file. Why? - Pei-turn - 2014-09-05
All you people who does not understand RAR/Original-releases just read http://whyrar.omfg.se/index_eng.php
RE: Xbmc to unpack a big file. Why? - helta - 2014-09-05
Everyone using rar's should just face the fact that you are not part of the scene, never will be a part of the scene, and should extract your damn rar's.
RE: Xbmc to unpack a big file. Why? - fritsch - 2014-09-05
Haha :-) but but but ...
RE: Xbmc to unpack a big file. Why? - un1versal - 2014-09-05
That's one big assumption helta,
though if "you" were part of the scene you wouldn't be making posts about why xbmc and rars, and would know better than to use compressed rars instead of stored and most definitely if "you" would be part of scene wouldn't be posting links about why scene uses rar's to educate the people who dont know why rars are actually used. In that case that site is at best incomplete and the reason is not actually there.fritsch said it best but but but.
RE: Xbmc to unpack a big file. Why? - helta - 2014-09-05
I didn't post that link, besides I store my blu-rays on floppies, 5 1/4 inch. Maintains compatibility with my C64.
RE: Xbmc to unpack a big file. Why? - fritsch - 2014-09-05
I do the same.
RE: Xbmc to unpack a big file. Why? - Martijn - 2014-09-05
damn. i want to have such a modern method
i still need cassette tapes
RE: Xbmc to unpack a big file. Why? - helta - 2014-09-05
my courier group still uses bikes.
RE: Xbmc to unpack a big file. Why? - Tuxon86 - 2014-09-05
Cassettes... Ah! Here it's paper tape for bluray and manual dip-switching data entry for DVD iso...
RE: Xbmc to unpack a big file. Why? - Prof Yaffle - 2014-09-05
I have my films carved frame-by-frame into rocks which I animate by rolling them down a hill. Never needed a backup, although a few frames have killed the odd passer-by.