Aki-xStream im September 2026: gepflegte KUS-Linie, starke Szene-Signale, aber schwacher öffentlicher Upstream

Recherchezeitpunkt dieses Berichts: 14. September 2026, Europa/Berlin. Der Bericht wertet öffentlich erreichbare Webseiten, Suchergebnisse, Repository-Daten, Forenlisten, Forenbeiträge, GitHub-Daten, Installationsseiten, Mirror-Hinweise und frühere in diesem Projekt vorhandene Lagebilder aus.

Wichtig ist die Grenze der Aussage: Aki-xStream ist kein klassisches Projekt mit einer einzigen, sauber dokumentierten Release-Seite. Ein Teil der relevanten Informationen liegt in Foren, Profilaktivitäten, Such-Snippets und durch Login-Schranken begrenzten Ressourcen. Wo eine Aussage nicht eindeutig belegt werden kann, wird sie ausdrücklich als nicht eindeutig verifizierbar oder öffentlich nicht nachweisbar markiert.

Dieser Bericht ist eine redaktionelle Lageanalyse, keine Installationsanleitung und kein Download-Verzeichnis. Operative Repo-Adressen, ZIP-Quellen und Workarounds werden deshalb nur als Distributions- und Supply-Chain-Signale eingeordnet, nicht als Handlungsempfehlung ausgespielt.

Kurzfassung: Aki-xStream ist Stand 14. September 2026 öffentlich nicht als eingestelltes Projekt einzuordnen. Die Aki-Linie wird in der deutschsprachigen Kodi-Szene sichtbar genutzt, diskutiert und supportet. Besonders DEB und VMOD liefern aktuelle Signale, während KUS als faktisch wichtiger Verteilweg erscheint.

Wer entwickelt es heute? Öffentlich am stärksten belegbar ist die Rolle von Akisame beziehungsweise der Aki-Linie. DEB verweist auf Akisames xStream Mod als derzeit weiter gepflegte Version, VMOD spricht von einem autorisierten und geprüften xStream-Fork moddet by Akisame. Diese Formulierungen belegen eine starke öffentliche Zuordnung, ersetzen aber keinen formalen Maintainer-Vertrag.

Wo wird es verteilt? Faktisch relevant ist KUS. DEB beschreibt KUS als funktionierenden Kanal und externe Seiten wie BestOnKodi ordnen xStream als deutsches Kodi-Addon aus dem KUS AllInOne Repository ein. Daneben tauchen Mirror-Dateien auf, etwa ein SatSupreme-Hinweis auf Aki-xStream-2026.08.14.zip. Solche Mirrors sind aber nicht automatisch autoritativ.

Zukunftsaussicht: kurzfristig stabil bis positiv, mittelfristig beobachtungsbedürftig. Die größte Stärke liegt in lebendiger Community-Reaktion und funktionaler Pflege. Die größte Schwäche liegt in fehlender öffentlicher, kanonischer Code- und Release-Transparenz für die aktuelle Linie.

Aki-xStream ist nach der öffentlich sichtbaren Quellenlage als aktueller Mod beziehungsweise Fork der xStream-Familie einzuordnen. Das historische xStream-Projekt beschreibt sich selbst als Video-Addon für Kodi und als Suchmaschine für Filme und Serien auf verschiedenen Webseiten. Der bereitgestellte Inhalt dieser Webseiten stehe laut alter xStream-Webseite nicht in Beziehung zu xStream oder den Entwicklern.

Technisch ist die Grundidee nicht das Hosting eigener Inhalte, sondern das Aggregieren, Suchen, Indizieren und Aufrufen externer Webseiten beziehungsweise Site-Plugins. Das Addon selbst ist damit eher Vermittlungs- und Bedienoberfläche als Inhalteanbieter.

Die alte xStream-Seite nennt Python 3 und Kodi 19 oder höher als Basis. Damit gehört die historische Linie in die Matrix- und spätere Kodi-Welt. Für Aki-xStream ist die Python-3-Grundlage plausibel, weil Kodi 19+ Python-3-Addons erwartet; eine eigene öffentliche Aki-Dokumentation zur Python-Version konnte jedoch nicht belastbar gefunden werden.

Funktionen, die in den untersuchten Community-Signalen immer wieder auftauchen, sind Suche über mehrere Quellen, Site-spezifische Indexseiten, Anpassung einzelner Domains, Player-/TMDb-Helfer-Kontext, Vavoo-Umfeld und der Umgang mit Captchas beziehungsweise Cloudflare-ähnlichen Schutzmechanismen. Details zu internen APIs, Resolvern und vollständigen Abhängigkeiten sind für die Aki-Linie öffentlich nicht vollständig auditierbar.

Historisch beginnt xStream nicht mit Aki-xStream. Die alte xStream-Wiki-Seite nennt als Ursprung 2010 und verweist auf Anis3 und Ron801 als frühe Namen; in derselben alten Wiki werden Heptamer und DWH als current developers genannt. Das ist eine wichtige historische Spur, aber kein Beleg dafür, dass dieselbe Infrastruktur heute die aktuelle Aki-Linie steuert.

Die sichtbare Entwicklung lässt sich grob in drei Phasen teilen: das ursprüngliche xStream-Projekt mit eigener Webseite und GitHub-Pages-Infrastruktur, eine unruhige Phase mit Forks, Fixes und konkurrierenden Repos, und die derzeit beobachtbare Aki-/KUS-Linie.

Der Wendepunkt 2026 liegt in der Community-Wahrnehmung. DEB beschreibt im Mai und August 2026 ein Repo-Sammelsurium und nennt KUS mit Akisames Mod als funktionierend, während Michaz keine eigene xStream-Version mehr führe und KUS nur noch enthalten sei. VMOD wiederum dokumentiert im Juli 2026 einen xStream-Fork moddet by Akisame.

Öffentlich am stärksten mit der aktuellen Linie verbunden ist Akisame. Das ergibt sich aus DEB-Verweisen, Akisames sichtbaren Profilaktivitäten und VMOD-Formulierungen zu einem Aki-xStream-Fork. Diese Zuordnung ist für eine redaktionelle Einordnung belastbar genug, um Akisame als zentralen aktuellen Akteur zu nennen.

Heptamer bleibt historisch und im Umfeld wichtig. Die alte xStream-Wiki nennt Heptamer als current developer der historischen Linie; VMOD zeigt Heptamer zudem als xStream Dev + Team VMOD. Gleichzeitig darf daraus nicht automatisch geschlossen werden, dass Heptamer die aktuelle Aki-xStream-Linie operativ pflegt.

DWH ist über die alte Wiki und GitHub-Historie als historischer xStream-Web-/Wiki-Akteur erkennbar. DEB-Moderatoren und Community-Helfer wie u040201, ElDiabolo666, derandere und watchone tauchen als Support-, Kommunikations- oder Umfeldakteure auf. Das sind keine privaten Identitäten, sondern öffentlich verwendete Nicknames.

Die Quellenlage muss strikt getrennt werden: Entwicklung, Distribution, Support und Archiv sind nicht dasselbe. Die alte xStream-Webseite ist eine offizielle wirkende historische Quelle; KUS ist aktuell faktisch wichtig für Verteilung; DEB und VMOD sind Support- und Community-Räume; Mirrors sind Belege für Verbreitung, aber nicht automatisch vertrauenswürdige Ursprungsorte.

Ein aktuelles öffentliches GitHub-Repository für Aki-xStream konnte nicht belastbar verifiziert werden. Die alten GitHub-URLs streamxstream/plugin.video.xstream und streamxstream/xStreamRepo liefern über die GitHub-API 404; das öffentlich sichtbare xStreamRepoWeb ist vorhanden, aber nur Webseite/Wiki-Infrastruktur.

Die Konsequenz ist klar: Wer Aki-xStream bewertet, muss KUS/DEB/VMOD als praktische Realität ernst nehmen, darf sie aber nicht mit einem transparenten Upstream verwechseln.

Die alte xStream-Webseite wirkt offiziell: Sie nennt Repository, Wiki, Matrix-Chat und GitHub-Issues. Sie ist für die historische Einordnung wertvoll und beschreibt das Grundprinzip des Addons. Für die aktuelle Aki-xStream-Linie ist sie aber nicht automatisch die maßgebliche Quelle.

Faktisch maßgeblich erscheint aktuell KUS in Verbindung mit Akisame und der DEB-/VMOD-Kommunikation. DEB nennt KUS als funktionierend und verweist auf Akisames Mod; BestOnKodi beschreibt xStream als deutsches Kodi-Addon aus dem KUS AllInOne Repository; VMOD führt den Aki-Fork als autorisiert und geprüft.

Die Antwort auf die Leitfrage lautet daher: Die offiziell wirkende historische Webseite ist für xStream wichtig, aber für Aki-xStream nicht eindeutig der aktuelle operative Ursprung. Die faktisch offizielle Linie wird öffentlich eher über Akisame/KUS/DEB/VMOD sichtbar.

Öffentlich eindeutig vorhanden ist streamxstream/xStreamRepoWeb. Dieses Repository beschreibt sich als offizielle xStream-Webseite, hat den Default-Branch gh-pages, 71 Commits, 11 Stars, 6 Forks, keine aktivierten Issues und wurde zuletzt am 12. Juni 2026 gepusht. Der letzte sichtbare Commit stammt von Heptamer und aktualisiert die Wiki.

Das ist wertvoll, aber es ist nicht der aktuelle Aki-xStream-Code. Die GitHub-API meldete für streamxstream/plugin.video.xstream und streamxstream/xStreamRepo 404. Daraus folgt nicht zwingend, dass der Code nicht existiert; es bedeutet nur, dass er unter diesen früher naheliegenden öffentlichen Pfaden am Recherchetag nicht öffentlich erreichbar war.

Für Auditing, Supply Chain und Reproduzierbarkeit ist das ein echter Nachteil. Ohne nachvollziehbaren öffentlichen Git-Upstream können Außenstehende ZIP-Dateien, Repository-Pakete und Forenstände nicht sauber gegen Quellcode, Tags, Releases oder Hashes prüfen.

Die aktuellste sicher belegbare Version lässt sich nicht mit der gewünschten Härte bestimmen. Das ist kein Schönheitsfehler, sondern ein zentraler Befund.

Öffentlich sichtbar sind mehrere Signale: DEB listet einen Threadtitel zu xStream 2026.08.07 und einem reproduzierbaren Kodi-Crash; SatSupreme zeigt einen Mirror-Eintrag Aki-xStream-2026.08.14.zip mit 2,02 MB; Kodi-Tipps nennt in einem sichtbaren Such-Snippet xStream Repo Version 1.2.4 und Plugin Version 4.2.0.2, was eher die historische xStream-Linie betrifft.

Für Aki-xStream darf daraus keine endgültige aktuelle Version konstruiert werden. Der sicherste Satz lautet: Eine Aki-xStream-Datei mit Datum 2026.08.14 ist öffentlich als Mirror-Hinweis auffindbar, eine DEB-Fehlerdiskussion nennt xStream 2026.08.07, aber eine offiziell bestätigte aktuelle Aki-xStream-Version mit Changelog, Hash und Release-Seite konnte nicht belastbar gefunden werden.

Die letzten Monate zeigen eher Wartung und Anpassung als ein sauber dokumentiertes Feature-Release-Programm. Sichtbar sind Domain- und Site-Plugin-Themen, Serienstream-/s.to-Anpassungen, Captcha- und Cloudflare-Kontext, Downloadoptionen, Player-/TMDb-Helfer-Umfeld und Diskussionen über entfernte oder bewusst nicht zurückkehrende Funktionen.

Akisame schrieb laut sichtbarer DEB-Profilaktivität am 31. August 2026, dass beim xStream-Mod kein Download-Feature zurückkehren werde und Nutzer angepasster Versionen aus Builds oder nicht unterstützten Repos sich an deren Ersteller wenden sollten. Das ist ein wichtiges Wartungs- und Supportsignal: Es grenzt den unterstützten Zustand ab.

Aktivitätszeichen Anfang/Mitte September betreffen vor allem Captcha- und Serienstream-Hilfe. Das spricht für laufende operative Pflege beziehungsweise Support, aber nicht zwingend für neue Hauptversionen.

Die historische xStream-Webseite nennt Python 3 und Kodi 19+ ausdrücklich. Offizielle Kodi-Dokumentation bestätigt, dass Kodi 19 Matrix und spätere offizielle Addons auf Python 3 ausgerichtet sind. Für Aki-xStream ist damit Kodi 19+ plausibel, aber nicht jede Zielplattform ist öffentlich sauber getestet.

Kodi 22 Piers ist am 14. September 2026 noch Vorabsoftware; Kodi selbst veröffentlichte am 5. September 2026 Beta 2. Für Aki-xStream gibt es öffentlich keinen belastbaren Nachweis einer vollständigen Kodi-22-Freigabe. Alles, was auf Kodi 22 läuft, sollte bis zu einer stabilen Kodi-22-Lage als Teststatus betrachtet werden.

Die öffentliche DEB- und Kodi-Szene zeigt Nutzung auf Android, Fire TV, Windows/Linux, LibreELEC und ähnlichen Systemen. Einzelne Nutzermeldungen sind aber keine offizielle Kompatibilitätsmatrix.

Die wichtigste Regel lautet: Nicht jedes Problem, das in xStream sichtbar wird, ist ein Kernfehler von Aki-xStream. Viele Störungen entstehen bei externen Webseiten, Captchas, Domains, Cloudflare-Schutz, Hostern, Playern, Dateisystemrechten oder alten Builds.

DEB zeigt mehrere typische Fehlerklassen: Serienstream-/s.to-Änderungen, Cloudflare-Hinweise, Android-Dateizugriffsprobleme, fehlende Einstellungen nach Updates, falsche Sprache bei Downloads und einen benannten Crash-Kontext zu xStream 2026.08.07. VMOD führt zusätzlich einen Bug- und Hilfethread für xStream und xShip.

Auffällig ist die Supportlogik: Erfahrene Nutzer fragen nach Aktualisierung, Index, Version, Quelle und konkretem Kontext. Das ist gesund, weil es pauschale Schuldzuweisungen reduziert.

Aki-xStream ist strukturell abhängig von externen Webseiten. Das ist kein Nebenthema, sondern das Wesen eines Addons, das fremde Quellen durchsucht oder anbietet. Jede angebundene Seite kann Domains, HTML-Struktur, APIs, Captchas, Cloudflare-Regeln, Login-Erwartungen oder Hosterpfade ändern.

Zusätzlich wirken Kodi-Mechanismen wie Python-Version, Addon-Manifest, Settings, Player-Konfiguration, TMDb-Helfer-Dateien und mögliche Resolver-/Hosterlogik. In der Community tauchen außerdem Vavoo, TMDb Helper, Serienstream, Kinokiste/Kinox-Kontexte und 2captcha als Stichworte auf. Für die Aki-Linie konnte jedoch keine vollständige öffentliche Dependency-Liste verifiziert werden.

Besonders häufig problematisch sind Captchas, Cloudflare-ähnliche Bot-Abwehr, Domainwechsel, entfernte Quellen, Hoster-Limits und alte Builds. Das sind genau die Stellen, an denen Nutzer oft Aki-xStream beschuldigen, obwohl das eigentliche Ereignis außerhalb des Addon-Kerns liegt.

Exakte Installationszahlen sind nicht öffentlich verfügbar. Es gibt keine belastbaren Downloadzahlen, aktiven Nutzerzahlen oder Telemetrie, die sauber auf Aki-xStream bezogen werden könnten.

Indirekte Indikatoren sprechen dennoch für Relevanz: DEB führt mehrere xStream-Threads mit teils hohen Aufrufzahlen; VMOD listet Aki-xStream im Video-Addon-Umfeld; BestOnKodi und Kodi-Tipps führen xStream in aktuellen Installations- beziehungsweise Addon-Kontexten; SatSupreme spiegelt eine Aki-xStream-ZIP; CHIP veröffentlicht weiterhin xStream-Anleitungen.

Die Verbreitung ist damit nicht messbar, aber sichtbar. Aki-xStream ist kein Randartefakt ohne Publikum, sondern ein Projekt mit erkennbarer deutschsprachiger Szene-Präsenz.

Die wichtigsten Informationsräume sind nicht klassische Tech-Medien, sondern Communities. DEB liefert die stärksten aktuellen Support- und Statussignale. VMOD liefert ein zweites Szene-Fenster mit eigener Bewertung und eigenen Akteuren. Kodi-Tipps, BestOnKodi und CHIP erzeugen Außenwirkung, sind aber eher Installations- und Sichtbarkeitsquellen als Entwicklungsquellen.

Reddit zeigt kaum belastbare Aki-xStream-Diskussionen. Stattdessen erscheinen dort vor allem ähnlich benannte, aber inhaltlich andere Projekte wie XStream Player und XStream Pro für Xtream Codes/IPTV. Genau diese Treffer sind für Namensabgrenzung wichtig.

Die Stimmung ist überwiegend pragmatisch positiv, aber nicht blind euphorisch. Mehrere Signale zeigen, dass die aktuelle Aki-/KUS-Linie als funktionierend und gepflegt wahrgenommen wird. Gleichzeitig gibt es Kritik an einzelnen Quellen, Indexständen, Build-Varianten und Funktionsentscheidungen.

Funktionalität: eher positiv, sofern Nutzer auf aktueller Linie bleiben. Stabilität: überwiegend okay, aber quellenabhängig. Entwickler: Akisame wird als aktiv wahrgenommen, was Vertrauen schafft, aber zugleich den Bus Factor erhöht. Repository: KUS scheint praktisch wichtig, aber die Repo-Lage bleibt für Außenstehende nicht so transparent wie ein öffentlicher Git-Release-Kanal.

Einzelne Nutzer berichten Probleme oder vergleichen negativ mit anderen Ständen. Daraus lässt sich kein allgemeiner Konsens gegen Aki-xStream ableiten. In den untersuchten Threads überwiegt eher die Haltung: aktuelle Version nutzen, alte Repos meiden, konkrete Fehler sauber einordnen.

Öffentlich sichtbar ist eine aktive Reaktion auf konkrete Problemklassen. Akisame reagiert im DEB-Umfeld auf Serienstream, Captcha, Downloadoptionen und Nutzungsfragen. Das heißt nicht, dass jeder Fehler sofort im Code gefixt wird, aber es zeigt eine lebendige Supportspur.

Konkrete Beispiele: Bei Serienstream/Captcha werden Hinweise auf die externe Webseite, Captcha-Erkennung und 2captcha-Kontext gegeben. Beim Downloadfeature wird klar kommuniziert, dass es nicht zurückkehren soll. Bei angepassten Versionen aus Builds oder nicht unterstützten Repos wird an deren Betreiber verwiesen.

Diese Reaktion ist technisch sinnvoll, weil sie Zuständigkeiten klärt. Gleichzeitig zeigt sie die Schwäche: Ohne öffentliche Issues, Pull Requests und Release-Notes bleiben viele Entscheidungen in Foren verstreut.

Aki-xStream steht nicht allein, sondern in einer xStream-Landschaft aus historischer Original-Infrastruktur, alten Repos, Forks, Mods, Builds und Mirrors. Die wichtigste aktuelle Linie ist nach öffentlicher Lage Akisames Mod/Fork über KUS. Daneben tauchen Michaz, Seizu, alte streamxstream-Pfade, KodiBox-Builds und Mirror-ZIPs auf.

Michaz wird im DEB-Hilfethread aktuell nicht mehr als eigenes xStream/xShip-Repo beschrieben, sondern als Umfeld, in dem KUS enthalten sei. Seizu wird dort als alte beziehungsweise letzte öffentliche xStream-Version beschrieben. Das sind wertvolle Einordnungen, aber sie stammen aus Community-Kontexten und nicht aus einer formalen Projektleitung.

Supply Chain ist der kritischste technische Vertrauenspunkt. Die Herkunft aktueller Pakete ist öffentlich nicht so eindeutig nachprüfbar wie bei einem offenen GitHub-Release mit Tags, Hashes, Checksums, signierten Releases und reproduzierbarer Build-Anleitung.

Es gibt keine belastbar gefundenen Hinweise auf konkrete Malware in Aki-xStream. Eine solche Behauptung wäre unseriös. Das Risiko entsteht nicht aus einem belegten Angriff, sondern aus der Verteilrealität: mehrere Repos, ältere Stände, Mirrors, Build-Varianten, ZIP-Dateien und teilweise versteckte Foreninhalte.

Bewertung: 🟡 mittleres Risiko. Begründung: aktuelle Community-Linie wirkt lebendig und nicht kompromittiert, aber Herkunft, Hashes, Signaturen und öffentlicher Upstream sind nicht ausreichend transparent, um ein geringes Risiko zu vergeben.

Aki-xStream beziehungsweise xStream hostet nach historischer Eigenbeschreibung keine eigenen Inhalte, sondern verweist auf beziehungsweise durchsucht externe Webseiten. Die rechtliche Bewertung hängt deshalb stark davon ab, welche Quellen genutzt werden, welche Inhalte dort verfügbar sind und ob diese Inhalte mit Zustimmung der Rechteinhaber öffentlich zugänglich sind.

Für Deutschland und die EU sollte nicht von einer alten Streaming-Grauzonenformel ausgegangen werden. Der EuGH hat in Filmspeler C-527/15 und in der The-Pirate-Bay-Entscheidung C-610/15 zentrale Leitlinien zur öffentlichen Wiedergabe, Links beziehungsweise Zugang zu offensichtlich rechtswidrigen Quellen gesetzt. Streaming aus offensichtlich unrechtmäßigen Quellen kann urheberrechtlich problematisch sein.

Dieser Abschnitt ist keine Rechtsberatung. Für Nutzer ist die praktische Folgerung schlicht: Kodi als Mediacenter ist legal; ein Addon und die jeweilige Nutzung sind nur so unproblematisch wie die konkret genutzten Quellen und Rechte.

Der Name xStream ist extrem verwechselungsanfällig. In Suchergebnissen tauchen Java-Bibliotheken namens XStream, Airtel Xstream, Xtream Codes, XStream Player, XStream Pro, IPTV-Player und M3U-/Xtream-Code-Addons auf. Diese Projekte gehören nicht zu Aki-xStream.

Besonders wichtig: Reddit-Treffer zu XStream Player und XStream Pro betreffen IPTV-/Xtream-Codes-Addons, nicht die deutschsprachige xStream/Aki-xStream-Linie für Webseitenquellen. GitHub-Treffer wie Pesicp/XStream-Player-Kodi21 sind daher als Namenskonflikt zu behandeln, nicht als Fork der hier untersuchten Linie.

Das aktuelle Verbreitungsnetz ist nicht linear wie bei einem klassischen GitHub-Release. Es ist eher ein Dreieck aus Maintainer-Signal, Repository-Verteilung und Community-Support.

Das Modell unten ist eine redaktionelle Abstraktion, keine technische Installationsanweisung.

Die Rollen lassen sich öffentlich nur anhand von Nicknames und Plattformfunktionen beschreiben. Private Identitäten werden nicht recherchiert und nicht behauptet.

Wichtig ist die Unterscheidung zwischen Entwickeln, Verteilen, Supporten und Berichten. Viele Konflikte in Kodi-Szenen entstehen genau dann, wenn diese Ebenen vermischt werden.

Die größte Stärke von Aki-xStream ist nicht eine einzelne Funktion, sondern die lebendige operative Pflege im Community-Umfeld. Wenn externe Seiten Domains ändern, Captchas schärfen oder Nutzer mit alten Builds arbeiten, entsteht schnell Supportbedarf. Genau hier scheint Aki-xStream aktuell nicht verlassen zu sein.

Die Aki-/KUS-/DEB-/VMOD-Achse schafft praktische Orientierung. Nutzer haben Orte, an denen Versionen, Indexstände, Fehler, Quellen und Zuständigkeiten diskutiert werden. Das ist bei Kodi-Addons oft wichtiger als eine schöne Projektseite, weil die eigentlichen Probleme selten statisch sind.

Kurz: Aki-xStream lebt dort, wo solche Addons real leben: in schneller Anpassung, Forenwissen und pragmatischer Fehlertrennung.

Die größte Schwäche ist die fehlende öffentliche, kanonische Entwicklungs- und Release-Transparenz. Ohne öffentliches Git, Tags, Releases, Checksums und klare Changelogs bleibt die Bewertung stark abhängig von Forensignalen.

Das ist organisatorisch empfindlich. Es erschwert Audits, erschwert Forks, erschwert historische Rekonstruktion und macht es schwerer, legitime Pakete von alten oder modifizierten Ständen zu unterscheiden.

Technisch kommen externe Abhängigkeiten hinzu. Selbst ein sauber gepflegter Addon-Kern kann schwanken, wenn die angebundenen Webseiten ihre Schutzmechanismen ändern.

Der Bus Factor wirkt niedrig. Wenn Akisame als sichtbarer Hauptakteur wegfällt oder KUS als Verteilkanal ausfällt, wäre die aktuelle Linie nicht automatisch tot, aber öffentlich deutlich schlechter koordinierbar.

Weitere strategische Risiken sind externe Quellen, rechtliche Angriffsflächen bei offensichtlich rechtswidrigen Streams, Captcha-Ökosysteme, nicht öffentliche Buildprozesse, wenige verlässliche Changelogs und die Verwechslung mit alten oder fremden Projekten.

Die Szene kann solche Risiken teilweise durch transparente Changelogs, Hashes, öffentliche Read-only-Repos, klare Supportgrenzen und eine sichtbare Maintainergruppe entschärfen. Öffentlich nachweisbar ist diese Institutionalisierung derzeit nicht vollständig.

Der Trend ist nicht explosionsartig positiv, aber stabil bis positiv. Verglichen mit dem Frühjahr 2026 wirkt die Lage weniger chaotisch, weil KUS/Akisame als erkennbare Achse hervortreten. Gleichzeitig bleiben Release-Transparenz und externe Quellen das Dauerthema.

Die Gesamtbewegung lautet: ↗ positiv stabilisiert. Nicht, weil alle Probleme gelöst wären, sondern weil die Community besser weiß, welche Linie aktuell zählt und welche alten Stände eher zu meiden sind.

Die Werte sind keine Messdaten, sondern eine redaktionelle Nutzwert- und Risikobewertung aus den öffentlich sichtbaren Signalen. Sie sollen Vergleichbarkeit schaffen, nicht mathematische Exaktheit vortäuschen.

Auffällig sind die hohen Werte bei Nutzerinteresse und Community-Support sowie die niedrigeren Werte bei Transparenz und Repository-Situation. Genau dort liegt die Schere des Projekts: praktisch lebendig, formal schwer auditierbar.

Entwicklung: 🟢 sichtbar aktiv. Funktion: 🟡 bis 🟢, weil externe Quellen stark mitentscheiden. Community: 🟢, weil DEB und VMOD aktiv wirken. Distribution: 🟡, weil KUS faktisch stark ist, aber öffentliche Nachvollziehbarkeit begrenzt bleibt.

Transparenz: 🟡 bis 🔴, weil ein aktueller öffentlicher Git-Upstream fehlt. Kompatibilität: 🟡, weil Kodi 19+ plausibel und Kodi 21 genutzt ist, Kodi 22 aber noch Vorabstatus hat. Zukunftssicherheit: 🟡 wegen Bus Factor und KUS-Abhängigkeit. Externe Abhängigkeiten: 🔴 als strukturelles Dauerproblem.

Gesamt: 🟡 BEOBACHTEN mit aktivem Kern. Aki-xStream ist nicht kritisch im Sinne von eingestellt, aber auch nicht grün im Sinne eines transparent institutionalisierten Projekts.

Seit dem früheren xStream-Lagebild vom 9. September 2026 ist vor allem eines hinzugekommen: die breitere, quellenbasierte Rekonstruktion der Rollen. Der neue Bericht trennt deutlicher zwischen historischer xStream-Webseite, Aki-/KUS-Linie, DEB/VMOD-Support und Mirror-Signalen.

Neue eindeutig belegte große Aki-xStream-Versionen seit dem vorherigen Bericht konnten nicht nachgewiesen werden. Neu sichtbar beziehungsweise stärker gewichtet sind aktuelle Akisame-Profilaktivitäten im September, die Bedeutung des Downloadfeature-Statements vom 31. August und die klare Einordnung, dass Mirror-Dateien wie Aki-xStream-2026.08.14.zip keine offizielle Release-Bestätigung ersetzen.

Keine relevante neue große Problemwelle ist öffentlich nachweisbar. Die Risiken bleiben dieselben, aber die Belege sind nun sauberer getrennt.

Aki-xStream ist heute aktiv und funktional relevant, aber organisatorisch fragmentiert und beobachtungsbedürftig. Es ist nicht praktisch eingestellt. Es ist auch nicht vollständig gesund im Sinne eines transparenten Open-Source-Projekts mit klarer Release-Governance.

Warum? Weil die aktuelle Linie öffentlich erkennbar gepflegt und diskutiert wird, die wichtigste Distribution aber über KUS/Community-Kontexte läuft und der aktuelle Code nicht als sauberer öffentlicher Upstream auditierbar ist. Nutzer sollten deshalb auf aktuelle, klar zuordenbare Quellen achten, alte Repos und anonyme Mirrors kritisch behandeln und Fehlerberichte immer nach Version, Kodi-Stand, Plattform, Quelle und Log einordnen.

Die interessanteste nächste Entwicklung wäre nicht noch ein weiterer Fix, sondern mehr Transparenz: ein öffentlicher Read-only-Upstream, signierte Releases, Changelogs, Hashes und eine kleine Maintainer-Dokumentation. Das würde aus einem praktisch lebendigen Projekt auch ein deutlich besser prüfbares Projekt machen.