[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