[zag]

Keep it simple

So +1 on dropping it

[Kib]

I would like to see them go rather than stay as well. They add a lot of confusion and imho are simply not worth all the hassle.
If getting them out is what it takes to make all path handling and scraping better and more manageable in the future I am all for it.

+1

I do see Martijn's point: Would it be possible to keep them in the way that they are but just translate them to "these sources share scraper settings" and not bother with merging stuff in file view ?

[topfs2]

+1 I agree, the only use case seems to be to the ability to combine multiple servers under one node in sources, which I don't use personally. I find it clearer to just to name them "Series on foo" for example.

And it seems to me that we could handle that case by grouping at the source view/management anyways, i.e. sources.xml supports it and that view but under the hood each added path is a different source. So that throughout core we only care for a proper paths.

[jmarshall]

The only semi-complicated bit is that if you do the sensible thing when listing a source and have a heirarchy (i.e. listing a source with paths a,b,c gives a listing containing those 3 items, and you click on "a" to get the first path etc.) then you need to handle it differently for tvshow scanning, as we'll need to go into each level to set content etc. A minor complication.

In the meantime, I've done work to eliminate multipaths from tvshows in the database. It's working quite nicely, and has killed off a longstanding bug (where you'd get odd/different behaviour depending on where you did "tvshow information" from).

Now you only get different behaviour in the refresh behaviour on a show: If you refresh from the library, it'll refresh items in all paths. If you refresh from a particular folder, it'll refresh only for that folder. This is to solve the "Battlestar Galactica" vs "Battlestar Galactica 2004" problem (i.e. partially incorrectly assigned shows).

[topfs2]

Hmm, yeah. Thinking of this more it seems like even if we localize it there it will bleed (as it has) and it will still be complicated, for very very little gain

So +1 from me to remove for sure. I'd much rather see the usage of it be solved through a nice library.