Dubbele taken of imports in Jellyfin voorkomen

Voorkom dubbele Jellyfin-taken en imports door elke bewerking één planner, één schrijver, één bewaakt pad en één voltooiingssignaal te geven.

Worden scans, imports of metadatataken na een herstart, het opnieuw aanmaken van een container of een nieuwe automatisering gedupliceerd? Noteer de taaknaam, starttijd, container-ID, planner, bewaakte map en uitvoer voordat je iets uitschakelt. De veilige oplossing verwijdert overlappend beheer in plaats van een dubbele vermelding te verbergen.

Vind elke planner die hetzelfde werk kan starten

Controleer geplande Jellyfin-taken, hooks voor het herstarten van containers, cron- of systemd-timers op de host, nabewerking door downloadbeheerders en elke sidecar die de API aanroept. Vergelijk tijdstempels en proces-ID's van twee uitvoeringen. Als beide taken door dezelfde gebeurtenis starten, schakel dan de secundaire trigger uit en laat de primaire taak ongewijzigd.

Jellyfin-taken kunnen periodiek of handmatig worden uitgevoerd, en opstarttaken kunnen starten voordat een netwerkshare beschikbaar is (naslagwerk voor taakplanning). Behandel het gereed zijn van de koppeling als een vereiste in plaats van een tweede import toe te staan ter compensatie.

Controleer of de dubbele taak na het opstarten, een webhook of een handmatige nieuwe poging verschijnt. De trigger maakt duidelijk welke eigenaar moet worden uitgeschakeld; alle geplande taken uitschakelen verbergt de oorzaak zonder herhaling te voorkomen.

Geef elk pad één schrijver en één stabiele identiteit

Zorg dat slechts één downloader of importer bestanden naar de bibliotheek verplaatst en dat elke container hetzelfde canonieke pad ziet. Twee containers met verschillende toewijzingen kunnen hetzelfde bestand als twee identiteiten importeren. Vergelijk inode, checksum, pad en eigenaarschap van één dubbel paar voordat je iets verwijdert.

Als het bronbestand wordt hernoemd of opnieuw geformatteerd, kan Jellyfin een nieuw item zien in plaats van een update. Voer een gecontroleerde verplaatsing uit, scan één keer en controleer het verwachte aantal items voordat je de automatisering opnieuw inschakelt.

Vergelijk de labels en bewaakte paden van de actieve containers, niet alleen het configuratiebestand op schijf. Een oude container kan een verouderde watcher actief houden nadat een nieuwe implementatie is uitgevoerd.

Valideer preventie tijdens herstart en nieuwe pogingen

Start de stack opnieuw nadat je één trigger hebt gewijzigd en laat het geplande tijdvenster één keer plaatsvinden. Bevestig één proces, één importgebeurtenis, één databasewijziging en één definitief bestand. Herhaal daarna een mislukte of onderbroken uitvoering om te controleren of de nieuwe poging geen tweede exemplaar start.

Schaal op wanneer duplicaten blijven bestaan met één planner en één pad, de database tegenstrijdige identiteiten bevat of een plug-in taken steeds opnieuw aanmaakt. Bewaar de oorspronkelijke media en de databaseback-up totdat het opschonen en de preventietest zijn geslaagd.

Voer na het verwijderen van de secundaire schrijver één normale import en één onderbroken nieuwe poging uit. Het verwachte resultaat is één databasegebeurtenis en één definitief bestand voor elk bronitem.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bevestig de preventieregel na een herstart

Start de stack opnieuw en wacht één gepland tijdvenster af terwijl alleen de gekozen planner is ingeschakeld. Noteer het proces, het pad en de databasegebeurtenis, zodat de beheersgrens zichtbaar is.

Behoud de configuratie wanneer een nieuwe poging geen tweede import start en de bibliotheek één geldig item bevat. Schakel telkens één automatisering opnieuw in als een andere service nodig is.

Schaal op wanneer duplicaten terugkeren met één schrijver, wanneer de database tegenstrijdige identiteiten bevat of wanneer een plug-in uitgeschakelde taken opnieuw aanmaakt.