Da sendingen hakket midt i en direktesending: Idas sak

Problemet som kom midt i sendingen

Ida deltok på kurset i høst, og jeg husker saken godt fordi den begynte så vanlig. Hun sendte små lokale arrangementer fra en stue som var gjort om til studio, og i den tredje sendingen begynte bildet å hakke etter tjue minutter. Lyden falt ut i korte glimt, og seerne skrev i chatten at de ble sittende og vente.

Hun skrev til meg dagen etter og var ærlig om det hun hadde gjort: skrudd opp bitraten, startet programmet på nytt og håpet at det gikk over. Ingenting av dette var galt i seg selv, men hun hadde ikke notert hva hun endret, og dermed visste hun heller ikke hva som hadde virket eller ikke.

Det er et mønster jeg ser ofte når noen øver på feilsøking for første gang. Man handler raskt fordi sendingen pågår, og mister oversikten. Derfor begynte vi med å rekonstruere forløpet i ro, med et ark og tidspunktene hun husket.

Å finne årsaken ved å dele opp kjeden

Vi gikk gjennom kjeden fra kamera til seer, ett ledd om gangen. Først kameraet og kabelen inn til datamaskinen, deretter enkoderen, så nettverket ut av huset og til slutt plattformen. Poenget er å stille ett spørsmål per ledd: viser dette leddet tegn til trøbbel akkurat da bildet hakket?

Idas maskin lå på lavt forbruk hele tiden, så enkoderen var neppe synderen. Hun hadde derimot en logg fra enkoderen med tall for droppede bilder, og de hoppet opp i samme minutt som lydtapet. Det pekte mot nettverket, ikke mot oppsettet hun hadde brukt tid på å justere.

Jeg ba henne gjøre en enkel test: kjøre en opplastingsmåling tre ganger i løpet av en kveld, med noen timers mellomrom. Resultatene varierte mer enn hun hadde ventet, og det ga oss en første konkret mistanke å gå videre med.

• Del kjeden i ledd og vurder ett om gangen
• Skriv ned tidspunkt for hver hendelse
• Endre én ting av gangen, og noter hva du endret

Det som lå skjult i hjemmenettet

Ida brukte trådløst nett fra et rom to vegger unna ruteren, og det viste seg at flere i huset strømmet video samtidig i det tidsrommet hun sendte. Opplastingen hennes var nominelt god nok, men den svingte kraftig når andre enheter tok kapasitet. Det er en vanlig årsak til at sendinger starter fint og forverres etter en stund.

Vi fant ikke dette ved å gjette. Overvåkingen av pakketap i en testsending viste at tapet kom i bølger, og at det sammenfalt med at en annen enhet begynte å laste opp. Da ble forklaringen ganske enkel å forstå, og hun trengte ikke å kjøpe noe nytt for å se den.

Jeg understreker at dette var hennes hus og hennes forhold. Hos en annen kan samme symptom komme fra en overbelastet bytte, en dårlig kabel eller en plattform som er treg. Metoden er det som overføres, ikke konklusjonen.

Små grep som ga en roligere sending

Ida la en nettverkskabel direkte til ruteren og valgte en bitrate godt under det hun målte som laveste opplasting. Som utgangspunkt å teste, ikke som fasit: hun sendte en testsending på en halvtime og så at droppede bilder holdt seg nær null. Så økte hun forsiktig til hun fant et nivå hun var komfortabel med.

Hun ba også familien vente med store opplastinger mens hun sendte, og skrev det inn på sjekklisten sin. Det virker banalt, men en avtale i huset kan være like effektiv som utstyr. Sjekklisten fikk også et punkt om å starte overvåkingen før sendingen, ikke etter at problemene viser seg.

Til slutt førte hun alle innstillingene inn i tabellen vi bruker i kurset, med dato, bitrate, oppløsning og resultat. Neste gang noe endret seg, kunne hun se det svart på hvitt og slippe å huske.

• Kablet forbindelse der det er mulig
• Bitrate godt under målt laveste opplasting
• Avtale om hva andre i huset gjør under sending

Reserveløsningen hun aldri hadde tenkt på

Den delen jeg synes er mest verdt å fortelle om, kom litt senere. Ida hadde fortsatt ikke en plan for hva hun skulle gjøre hvis kabelen sviktet midt i en sending. Vi satte opp en enkel reserve: mobildeling som kunne tas i bruk i løpet av noen minutter, med en lavere bitrate og en forhåndsvalgt, enklere profil i enkoderen.

Hun øvde på overgangen i en testsending. Første forsøk tok nesten fire minutter, fordi hun lette etter innstillingene. Etter at hun hadde samlet alt på ett sted og skrevet trinnene ned, gikk det på under to. Det er forskjellen på å ha en reserve og å ha en reserve man faktisk klarer å bruke under press.

Jeg kan ikke love at en reserve alltid holder, mobildekning varierer og kostnader for data er en egen vurdering. Men en øvd reserve er bedre enn en antatt.

Hva jeg tar med meg fra Idas sak

Det som slår meg hver gang, er at feilsøking handler mer om rekkefølge enn om teknikk. Ida kunne mer enn hun trodde, men hun manglet en måte å gå fram på som ikke ble forstyrret av stresset i sendingen. Å dele kjeden i ledd, notere endringer og teste i ro hjalp henne mer enn noen enkeltinnstilling.

Hun sendte flere arrangementer utover høsten, og jeg vet at ikke alt gikk perfekt. En gang falt lyden ut igjen, men denne gangen visste hun hvor hun skulle lete, og bildet kom tilbake etter kort tid. Det er den typen realistisk framgang jeg synes er verdt å sikte mot.

Feilsøking under sending blir lettere når du har øvd i ro og skrevet ned hva du gjør. Idas sak viser at årsaken ofte ligger utenfor enkoderen, og at en reserveløsning du har prøvd, er mer verdt enn en du bare har tenkt på. Bruk tallene som utgangspunkt å teste, ikke som fasit, og sjekk alltid plattformens egen dokumentasjon for krav som gjelder akkurat der du sender.