[Wipe]

Multi rar seems to be broken for me in release 18.0 "Leia". My Android TV automatically updated from v17 to v18 and now It can't detect movies that were detected before. Tried reinstalling Kodi altogether and also installed the Add-on RAR archive support but nothing works. The only problem is with Multi rar files, .mkv files works as expected. Has anyone else experienced this? 

https://kodi.wiki/view/Add-on:RAR_archive_support

i have an Mi box and have the same issue, is there any workaround or fix for it? Revert to version 17?

[Gomez]

Multi rar seems to be broken for me in release 18.0 "Leia". My Android TV automatically updated from v17 to v18 and now It can't detect movies that were detected before. Tried reinstalling Kodi altogether and also installed the Add-on RAR archive support but nothing works. The only problem is with Multi rar files, .mkv files works as expected. Has anyone else experienced this? 

https://kodi.wiki/view/Add-on:RAR_archive_support

i have an Mi box and have the same issue, is there any workaround or fix for it? Revert to version 17? 

Install libarchive and remove rar archive. Reboot. Worked for me.

[Brice]

Actually I did the opposite. I had to disable the VFS archive plugin and keep the VFS RAR plugin enabled.

The archive plugin made the multi-RAR file appear as folders which somehow caused problems with the library as well.
On the other hand the RAR plugin make the RAR archives "transparent", which solved the issue with library.

[Omrgyl]

I have tried that on multiple different Android HW platforms (Nvidia Shield, Samsung S4 tablet, etc.). Have installed both VFS Archive and VFS RAR plugins. If I disable VFS Archive, Kodi app crashes as soon as I open the directory with multi-rar media. If I do it in a vice versa approach, e.g. disable VFS RAR and enable VFS Archive, I can see the full media file listed in the directory together with correct filesize.  However, when I am trying to playback the listed file, the playback usually just crashes without getting started. This behavior is consistent accross my Android platforms. Anyone with a similar experience and/or possible workaround?

[Beam]

I tried multi-rar media on ubuntu and andriod. Both VFS archive a VFS RAR plugins enabled.
No crashes, everything works except https://github.com/xbmc/xbmc/issues/15494 . I have to use context menu & play, not only play (enter) on scrapped item.

[Omrgyl]

No, it does not work for me that way. With both addons installed, with any combination of enabled/disabled I am not able to start playback of the scrapped file, neither directly using "Enter" nor via context menu "Play". The GUI just shows spinning wheels for a few seconds, then it fails.

[Gomez]

Actually I did the opposite. I had to disable the VFS archive plugin and keep the VFS RAR plugin enabled.

The archive plugin made the multi-RAR file appear as folders which somehow caused problems with the library as well.
On the other hand the RAR plugin make the RAR archives "transparent", which solved the issue with library.

You are right. At least with vfs.libarchive i can play movies (need to use the files view), but the library does not get populated. I opened a issue on github, would be good if some can confirm / add more info: https://github.com/xbmc/vfs.libarchive/issues/27

FYI the plugin developer says  vfs.libarchive is the way to go, see here: https://github.com/xbmc/vfs.rar/issues/2...-407388300

[blunden]

Actually I did the opposite. I had to disable the VFS archive plugin and keep the VFS RAR plugin enabled.

The archive plugin made the multi-RAR file appear as folders which somehow caused problems with the library as well.
On the other hand the RAR plugin make the RAR archives "transparent", which solved the issue with library.

You are right. At least with vfs.libarchive i can play movies (need to use the files view), but the library does not get populated. I opened a issue on github, would be good if some can confirm / add more info: https://github.com/xbmc/vfs.libarchive/issues/27

FYI the plugin developer says  vfs.libarchive is the way to go, see here: https://github.com/xbmc/vfs.rar/issues/2...-407388300    

Wanting people to move to the newer plugin makes sense I guess since the other one is based on pretty old code after all. Once these issues have been worked out, its better support for newer RAR features (judging by the libarchive commit messages) will be a welcome addition and the fact that fewer Kodi-specific patches seem to be needed hopefully makes the plugin easier to maintain too.

Btw. it seems he has already identified the issue you identified.

I wonder if switching plugins from the old one to the new one once the latest fixes are available from the repo will work without issues? I'm hoping that's the case. Rescanning everything after the move from SPMC to Kodi earlier today (despite using the backup plugin to migrate everything) is not something I'd want to repeat again if I can avoid it.

EDIT: This commit suggests it should be backward compatible.

https://github.com/xbmc/vfs.libarchive/p...282142e56a

[Brice]

Ah nice !
For me any video played with archive plugin was failing at some point, but that was a few days ago. I should see if there's an update and if single video in multirar are made "transparent".

Another issue I encountered when using the RAR plugin, is that video just don't play over UPnP, the mkv file within the RAR archive is listed (not the RAR files) but it just doesn't get streamed.

[Wipe]

I installed the archive plugin and had the RAR plugin enabled as well and now the movies start, no crash.

[spiff]

hi, some updates.

after leia release, i have
1) fixed a missing tag in vfs.rar which pushed out v2.0.6 there. it broke multi-archive rars (i fixed it months back but forgot to tag and no new version was pushed out).
2) fixed vfs.libarchive so you scan and play from library (a required member function was missing the implementation). this is being pushed out as 1.0.5 at the moment.

as for compatibility; it is one way. you can use a library scanned with vfs.rar through vfs.libarchive. but if you scanned it using vfs.libarchive, you cannot use it with vfs.rar.
the reason for that is the url protocol changes, and i can handle rar:// with vfs.libarchive, but i cannot handle archive:// with vfs.rar (since it can be a lot of archive types, not just .rar).

[Gomez]

hi, some updates.

after leia release, i have
1) fixed a missing tag in vfs.rar which pushed out v2.0.6 there. it broke multi-archive rars (i fixed it months back but forgot to tag and no new version was pushed out).
2) fixed vfs.libarchive so you scan and play from library (a required member function was missing the implementation). this is being pushed out as 1.0.5 at the moment.

as for compatibility; it is one way. you can use a library scanned with vfs.rar through vfs.libarchive. but if you scanned it using vfs.libarchive, you cannot use it with vfs.rar.
the reason for that is the url protocol changes, and i can handle rar:// with vfs.libarchive, but i cannot handle archive:// with vfs.rar (since it can be a lot of archive types, not just .rar).

thanks spiff! Your work is really appreciated!

Just to make it clear, whats the recommended addon vfs.rar or vfs.libarchive? Is there a difference? I noticed libarchive is slower (true)? Will both be maintained?

[spiff]

libarchive for sure. it may be a bit slower if the underlying IO is slow as it will always open all archives, while i did a lot of cheating there in vfs.rar. but that also means it does things more proper in a lot of cases.
the vfs.rar code is from 2003 and i will not update it other than maintenance. the hacks required to make it work are obnoxious and extremely intrusive.
the new rar code is too restructured, so if i want to update it, i'd have to basically re-add the hacks from scratch.

that being said: as stated i will maintain both, so as long as vfs.rar can handle your needs, there is no reason to not use it, as such.

[blunden]

hi, some updates.

after leia release, i have
1) fixed a missing tag in vfs.rar which pushed out v2.0.6 there. it broke multi-archive rars (i fixed it months back but forgot to tag and no new version was pushed out).
2) fixed vfs.libarchive so you scan and play from library (a required member function was missing the implementation). this is being pushed out as 1.0.5 at the moment.

as for compatibility; it is one way. you can use a library scanned with vfs.rar through vfs.libarchive. but if you scanned it using vfs.libarchive, you cannot use it with vfs.rar.
the reason for that is the url protocol changes, and i can handle rar:// with vfs.libarchive, but i cannot handle archive:// with vfs.rar (since it can be a lot of archive types, not just .rar).

Thanks for the update and the great work in general. Your maintainence of these plugins is greatly appreciated.

Yeah, that's what I meant with backward compatibility, being able to use vfs.libarchive with a library generated using vfs.rar. That's probably the most common upgrade pattern anyway so that limit makes sense.

libarchive for sure. it may be a bit slower if the underlying IO is slow as it will always open all archives, while i did a lot of cheating there in vfs.rar. but that also means it does things more proper in a lot of cases.
the vfs.rar code is from 2003 and i will not update it other than maintenance. the hacks required to make it work are obnoxious and extremely intrusive.
the new rar code is too restructured, so if i want to update it, i'd have to basically re-add the hacks from scratch.

that being said: as stated i will maintain both, so as long as vfs.rar can handle your needs, there is no reason to not use it, as such.

Good to know.

Once again, thanks for maintaining them.

[Brice]

Hi spiff.

Thanks for the explanation.
On e question remains for me. I'm still using the RAR plugin for now but when accessing the library over UPnP the players cannot read / download a single byte of the multirar archive. I'm not sure what so can do.

I'm not ready to switch to libarchive as it may have drawbacks on performance for my device and it cannot be 'rollbacked' I don't want to rescan my library.