Probleemoplossing

Het dashboard is groen, maar geen enkele televisie ontvangt iets

Elke zender staat op draaiend. De bitratewaarden zien er aannemelijk uit. Geen enkele televisie heeft beeld. Dit is met afstand de meest voorkomende storing bij een nieuwe installatie, en het is bijna altijd de multicastroute.

Waarschijnlijke oorzaak

De route voor multicastverkeer wijst naar de verkeerde netwerkinterface, of naar een interface zonder carrier — niets aangesloten, of aangesloten op een dode poort. De pakketten worden correct gemaakt en afgegeven aan een interface die nergens heen leidt.

De uitgaande socket aan een bronadres binden lost het niet op. De kernel raadpleegt nog steeds de routeringstabel om de uitgaande interface te kiezen; het bronadres bepaalt alleen wat er in de pakketheader staat.

Zo bevestigt u het

Twee opdrachten op het apparaat. Vraag de kernel waar een datagram voor de groep van de zender werkelijk heen zou gaan, en kijk daarna welke interfaces een carrier hebben:

# Substitute the destination group of an affected channel
ip route get 239.10.0.1

# Which interfaces are actually up, and which are merely configured
ip -brief link

De eerste opdracht noemt de interface die zal worden gebruikt. Is dat niet de interface die naar de televisies wijst, dan hebt u de storing gevonden. Is het wel de juiste interface, maar toont ip -brief link die interface als DOWN of zonder carrier, dan hebt u de storing ook gevonden.

Oplossing

Laat het hele multicastbereik naar de interface richting de televisies wijzen, en zorg dat de wijziging een herstart overleeft — een met de hand getypte ip route-opdracht gaat verloren bij de volgende herstart van het apparaat, en zo keert deze storing weken later terug zonder dat iemand zich de eerste keer herinnert. Installatie beschrijft de meegeleverde routeringsunit, die de route periodiek opnieuw beoordeelt zodat die de kabel volgt als de verbinding verhuist.

Castmux controleert de routeringstabel van buiten het proces en meldt een bestemming als onrouteerbaar wanneer dat zo is. Het herstart de zender in die situatie bewust niet: een herstart kan een routeringsfout niet oplossen, en een herstartlus zou de ene logregel die de echte oorzaak noemt begraven. Zie Monitoring.

Blokvorming en haperingen op één zender

Het beeld valt uiteen in blokken, of bevriest en verspringt, op één zender terwijl andere goed zijn.

Meest waarschijnlijk: twee zenders op dezelfde groep

Twee processen die naar dezelfde multicastbestemming verzenden. De televisies ontvangen beide streams door elkaar, en het resultaat is voortdurende corruptie. Meestal komt dit door een migratie: een oudere service van een vorige installatie die nog draait, of een systeemunit die uitgeschakeld maar niet gestopt is, naast de nieuwe installatie. Beide zenders zien er vanuit hun eigen oogpunt volkomen gezond uit, omdat elk een geldige stream levert.

Bevestig het met de alert voor dubbele zenders, die wordt gegeven wanneer Castmux verkeer naar een van zijn bestemmingen waarneemt dat het niet zelf heeft verzonden, en door op het apparaat en op het netwerk te zoeken naar een ander proces dat naar dezelfde groep en poort verzendt. Los het op door de oudere zender goed te stoppen — een unit uitschakelen houdt niet tegen dat iets anders hem start, dus controleer ook geplande taken.

Overweeg ook

Verlies aan de bronzijde. De originserver levert een beschadigde stream en u stuurt die getrouw door. Om dit eerlijk te zien, laat u de zender op de pass-through-engine draaien: die behoudt de oorspronkelijke continuity counters, zodat analyse verderop in de keten het verlies toont. De remux-engine stempelt de continuity counters opnieuw, waardoor de uitvoer structureel schoon lijkt en verborgen blijft waar de schade vandaan kwam. Zie Streaming-engines.
Een overvolle multiplex, als de zender via DVB-C wordt meegestuurd. Overschrijdt de gezamenlijke bitrate van de services wat de draaggolf kan dragen, dan gaat alles in die multiplex achteruit, niet alleen de zender waarover iemand heeft geklaagd. Zie DVB-C-multiplexing.
Switches zonder IGMP-snooping. Zonder snooping wordt elke multicaststream naar elke poort gestuurd. Een tiental zenders komt dan aan bij elke televisie en bij elk ander apparaat op het segment, en de toegangspoorten raken verzadigd. Het symptoom is meestal blokvorming op veel zenders tegelijk, die erger wordt naarmate u zenders toevoegt.

Een zender herstart herhaaldelijk

De uptime komt nooit boven een minuut of twee. Begin met het log van die zender in de interface: de reden van elke herstart wordt vastgelegd, en daarmee zijn de meeste oorzaken hieronder zonder verder onderzoek te onderscheiden.

Bron onbereikbaar of wisselend beschikbaar

De originserver verbreekt de verbinding, of is maar soms beschikbaar. Castmux wacht steeds langer tussen pogingen in plaats van de server te bestoken, en die backoff wordt gereset na een aanhoudend gezonde periode. Controleer de originserver voordat u iets op het apparaat verandert.

De originserver publiceert een IPv6-adres dat het apparaat niet kan bereiken

Zeer gebruikelijk, zelden vermoed. Zie Alles start traag hieronder — het veroorzaakt beide symptomen.

SRT-latency te laag ingesteld

De ingestelde latency moet de round-trip time van de verbinding dekken, met ruimte voor hertransmissie. Is die te laag, dan mislukt het herstel en valt de sessie steeds weg.

Een watchdog gebaseerd op een meetwaarde die voor de engine niet bestaat

Externe monitoring die alarmeert op frames per seconde of afspeelsnelheid, herstart gezonde pass-through-zenders eindeloos, omdat die meetwaarden voor die engine niet bestaan. Zie de waarschuwing in Monitoring.

Een overbelaste uplink bij het opstarten

Starten alle zenders tegelijk, dan opent elk tegelijk zijn verbinding met de originserver en kan de uplink ze niet allemaal bedienen; meerdere krijgen een time-out, herstarten en proberen het weer samen. De gespreide start bestaat precies om dit te voorkomen. Is die verkleind of uitgeschakeld, zet hem dan terug.

Een zender start helemaal niet

Controleer deze punten op volgorde. De lijst is geordend naar hoe vaak elk punt het antwoord blijkt te zijn, niet naar hoe interessant het is.

Is de zender actief? Een gedeactiveerde zender wordt helemaal niet ingepland.
Is hij on-demand zonder kijkers? Dit is het meest voorkomende valse alarm op deze pagina. Een on-demand-zender waar niemand naar kijkt, hoort juist niet te draaien. Bevestig het door de preview te openen; die telt als kijker en start de zender. Zie On-demand streaming.
Is de bron bereikbaar vanaf het apparaat? Niet vanaf uw laptop — vanaf het apparaat. Andere DNS, andere routering, andere firewallregels, mogelijk een ander VLAN. Een bron die perfect speelt in VLC op uw machine vertelt u dat de originserver leeft, en niets over of het apparaat hem kan bereiken.
Wordt de bestemming al door een andere zender gebruikt? Twee zenders met dezelfde groep en poort zijn dezelfde storing met dubbele zenders als hierboven, maar lokaal veroorzaakt.
Kon de zender bij DVB-C worden geprobed? Een service die niet kon worden geprobed, kan niet aan een multiplex worden toegewezen. Zie DVB-C-multiplexing.

Alles start traag en ophaalacties duren seconden

Zenders doen onredelijk lang over het opstarten, het ophalen van playlists duurt seconden, en de traagheid is wisselend — soms is hetzelfde verzoek snel.

Oorzaak

De originserver publiceert een IPv6-AAAA-record en het apparaat heeft geen werkende IPv6-route. Adresselectie geeft de voorkeur aan IPv6, dus elk HTTP-verzoek probeert eerst IPv6 en valt pas daarna terug op IPv4. Wat die terugval kost, hangt volledig af van hoe de IPv6-poging mislukt:

Hoe de IPv6-poging mislukt	Kosten per verzoek
Directe weigering	Een paar honderd milliseconden. Vervelend, overleefbaar.
Route naar een blackhole	Een volledige connect-time-out, zonder iets wat die eerder afbreekt. Hier komen haperingen van meerdere seconden vandaan.

Betaald bij elk verzoek om een playlist en elk verzoek om een segment, is dit genoeg om een zender zijn timing te laten missen en te laten herstarten. In één geval leidde het tot een zender die op één dag 765 keer herstartte.

Oplossing

Stel het apparaat zo in dat adresselectie IPv4 verkiest boven IPv6. Doe dat op beide plaatsen: op de host en in de container, die een eigen kopie van het adresselectiebeleid heeft. Past u alleen de host aan, dan blijft het streamingproces — het proces dat de verzoeken doet — ongewijzigd en verandert het symptoom helemaal niet, wat meestal wordt opgevat alsof de diagnose fout was.

De zender speelt, maar er is geen geluid of de verkeerde taal

Het beeld is goed, maar audio ontbreekt, of er is maar één taal beschikbaar terwijl de bron er meerdere bevat. Drie verschillende oorzaken:

De remux-engine stuurt één audiospoor door. Zijn standaard streamselectie neemt één video- en één audiostream en laat de rest vallen. Heeft de locatie meerdere talen nodig, laat de zender dan op de pass-through-engine draaien, die elke audio-PID meeneemt samen met de oorspronkelijke programmatabel en de taaldescriptors, zodat de televisie de keuze kan aanbieden. Zie Streaming-engines.
Een gedemuxte HLS-ladder. Publiceert de originserver audio als aparte renditions in plaats van gemuxt in de videovarianten, dan zou het kiezen van één videovariant stille video in de lucht brengen. De beveiliging van het resolutieprofiel detecteert dit en houdt juist daarom de master-URL aan, en meldt dat op de zender. Hebt u de bron-URL met de hand overschreven zodat die naar een videovariant van zo’n ladder wijst, dan is dat waar de audio is gebleven. Zie Resolutieprofielen.
De bron heeft echt maar één spoor. Geen enkele engine-instelling maakt een audiospoor aan dat de invoer niet bevat. Controleer dit bij de originserver voordat u iets anders onderzoekt.

Een schakelaar in de interface spreekt de badge ernaast tegen

Een schakelaar toont de ene status, terwijl de status ernaast, op basis van dezelfde onderliggende waarde, de andere toont.

Dit is browsergedrag, geen applicatiestatus. Bij een gewone herlaadactie of bij teruggaan in de geschiedenis zetten browsers formulierelementen terug in hun vorige toestand, en negeren ze de status die de server in de pagina heeft meegestuurd. De badge is gewone tekst en volgt de server; de schakelaar is een formulierelement en volgt het geheugen van uw browser van de vorige pagina.

Forceer een harde herlaadactie en de twee komen overeen. Dat dit bij een product als dit überhaupt voorkomt, komt doordat zender-id’s na verwijdering worden hergebruikt: maak een zender aan, verwijder hem, maak een andere aan, en de nieuwe krijgt de oude id — waarna de browser vrolijk de schakelaar van de verwijderde zender op zijn vervanger terugzet.

Televisies zijn hun zendernummers kwijt na een wijziging van de zenderlijst

Bij DVB-C slaan televisies zenders op aan de hand van de service-identiteiten in de multiplex. Een andere volgorde van de slots verandert die identiteiten, dus de televisies herkennen niet meer wat ze hadden opgeslagen en moeten opnieuw worden afgestemd — in het hele gebouw, en dat is precies het klusje waar niemand op zit te wachten.

Zolang de service-identiteit niet los van de slotvolgorde kan worden vastgelegd roadmap, vermijdt u het herschikken van een multiplex die in de lucht is. Voeg nieuwe services achteraan toe in plaats van ze tussen te voegen, en leg de volgorde vast voordat het apparatenpark wordt afgestemd, niet erna. Zie DVB-C-multiplexing.

Wat u naar support stuurt

Met het volgende wordt een uitwisseling van dagen één enkel antwoord. Verzamel het voordat u het bericht schrijft, niet pas als erom wordt gevraagd.

De zendernaam, de bron-URL en de bestemmingsgroep en -poort.
Het log van die zender, uit de interface.
De uitvoer van ip route get <group> voor de getroffen bestemming.
De uitvoer van ip -brief link.
Het configuratiebestand, met de inloggegevens verwijderd.
Of de storing één zender treft of alle — alleen dit al onderscheidt een bronprobleem van een netwerkprobleem.
Of er iets op het netwerk is veranderd. Een switch vervangen, een VLAN gewijzigd, een kabel verplaatst, een firmware-update. Het antwoord is vaker ja dan mensen verwachten.