Medusa: Improve multiple indexer support

[p0psicles]

Just a list of items that should probably be fixed / enhanced before the addition of multiple indexers:

Database fields:

• [ ] There really needs to be some consolidation and standardization of how we refer to the show and episode indexes and ids. Having references to indexerid, indexer_id and indexer can be confusing. Not really a high priority however, may cause more grief than anything if there are many references around.

Scene exceptions:

• [x] Scene exceptions are currently loaded into the database and are indexed purely by an indexer id. Ideally we should we should really store this against indexer number + indexer id

Show 'indexerids':

• [ ] There needs to be adjustment to code to handle the fact that two indexers may have the same 'indexerid' for two different shows. Eg both Tvmaze and Anidb start their show ids at 1 and increment onwards. Currently the only way I see this working is removing all reference to indexerid in a fair chunk of all gui / backend code that we perform and replacing it with the unique database index

Duplicate show detection:

• [x] There may be duplicate shows added over two or more indexers. Eg adding family guy on Tvdb and Tvmaze. Whether we completely block this ever happening or add code to deal with this needs to be sorted.

List originally created by @adam111316

[OmgImAlexis]

Since XEM maps between indexers can we use their global ID to map between indexers instead of a db id? Since the db id may be different depending on the order and what shows you add this would allow us to have a single ID per show for all users and all installs.

[labrys]

@OmgImAlexis no because it only works if the show is listed in xem, and as was mentioned with tvrage, putting too much responsibility on a single provider can be problematic if the provider goes down. Also there is no reason to need a global id for all medusa clients, a local id should be sufficient.

[OmgImAlexis]

@p0psicles did you want to update this to address what's been changed since March last year?

[labrys]

Personally I prefer a structure like the following:

source { id integer (pk), name text, slug text, website url, ...}

item {id integer (pk), source_id integer (fk), remote_id }  # remote_id: id used by the source
    unique constraint (item.source_id, item.remote_id)

item_info { id integer (pk), item_id integer (fk), language ISO Language, .... }
    unique constraint (item_id, language)  # for language specific information

item_map { source_id (fk), reference_id {fk} }  # map x-ref'd IDs and (id1, id2) != (id2, id1)
    pk constraint (source_id, reference_id)

[fernandog]

@p0psicles we can close it right?

[p0psicles]

3 of 4 of these issues still apply imo.