Improve soccer/all next-match coverage with a secondary schedule source

[Chreece]

What I would like to improve

When a user follows one soccer team across all competitions, ESPN can occasionally know about a later match while missing an earlier fixture from another competition.

From the user's side this can make TeamTracker show the wrong next match, even though the earlier fixture is available from another public schedule source.

I have been testing a possible follow-up to #364 that keeps ESPN as the main source and uses TheSportsDB only as a supplemental schedule source for soccer/all.

What users would see

There would be no extra setup:

• no account;
• no personal API key;
• ESPN remains the preferred source;
• if both sources describe the same fixture, ESPN wins;
• the supplemental source is only used when it safely finds an earlier valid fixture;
• if the team cannot be matched safely, TeamTracker stays on ESPN;
• normal league-specific sensors and other sports are unchanged.

How I kept the prototype isolated

I tried to follow the existing provider/parser architecture rather than spread the change through shared code:

• no changes to the shared coordinator or sensor entity;
• no changes to parse_espn.py or parse_espn_all.py;
• provider-specific HTTP/caching stays in a small TheSportsDB client;
• supplemental events are adapted into the existing ESPN-style response shape so the existing parser can continue to handle the sensor;
• ambiguous team matches are rejected instead of guessed;
• explicit gender metadata must agree across sources;
• selected supplemental fixtures are refreshed by event ID around kickoff;
• requests are cached and rate-limited.

Validation so far

The current local prototype has passed:

• targeted supplement tests: 47 passed;
• existing soccer/all regressions: 16 passed;
• full repository suite: 138 passed;
• snapshots: 46 passed;
• pylint: PASS;
• diff hygiene: PASS.

I also live-tested:

• normal ESPN behavior;
• ESPN preference when both sources describe the same fixture;
• rejection of an unsafe cross-gender team match;
• a real case where the supplemental source had an earlier fixture and was selected;
• retained event refresh by event ID;
• fresh pre-kickoff reacquisition.

I have not yet observed a real supplemental fixture cross PRE -> IN -> POST live. Those states are covered by tests, but I do not want to claim live behavior that has not been observed.

Because this adds another data source and changes source/polling behavior, I wanted to discuss the direction here before opening a PR.

Would this kind of focused supplemental-source approach fit the project direction after #364, or would you prefer a different boundary?

AI-assisted development

I used ChatGPT substantially to inspect the existing implementation, design test probes, help write/refactor the prototype and tests, and analyze API results. I ran the tests and live probes myself, reviewed the changes, and can explain/support the code.

[Chreece]

This should cover specific cup leagues and friendly games not covered by ESPN (testing needed)

[vasqued2]

This is interesting.

I would want to break this into 2 phases. Phase 1 would introduce TheSportsDB as an additional data provider. This should follow the existing architecture and introduce a provide_sportsdb.py file and parse_sportsdb.py file. I am very interested in this. If I remember correctly, SportsDB supports sports beyond soccer. Ideally, this change would not be limited to soccer. If soccer were Phase 1a, I would be good w/ that but would want to be able to extend to other supported sports too. Phase 1 would allow separate sensors to be created for matches not supported by ESPN. This would be a first release.

Once this release is confirmed and working, I would consider a separate release to do some sort of merge or joint look-up. I am not 100% convinced this could work or how it would work as I'm not sure how team ID's/names, etc. are consistent across different sources. This would create a pattern for how other sources could be combined, not just ESPN and SportsDB so want to be very deliberate about it.

Thanks for bringing it up.