Doorgaan naar hoofdinhoud
Onofficiële Beta-vertaling

Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →

Problemen melden

Op deze pagina leggen we uit hoe je issues kunt aanmaken, inclusief het beleid en de procedures van het Jellyfin-project voor het afhandelen van issues.

Issues mogen alleen softwarebugrapporten bevatten.

Alle andere discussies, inclusief eerste stappen bij probleemoplossing, moeten worden gericht aan onze helpkanalen.

Functieverzoeken indienen

Let op: functie- en verbeteringsverzoeken moeten worden ingediend via onze Fider-instance voor tracking, stemmen en rapportage. Houd alle functieverzoeken op deze pagina en plaats ze niet als GitHub-issues.

Zoeken en stemmen

Voordat je een issue opent, doorzoek de bestaande issues om te zien of een vergelijkbaar probleem of functieverzoek al is gemeld. Dubbele issues vervuilen de repository en moeten worden vermeden.

Als je een issue vindt dat overeenkomt of sterk lijkt op jouw probleem, gebruik dan de 👍-reactie om te bevestigen dat het issue ook jou treft of dat je het functieverzoek steunt. Voeg eventueel ook een reactie toe met jouw specifieke situatie of gebruiksscenario.

Als het bestaande issue gesloten is, lees dan door of de beschreven oplossing(en) voor jou werken. Zo niet, laat dan een reactie achter zodat we het issue heropenen. Let op: pull requests worden eerst in dev opgenomen, maar releases worden gebouwd vanuit master, dus een oplossing is niet direct beschikbaar in de officiële bronnen maar wordt meegenomen in de volgende release.

Een issue openen

Ben je klaar om een issue aan te maken? Bekijk dan deze pagina!

Bugs melden

Bij het melden van een bug is het belangrijk zoveel mogelijk relevante details te vermelden - dit is cruciaal voor onderzoek en oplossing. Denk aan:

  • Hoe je Jellyfin hebt geïnstalleerd (upgrade of nieuwe installatie)

  • Je platform en besturingssysteem (Debian, Arch, Docker, etc.)

  • Wat je aan het doen was toen het probleem optrad

  • Relevante loguitvoer

  • Eventuele aangepaste configuraties

Voeg [bug] toe aan het begin van de titel. Het Jellyfin-team verwijdert dit later bij het labelen. Voeg eventuele relevante labels toe na [bug] om triage te versnellen.

Bugs moeten reproduceerbaar zijn. Dat betekent dat je door probleemoplossing moet kunnen vaststellen hoe je het probleem kunt reproduceren. Hoewel eenmalige bugs niet genegeerd mogen worden, is het waarschijnlijk erg moeilijk om ze op te lossen als ze moeilijk of onmogelijk te reproduceren zijn. Probeer de bug te reproduceren voordat je een issue aanmaakt en neem de kleinste testcase op die je kunt bedenken om het aan te tonen.

Moet je hulp bij probleemoplossing of issue-aanmaak? Neem contact op met de community - we helpen je graag!

Issuelabels

Jellyfin gebruikt diverse labels voor triage en issuebeheer. Gebruikers kunnen deze zelf niet toewijzen vanwege GitHub-beperkingen, maar een teamlid voegt ze tijdens triage toe.

Categorieën

Deze labels geven aan welk deel van de codebase is getroffen:

  • backend: Issues die vooral de server-backendcode betreffen

  • build: Issues die vooral het bouwproces betreffen

Ernst

Deze labels helpen bepalen hoe kritiek een issue is.

  • regression: Een issue dat directe aandacht nodig heeft vanwege een regressie ten opzichte van de laatste build.

  • bug: Een bug in de code die normaal gebruik beïnvloedt.

Beheer

Deze labels helpen bij het beheren van het project en de richting.

  • good first issue: Iets dat zeer eenvoudig zou moeten zijn en een goede plek is om te beginnen.

  • help wanted: Een issue dat momenteel geen duidelijke expert binnen het project heeft en externe hulp kan gebruiken.

  • roadmap: Een meta-issue gerelateerd aan de toekomstige roadmap van het project.

  • investigation: Een issue van het type onderzoek in de codebase.

Pull Requests

Deze labels zijn alleen van toepassing op pull requests voor administratieve doeleinden.

  • requires testing: Een PR die nog niet in een live omgeving is getest. Elke grote backend-beïnvloedende PR moet worden getest voordat deze wordt samengevoegd om regressies te voorkomen.