[jmarshall]

Multipaths suck. Ok, they don't suck, but supporting them sucks.

I've been struggling with a few things, one of which is how to support multiple paths for tvshows properly in terms of the database etc. The conclusion is that it's practically impossible to get things completely right in the presence of multipaths. The user can go and edit a multipath after the initial addition to add a path, and when they do so the paths no longer match, causing various issues. In some places when we get a multipath we replace it with the first path from the multipath. This is fine as long as the user doesn't go and change the first path...

i.e. it's extremely difficult to come up with a full-proof way to deal with the fact that multipaths can change.

So, I'm considering their removal. The main use-case for them is combining multiple shares/sources under a single one for browsing by file. The main advantage of using multipaths is not for the combining at the 'root' level, but rather for the combining at later levels.

e.g.

/mnt/disk1/shows/house.of.cards/season1/episodes1..6.avi
/mnt/disk2/shows/house.of.cards/season1/episodes7..12.avi

If a multipath of /mnt/disk1 and /mnt/disk2 is done, then at all levels you'll see a single directory (shows/house.of.cards/season1) and at the final level you'll see all episodes. This is kinda nice for the user, but it is a pain in the arse from a code perspective, as shitloads of code needs to know how to deal with "multipath:// /mnt/disk1/shows/house.of.cards/season1/ , /mnt/disk2/shows/house.of.cards/season1/" style URLs.

My proposal is to drop the facility completely (with the possible exception of the root definition of sources, though I'd tend to kill that as well) so the user will simply see their filesystem as it really is - they have library mode for the pretty combining of stuff after all.

But, I may be unaware of some critical use whereby the removal of it will seriously piss users off. So, before I go ask the users, any opinions?

Cheers,
Jonathan

[Ned Scott]

I can only speak from a user's perspective:

It's a neat ability on paper, but even after specifically trying, I am not really able to find a use that works good enough to justify it over a library-based alternative. I think I've used the feature maybe once or twice, and I could have just as easily moved files over.

It's a topic that I've found very hard to describe on the wiki, and while it is mentioned at least once ( http://wiki.xbmc.org/index.php?title=Add..._locations ), it's mostly ignored as it makes the instructions much more complicated. It's honestly easier to move files even if you have to rescrape. Library source management is already complicated in that one path can be a source (add "movies" as a path and set it as "movies") or one path can have several sources (add a generic "videos" folder as a path, set sub-folders as "movies" and "TV shows"). Adding multipaths to that matrix makes my head want to explode, and I feel I have a good grasp on the concept.

I'm also guessing (and might be totally off on this) that removing multi-paths might make it easier to come up with solutions for when files move in the library? Not wanting to deal with moving existing files is one reason to use multi-paths. Removing multipaths might in itself reduce the demand for multipaths, so everybody wins? (in the long run)
EDIT: err, brain fart. Library still combines things.

I'm also guessing this might make library paths easier to manage when they somehow differ between what is in sources.xml and what is in the database?


(I haven't tried this myself, and I don't like the idea of trying to explain or encourage this but:
Any user who really refuses to keep a single show on a single hard drive also has another solution, though it might also be viewed as hacky for all I know: path substitution (wiki). The old path looks like the new path, plus the new path really does exist and has files as well. Sounds horrible, but perhaps that in itself will inspire those users to shuffle those files after all, rather than use pathsubs or multi paths.)

[jmarshall]

I have single shows across multiple disks. I think the worst case I have is a show across 4 disks :p. In most cases I bother enough to get a whole season on a disk, but I just ran out of space (new 4TB drive about to go into the array) and I dunno if I can be bothered moving things about this time around...

But yeah, I don't bother with multipath stuff, and do just as you suggest in your second case (i.e. in files I add each disk, then set content on the subfolders of each as appropriate).

I use files for quickly going to something new or temporary, everything else is in the library anyway.

[Montellese]

I think it's a pretty nice feature on the source level i.e. I can add one "Movies" source and then point it at multiple paths on multiple drives. I probably won't be needing it anymore since I've just built a NAS with a RAID but I can see it's usefulness.

I'm not sure which cases cause specific problems but I've always found it dangerous that the user can actually type in a path instead of only being able to select a path by browsing. Obviously it's still possible to change the first path in a multipath through browsing as well.

But isn't the root cause of the problem that we may be relying too much on the path(s) of an item (which becomes problematic with multiple paths belonging to the same item)? I've seen many places where a list of database items is compared and it uses the path to compare two items even though there's much better and more accurate information available (like the item type and database ID).

[jmarshall]

That's the root cause, yes. I have a branch that basically moved m_strFileNameAndPath et. al. private. Needless to say, I fairly quickly started backing away :p

EDIT: To expand, there's actually more stuff that's unrelated to the above issue. e.g. given we have multipath://path1,path2 and we then have a new path3 added, can we guarantee when adding a show spanning these three paths that we correctly detect that it's currently assigned to multipath://path1, path2, and that multipath://path1, path2, path3 isn't going to cause issues if we assign the show there as well? What about if the user browses just to path1 (not via the multipath) then there'd be nothing indicating that the show in path1 is actually in the library, as it's assigned to a multipath. The same thing happens the other way around.

But in some cases we do need to compare non-db items to db items. Perhaps it doesn't happen enough that hitting the database to get the path (or dbid for the non-db item) is expensive - I dunno.

The thing that prompted this was the particular case where a show is assigned to a multipath and we want to determine from files view whether a show folder is in the library in order to show the library information. If it's a multipath, do we test each one? (this is what we do atm) If so, we're assuming that the show has not been assigned to a multipath.

i.e. basically we're assuming that the library itself knows about multipath:// and when you add a show pointed there, it goes and fills tvshowlinkpath with each path, rather than the multipath. It isn't obvious to me why the database should have a bunch of code to handle these cases...

Cheers,
Jonathan

[Martijn]

My only use case it that i have added one "movie" source that has multiple server locations added to it so i only have one source entry in the list on which you one time set the scraper. Same i do for tvshows and music. So not really because one show is scattered across different disk but more for convenience for scraper setting. So basically the same as Montellese.
I wonder how many users actually know about this feature and still use or actually need it.

From add-on/json point of view the multipath:// is also a hell to support as it's a special use case where many things can go wrong or you need to add some workarounds.

I presume you will add some conversion code to transfer the current multipath:// to separate sources? This is one place where possible issues can occur.
Example as now my "movies" source needs to be split up in three separate entries with the same scrapers settings as i already had and having some meaningful entry name. I also use these in source entries in smartplaylists which could become broken as well.

Just throwing out my use case with things to be taken into account of possible issues with removing it (which i'm for as it would probably simplify things a lot).

[jmarshall]

I would keep the multiple-paths in a source thing in place (via a different mechanism), yes. In the short term, I'm thinking we replace the multiple-path source thing as basically a single entry for the "source" which when you click on it then gives you all the paths you've assigned to it. That way you don't get the issue with what to do with duplicates from merging the lists from multiple paths. In the long term we might look to reverse the logic. i.e. "Add Movies" -> Choose paths to add, rather than "Add paths" -> "Choose content type".

So yeah, if the only thing you're really using it for is "combine these paths into one source that I deal with as a unit", rather than "when I browse this multipath source, please merge any duplicates from each path their own multipaths", you're not using any functionality that wouldn't remain afterwards.

Cheers,
Jonathan

[da-anda]

I also used them once but dropped it. I see no issue with removing the current implemlentation, but I know there are filesystem only users out there, and I think those would like to keep the possibility of a "group of shares" which they can browse in a merged view.

Btw - I'm just wondering why we store the absolute paths in the DB and not only the Source-ID and the relative path to that source, while "multipaths" is just a logical group if independet sources?

[jmarshall]

"I think those would like to keep the possibility of a "group of shares" which they can browse in a merged view."

That's exactly what I would be removing (the merging bit). We need to be pragmatic about support burden versus use.

[Memphiz]

I think we can afford 3 unhappy users more ... rip it out imo.

[da-anda]

jmarshall, would there still be a problem with the merging bit when we ignore library overlays? It should only be for browsing, no library management. Think of it as movie set. The share itself are configured and indexed standalone, but they can be grouped in a "set", and all those sets do is to provide a merged view.. You won't be able to change the content of subfolders etc - only browse and play. Internally XBMC would just have regular shares and their paths. But if this also is of trouble, drop it, was just a thought to keep non-library users happy

[jmarshall]

The merging is the problematic case. i.e. the bit where you have to list 3 different paths and merge their contents into one list, where any duplicates create their own shared paths. Such as the example from the first post.

[natethomas]

Getting rid of it also gets rid of at least one button during the source set up, which is never bad IMO.

[popcornmix]

I've managed to survive this long without knowing that multipath:// existed.
None of the bug reports or logs I've studied have used it. I'm guessing it's used by very few people.

If few people use it and it's a pain to maintain then drop it.

[jjd-uk]

My only use for it is similar to the others, one entry point for related locations on multiple servers, so

Movies Source:
//server1/movies
//server2/movies

TV Source:
//server1/tv
//server2/tv

There are no shows split across the servers so don't particularly need the merging at a low level.