Kodi Community Forum

if i remember correctly i used to be able to browse rar files and play the images inside, also dvds:

"
quote (spiff @ aug. 04 2005,03:05)
all good things come to those who wait

- 04-08-2005 added: proper stored rar support.

now go play those avi's, those .imgs those .bins etc straight from stored rar files

spiff
"

i have a 90 file rarred dvd. each rar is 50mb large. inside the rar file is the actual dvd image, ie the vob files ect. however when opening the directory (smb) where the rars are lying, xbmc hangs.

i tried a one part rar file with a 15mb avi file inside and when opening the directory where the rar is stored and this works perfectly as discussed in other threads: the rar is shown and can be openend and you can select the avi file to be played.

maybe i missed something, maybe the rar support is not for dvd (yet)?

anyway, here is the log. xbmc just hangs when fetching the dir. the server i'm using is connected via cable and non-rarred dvd video content is streamed perfectly.

built on dec 16 2005
....
21-12-2005 23:23:19 debug current m_vecpathhistory:
21-12-2005 23:23:19 debug 00.[]
21-12-2005 23:23:21 debug cguiwindowvideofiles::getdirectory (smb://floris/downloads)
21-12-2005 23:23:21 debug parentpath = []
21-12-2005 23:23:21 debug fetching directory (smb://floris/downloads)


//regs -floris

disable stacking. i just confirmed that stacking more than 60 files crashes xbmc. 60 files is ok. 61 = crash.

** edit **
if stacking is disabled, you should be able to play a dvd out of a multipart rar set. i just tested with a 90 part rar set and it worked fine, got the dvd menu and everything.

hmm, that's strange. stacking shouldn't cause crashes - maybe it's the getvolumefromfilename() code??

i'll take a look if it's not fixed by the new year.

cheers,
jonathan

thanks for looking into it. stacking off - and the rars show up again without locking xbmc. :kickass:

cheers, floris

jm,
it wasnt getvolume either. the crash happens after all the stacked items were identified. i did some testing and it seems to crash when the total stacked path exceed 1300 bytes.

in the meantime, i threw in a workaround for file.partxxx.rar sets so that they stack a bit differently. (technically, they arent stacked at all in my workaround. i'm just removing all the files but the first from the item list.)

see this thread for some more info:
http://www.xboxmediaplayer.de/cgi-bin....t=17358

yeah, that'll be it - there is likely places somewhere where we are using char arrays to represent the paths, and these will have a fixed length.

this needs to be found and remedied.