Hoe ontdekt en verwerkt Jellyfin wijzigingen op verschillende apparaten?

Jellyfin verzoent de meeste wijzigingen tussen apparaten via een centrale server, die bibliotheekupdates detecteert, de gedeelde status opslaat en de resulterende weergave aan clients aanbiedt.

Een telefoon, televisie, browser en tablet onderhandelen normaal gesproken niet rechtstreeks met elkaar over de waarheid van de mediabibliotheek. Ze communiceren met dezelfde Jellyfin-server, die de geïndexeerde bibliotheekmetadata en gebruikersspecifieke status, zoals de kijkvoortgang, beheert. Bestandsdetectie, updates van de afspeelstatus en het vernieuwen van clients zijn afzonderlijke fasen die op één serverautoriteit samenkomen. Apparaten zijn het daardoor meestal eens nadat de server de wijziging heeft geaccepteerd en elke client is vernieuwd.

De server is de gedeelde autoriteit, niet de afzonderlijke clients

Clients geven bibliotheekweergaven weer en sturen gebruikersacties, maar de blijvende gedeelde catalogus staat op de server. Dankzij deze architectuur kunnen een televisie en een telefoon hetzelfde item zien zonder de volledige database tussen apparaten te kopiëren. Elke client kan de weergavestatus cachen, maar de gezaghebbende registratie van bibliotheeklidmaatschap en gebruikersvoortgang blijft gecentraliseerd.

Een mediaserver is normaal gesproken de autoriteit voor wat daadwerkelijk beschikbaar is en wat door de lokale gebruikers ervan is afgespeeld. Een nuttig model van de bron van waarheid beschouwt de mediaserver voor afspelen als iets anders dan draagbare volgsystemen. Datzelfde uitgangspunt verklaart Jellyfin-clients: ze komen samen op basis van de serverstatus in plaats van onderling tussen apparaten een winnaar te kiezen.

Dit model vereenvoudigt het eigenaarschap van conflicten, omdat er één plek is waar geaccepteerde wijzigingen blijvend worden opgeslagen. Een client kan tijdelijk verouderde gecachte gegevens weergeven, maar wordt niet opeens een tweede gelijkwaardige database omdat hij nog niet is vernieuwd. Verzoening betekent dat de clientweergave terugkeert naar de door de server geaccepteerde status.

Wijzigingen in het bestandssysteem worden via serverdetectie bibliotheekstatus

Het toevoegen, vervangen, hernoemen of verwijderen van een mediabestand wijzigt eerst de opslag, niet de Jellyfin-catalogus. De server moet die gebeurtenis in het bestandssysteem detecteren via een scan, monitoringsignaal of automatisering, het betreffende pad controleren en de geïndexeerde weergave bijwerken. Pas na die opslag kunnen clients de nieuwe bibliotheekweergave ontvangen.

Gerichte automatiseringstools zoals gerichte bibliotheekupdates bestaan omdat detectie preciezer kan worden geactiveerd dan door te wachten op een brede geplande scan. Het architecturale punt blijft hetzelfde: een bestandsgebeurtenis wordt eerst een bibliotheekupdate op de server voordat het een UI-wijziging op meerdere apparaten wordt.

Hierdoor blijft er tijdens het detectievenster een onderscheid tussen de waarheid van de opslag en die van de catalogus. Een bestand kan op schijf bestaan terwijl clients het nog niet zien, of een geïndexeerd item kan kort blijven staan totdat de verwijdering is verwerkt. De tijd tussen een wijziging in het bestandssysteem en de update van de serverindex meten is daarom iets anders dan meten hoe snel een client vernieuwt nadat de server de wijziging al heeft opgeslagen.

Afspeelvoortgang keert terug naar dezelfde gebruikersstatus op de server

Kijkvoortgang volgt een ander invoerpad dan bestandsdetectie. Het mediabestand verandert niet wanneer een kijker minuut veertig bereikt; de client meldt de afspeelstatus die aan de geauthenticeerde gebruiker is gekoppeld, en de server registreert die gebruikersspecifieke update. Een ander apparaat dat met hetzelfde account is aangemeld, kan later de gedeelde serverstatus opvragen en vanaf de geaccepteerde positie hervatten.

Daarom kan Jellyfin kijkgeschiedenis tussen apparaten synchroniseren via verschillende clients zonder een lokaal voortgangsbestand rechtstreeks tussen de televisie en telefoon te kopiëren. Beide apparaten komen samen omdat ze via dezelfde gebruikersregistratie op de server lezen en schrijven, niet omdat ze onderling peer-to-peer verzoenen.

De waarneembare grens is het moment van schrijven. Als een apparaat offline gaat voordat de voortgangsupdate de server bereikt, kan een ander apparaat legitiem de oudere serverwaarde tonen. Zodra de verbinding terugkeert, hangt het eindresultaat af van welke update de toepassing accepteert en in welke volgorde. Lokale offlinevoortgang mag niet worden verward met een al opgeslagen gedeelde status.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Clients verzoenen door de server opnieuw te raadplegen, niet door met elkaar samen te voegen

Nadat de server een wijziging heeft opgeslagen, hebben clients nog steeds een vernieuwing, gebeurtenis, navigatieactie of volgend verzoek nodig om de nieuwe status op te halen. Een televisie kan een verouderd posterrooster in het geheugen houden terwijl een browser de update al toont. Die tijdelijke afwijking is een probleem met de presentatiecache, tenzij de server zelf tegenstrijdige registraties bevat.

De diversiteit aan clients maakt dit onderscheid zichtbaar, omdat verschillende Jellyfin-clients dezelfde server met verschillende interfaces en afspeelgedrag kunnen weergeven. Als één client verouderd lijkt terwijl een andere actueel is, controleer dan eerst de serverstatus en vernieuw of verbind de afwijkende client opnieuw voordat je de mismatch als een databaseconflict beschouwt.

Dit onderscheid is belangrijk bij het oplossen van problemen. Als twee clients het oneens zijn, vraag dan eerst de serverstatus op of inspecteer die. Als de server de verwachte waarde bevat en slechts één client verouderd is, zijn vernieuwings- of cachegedrag waarschijnlijk de oorzaak. Als de server de update zelf niet bevat, onderzoek dan detectie, rechten of de schrijfactie voordat je de tweede client de schuld geeft.

Foutgrens: afzonderlijke servers verzoenen hun databases niet automatisch

Het model met een centrale autoriteit geldt binnen één Jellyfin-serverinstantie. Als een huishouden twee onafhankelijke servers gebruikt, kan elke server eigen gebruikers, kijkstatus, metadatabewerkingen en wijzigingen in de bibliotheekdatabase opbouwen. Er is geen algemene aanname dat die databases elkaar ontdekken en veilig samenvoegen, alleen omdat ze naar vergelijkbare mediabestanden verwijzen.

Tools voor serversoverschrijdende synchronisatie, zoals expliciete synchronisatie van de kijkstatus, bestaan juist omdat onafhankelijke mediaservers een expliciet verzoeningsmechanisme nodig hebben voor gedeelde voortgang. Zo'n tool kan een gedefinieerde subset van de status synchroniseren; hij verandert twee volledige Jellyfin-databases niet in een transparant multi-mastercluster.

Dezelfde grens geldt voor offlineapparaten. Een client kan een verouderde lokale weergave bewaren, maar mag niet worden behandeld als een gezaghebbende database die handmatig met Jellyfin moet worden samengevoegd. Wanneer meerdere schrijvers of servers worden geïntroduceerd, bepaal dan welke status gezaghebbend is, welke velden worden gesynchroniseerd en hoe conflicterende updates worden opgelost voordat je het ontwerp “verzoend” noemt.

Voer een vierstappentest voor verzoening uit op twee apparaten

Gebruik twee clients die met dezelfde testgebruiker zijn aangemeld en één bekend media-item. Voeg eerst een testbestand toe of hernoem het en meet hoe lang de detectie door de server duurt. Controleer vervolgens of beide clients na het vernieuwen de nieuwe catalogusstatus ontvangen. Wijzig daarna de kijkvoortgang op client A en controleer of client B de door de server geaccepteerde waarde ontvangt. Start ten slotte de server opnieuw op en controleer of de opgeslagen status behouden blijft.

De interne uitleg van consistentie van gelijktijdige statusupdates biedt de aanvullende databasegrens: geaccepteerde schrijfbewerkingen hebben transactie- en ordeningsregels nodig, zodat overlappende activiteit geen half voltooide updates zichtbaar maakt. De test op meerdere apparaten voegt daar detectie- en vernieuwingsmomenten van clients aan toe, boven op die garantie van blijvende status.

De test is alleen geslaagd wanneer de server na elke stap dezelfde waarneembare autoriteit wordt: opslagwijzigingen worden één keer geïndexeerd, beide clients komen samen op hetzelfde bibliotheekresultaat, gebruikersvoortgang wordt niet gedupliceerd of verloren en een herstart maakt een opgeslagen update niet ongedaan. Als de apparaten het oneens blijven, bepaal dan of de fout ontstond bij detectie, het opslaan op de server, het vernieuwen van de client of de grens tussen afzonderlijke servers.

Veelgestelde vragen

Synchroniseren Jellyfin-clients rechtstreeks met elkaar?

Normaal gesproken niet. Een telefoon, televisie, browser en tablet komen via de Jellyfin-server samen: clients sturen updates naar de server en lezen later de serverstatus. Als je clients als peerkopieën beschouwt, lijken normale vernieuwingsvertragingen op conflicten die in werkelijkheid niet bestaan.

Waarom kan één Jellyfin-client verouderde bibliotheekgegevens tonen?

De server kan een bibliotheek- of afspeelwijziging al hebben opgeslagen terwijl één client nog een oudere gecachte weergave toont. Controleer de serverstatus via een andere client of de webinterface en vernieuw of verbind de afwijkende client opnieuw voordat je problemen met detectie of de database onderzoekt.

Kunnen twee afzonderlijke Jellyfin-servers de kijkvoortgang automatisch synchroniseren?

Afzonderlijke Jellyfin-servers vormen geen automatisch multi-masterstatussysteem. Als dezelfde gebruiker zijn kijkgeschiedenis tussen onafhankelijke servers moet meenemen, gebruik dan een expliciete synchronisatieworkflow met een vastgelegde bron van waarheid en test het gedrag bij conflicten voordat je erop vertrouwt.