Zum Inhalt springen

Informationsprobleme

Funktionen anfordern

Bitte beachten Sie, dass Funktions- und Erweiterungsanfragen zur Überwachung, Abstimmung und Berichterstellung an unsere Fider-Instanz gerichtet werden sollten. Bitte behalten Sie alle Funktionsanfragen auf dieser Seite und nicht auf GitHub.

Emissionsrichtlinien

Auf dieser Seite wird erläutert, wie Themen geöffnet werden, einschließlich der Richtlinien und Verfahren für das Jellyfin-Projekt zum Umgang mit Themen.

 Informationsprobleme Informationsprobleme

Probleme sollten nur detaillierte Software-Fehlerberichte.

Alle anderen Diskussionen, einschließlich der anfänglichen Fehlerbehebung, sollten an unsere Hilfekanäle gerichtet werden.

Suchen und abstimmen

Durchsuchen Sie vor dem Öffnen einer Nummer vorhandene Nummern, um festzustellen, ob ein ähnliches Funktionsproblem oder eine ähnliche Anforderung gemeldet wurde. Doppelte Probleme bringen die Kaution durcheinander und sollten vermieden werden.

Wenn Sie ein Problem finden, das Ihrem Problem entspricht oder sich diesem nähert, verwenden Sie das Feedback, um zu bestätigen, dass das Problem auch Sie betrifft oder dass Sie die Funktionsanforderung unterstützen. Fügen Sie optional auch einen Kommentar hinzu, der Ihre Version des Problems oder den Anwendungsfall der Funktion beschreibt.

Wenn das vorhandene Thema geschlossen ist, lesen Sie es bitte, um festzustellen, ob die akzeptierten Lösungen für Sie zutreffen. Wenn nicht, hinterlassen Sie einen Kommentar und das Thema wird erneut geöffnet. Bitte beachten Sie, dass die Öffentlichkeitsarbeit an erster Stelle in der Entwicklung steht, die Releases jedoch vom Master erstellt werden. Eine Problemlösung wird nicht sofort aus offiziellen Quellen verfügbar sein, sondern in der nächsten Release enthalten sein.

Öffne eine Nummer

Wenn Sie bereit sind, eine Nummer zu öffnen, lesen Sie bitte diese Seite!

Fehler melden

Achten Sie beim Schreiben eines Problems darauf, möglichst viele relevante Details zu erfassen. Dies ist sehr wichtig, um die Fehlerbehebung und Nachverfolgung / Untersuchung des Problems zu erleichtern. Einige nützliche Elemente sind:

  • Wie haben Sie Jellyfin installiert (Upgrade / Neuinstallation)
  • Welche Plattform und welches Betriebssystem verwenden Sie (Debian, Arch, Docker usw.)
  • Was Sie getan haben, hat dazu geführt, dass das Problem aufgetreten ist
  • Alle relevanten Protokollausgaben
  • Jede nicht standardmäßige Konfiguration, die Sie verwenden

Fehler sollten am Anfang ihres Titels mit [Fehler] gekennzeichnet werden. Dies wird später vom Jellyfin-Team durch Zuweisen der Tags entfernt. Wenn Sie wissen, welche anderen Tags auf Ihr Problem angewendet werden sollen, fügen Sie diese nach dem [bug] -Tag hinzu, um die Triage zu unterstützen.

Die Fehler müssen reproduzierbar sein. Das heißt, Sie sollten in der Lage sein, durch Fehlerbehebung zu bestimmen, wie das Problem repliziert werden soll. Obwohl die einmaligen Fehler nicht ignoriert werden sollten, ist es wahrscheinlich sehr schwierig, sie zu beheben, wenn sie schwer oder unmöglich zu reproduzieren sind. Bitte versuchen Sie, den Fehler zu reproduzieren, bevor Sie das Problem darstellen, und geben Sie den kleinsten Testfall an, den Sie zur Demonstration verwenden können.

Wenn Sie jemals Hilfe beim Lösen von Problemen oder beim Öffnen eines Themas benötigen, wenden Sie sich bitte an die Community. Wir werden versuchen, Ihnen zu helfen!

Emissionsetiketten

Jellyfin bietet eine Reihe von Issue-Labels zur Unterstützung der Triage und des Issue-Managements. Benutzer können sie aufgrund von GitHub-Berechtigungen nicht selbst zuweisen, sie werden jedoch während der Triage von einem Teammitglied hinzugefügt.

Kategorien

Diese Tags sind breite Kategorien, für die ein Teil der Codebasis betroffen ist.

  • ... von hinten: Ein Problem, das sich hauptsächlich auf den Server-Backend-Code bezieht.
  • Build: Ein Problem, das sich hauptsächlich auf den Bauprozess bezieht.

Kritik

Mithilfe dieser Beschriftungen können Sie feststellen, wie kritisch ein Problem ist.

  • Regression: Ein Problem, das aufgrund einer Regression aus dem letzten Build sofort behandelt werden muss.
  • ... ein Fehler: Ein Fehler im Code, der sich auf die normale Verwendung auswirkt.

Management

Diese Beschriftungen helfen bei der Verwaltung des Projekts und der Richtung.

  • Eine gute erste Ausgabe: Etwas, das sehr einfach zu tun sein sollte und ein guter Anfang ist.
  • Hilfe gesucht: Ein Problem, das derzeit keinen eindeutigen Experten innerhalb des Projekts hat und Hilfe von außen benötigen könnte.
  • Roadmap: Ein Meta-Thema, das sich auf die zukünftige Roadmap des Projekts bezieht.
  • Untersuchung: Eine Untersuchung, die auf Code basiert.

Extraktionsanfragen

Diese Bezeichnungen gelten nur für Pull-Anforderungen zu Verwaltungszwecken.

  • erfordert Tests: Eine PR, die noch nicht in einer Live-Umgebung getestet wurde. Alle PRs, die sich auf den Fonds auswirken, müssen vor dem Zusammenschluss getestet werden, um Regressionen zu vermeiden.

de_DEDeutsch
es_ESEspañol zh_CN简体中文 hi_INहिन्दी arالعربية pt_BRPortuguês do Brasil bn_BDবাংলা ru_RUРусский ja日本語 fr_FRFrançais it_ITItaliano de_DEDeutsch