Det viste sig at de flere steder brugte OR i deres WHERE clauses. Hvilket var det første problem.
Mens en OR i en SELECT eller CASE clause ikke er noget stort problem, er det generelt ikke en god idé at have OR i din WHERE clause. Dette fordi en OR resulterer i at der laves et fuldt tablescan.

Lad os prøve at se på det konkrete eksempel jeg havde ude hos kunden, for at se hvordan vi kan gøre det bedre.

Nedenstående rå SQL query tager mig over 30 sekunder at eksekvere på min database gennem SQL Server Management Studio (SSMS):

SELECT *
FROM GetCustomerPurchases_View
WHERE (
         CardIdentification IN ('ABC', 'DEF', 'JKL', 'ASD')
         OR CustomerId = 123
      )
      AND PurchaseTime > '2021-11-17 00:00:00'
      AND CardIdentification IS NOT NULL

Ændrer jeg koden til at bruge UNION i stedet for OR, vil den resulterende SQL query komme til at se således ud:

SELECT *
FROM GetCustomerPurchases_View
WHERE CardIdentification IN ('ABC', 'DEF', 'JKL', 'ASD')
      AND PurchaseTime > '2021-11-17 00:00:00'
UNION
SELECT *
FROM GetCustomerPurchases_View
WHERE CustomerId = 123
      AND PurchaseTime > '2021-11-17 00:00:00'
      AND CardIdentification IS NOT NULL

Når jeg har lavet query om til at bruge UNION i stedet for OR, tager det mig under et sekund at eksekvere min query, og jeg får det samme datasæt tilbage.

Hvorfor er querien med UNION hurtigere end OR?

Som nævnt tidligere, resulterer en OR i vores WHERE clause, at der bliver lavet et fuldt tablescan. Men med UNION får SQL Server i stedet lov til at lave en eksekutionplan hvor den vælger den optimale strategi for de enkelte subqueries, inden der bliver lavet UNION på datasættene fra vores subqueries. Dette kan resultere i nogle meget hurtigere subqueries, og af hvad jeg har erfaret, er det konsekvent hurtigere end et fuldt tablescan.

Da kunden kører med EntityFramework skulle vi have implenteret vores query som

At få det implementeret i rå SQL som LINQ var dog straks sværere.

Et intuitivt første forsøg ville være at gøre som herunder, hvor vi blot omskriver vores SQL query til LINQ:

var listWithCustomerPurchases = context.GetCustomerPurchases_View
   .Where(x =>
      cardIdentificationList.Contains(x.CardIdentification)
      && x.PurchaseTime >= cutOffDate)
   .Union(
      context.GetCustomerPurchases_View
      .Where(x =>
         x.CustomerId == Customer_Id 
         && x.PurchaseTime >= cutOffDate
         && x.CardIdentification != null)
      )
   .ToList();

Men i det konkrete eksempel ude hos kunden, resulterede det i at vi nu stadig fik et uønsket OR i vores SQL statement fra LINQ:

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE (
   ([Extent1].[CustomerId] = @p__linq__0) 
   OR (([Extent1].[CustomerId] IS NULL) AND (@p__linq__0 IS NULL))
) 
AND ([Extent1].[PurchaseTime] >= @p__linq__1) 
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=13213;@p__linq__1=65465

Dette uønskede OR kom fra at LINQ kunne se at vores Customer_Id kunne være NULL.

Så, for at fjerne vores uønskede OR, skal vi sikre os at Customer_Id ikke kan være NULL. Ude hos kudnen gjorde vi det helt konkret ved at tjekke for om Customer_Id er NULL, og hvis ikke, tage value fra denne over i en variable som ikke er nullable.

Denne løsning ses implementeret herunder

var query = context.GetCustomerPurchases_View
   .Where(x =>
      cardIdentificationList.Contains(x.CardIdentification)
      && x.PurchaseTime >= cutOffDate);

if(Customer_Id .HasValue){
   var customerIdLong = Customer_Id.Value;

   var queryWithCustomerIds = context.GetCustomerPurchases_View
      .Where(x =>
         x.CustomerId== customerIdLong 
         && x.PurchaseTime >= cutOffDate
         && x.CardIdentification != null);
      )
   query = query.Union(queryWithCustomerIds);
}

var listWithCustomerPurchases = query.ToList();

Nu hvor jeg kun laver union når jeg ved at Customer_Id ikke er null, kommer den resulterende SQL til at se ud om vi ønsker den.

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE ([Extent1].[CustomerId] = @p__linq__0) 
AND ([Extent1].[PurchaseTime] >= @p__linq__1) 
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=13213;@p__linq__1=65465

Det har også den øgede bonus at querien er endnu hurtigere hvis Customer_Id rent faktisk er NULL, da der så er lidt mindre at checke for vores WHERE clause.

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE ([Extent1].[PurchaseTime] >= @p__linq__0)
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=65465

Alt efter hvilken Raspberry Pi enhed der bliver brugt som hjernen her, skal man ikke forvente de store hastigheder. Jeg forsøgte mig med den første Raspberry Pi som udkom i 2011, og den kunne kun levere hastigheder på 5MB/s (40Mbit). Det er ikke overvældende hastigheder, men det er nok til fx et musikbibliotek for dit Sonos system.

Til gengæld bruger denne løsning ikke meget strøm. Jeg har målt mellem 8 & 10 watt alt efter hvor meget trafik der var på netværksdrevet, hvilket må siges at være meget billigt i strøm, under 90kWh om året. Det er ikke mange basører når det bliver omregnet til kroner og ører

Jeg har lænet mig meget op ad guiden fra PCMag: https://www.pcmag.com/how-to/how-to-turn-a-raspberry-pi-into-a-nas-for-whole-home-file-sharing, så vil du have en mere visuel gennemgang kan deres guide anbefales.

Det skal dog siges at jeg i denne gennemgang er meget liberal med sikkerhed og skriverettigheder. Så hav det i mente hvis du ikke er villig til at lukke netværksdrevet fuldt op for alt og alle på dit lokale netværk.

Jeg vil antage at du har installeret den seneste version af Raspberry Pi OS, og har opdateret den. Hvis ikke du har en Raspberry Pi klar kan guiden fra PCMag anbefales, til at komme i gang. Opdatering af din Raspberry Pi kan hurtigt klares med følgende kommando som vil tjekke for opdateringer, og derefter laver en fuld opgradering med apt full-upgrade.

sudo apt update && sudo apt full-upgrade -yf

apt update and upgrade

Hvis du ønsker automatisk at holde din Raspberry Pi opdateret kan du opsætte et cronjob som gør dette for dig. Naviger først ind i din crontab:

sudo crontab -e

Og tilføj derefter følgende i bunden:

0 3 * * * sudo apt update && sudo apt full-upgrade -yf
0 5 * * * sudo apt -y --purge autoremove
5 5 * * * sudo apt autoremove

Crontab auto update and upgrade

Dette opretter cronjobs der:

• Kører dagligt på faste intervaller
• Opdaterer alting kl. 3
• Rydder op i gamle filer kl. 5

I forhold til montering af harddisk er der mange måder at gøre det på. Har du en helt normal ekstern harddisk er det bare at slutte den til en af USB-portene på din Raspberry Pi. Har du en 3.5″ aflagt “lille” mekanisk harddisk skal du have fat i en USB -> Sata adapter. Personligt bruger jeg den fra LogiLink, og den virker helt fint. Det vigtigste er at den får strøm andenstedsfra end fra USBen på din raspberry Pi. Min Raspberry kunne i hvert fald ikke levere strøm nok til en mekanisk harddisk.

Når din disk er koblet til din Raspberry Pi og du kan se den med

sudo fdisk -l

er det på tide at få den unmounted, formateret, og partitioneret. Her vil jeg igen anbefale guiden fra PCMag, der er ingen grund til at gentage hvad de allerede fint gennemgår hos dem.

Med det ude af vejen, er det tid til at lave en mappe i linux som vi senere kan mounte vores usb harddisk til. Det er denne mappe vi senere kommer til at udstille gennem Samba. Jeg har valgt at oprette min mappe under /mnt/usb/

sudo mkdir /mnt/usb/

Herefter har jeg rekursivt sat chmod til 777 så jeg er sikker på at alle har skriveadgang til mappen. Ellers får vi potentielt problemer senere når vi vil overfører data til vores netværksdrev. 

sudo chmod -R 777 /mnt/usb/

At mounte disken til vores nyoprettede mappe er forholdsvis nemt da det blot er en enkelt kommando:

sudo mount /dev/sda1 /mnt/usb

Men, dette er en engangsting. Hvis du nogensinde genstarter din Raspberry Pi, er denne konfiguration ikke gemt, og kommandoen skal manuelt køres igen. Denne slags manuelle vedligehold er ikke ligefrem ønskværdigt.

Med lidt hjælp fra DevConnected (https://devconnected.com/how-to-mount-and-unmount-drives-on-linux/) fandt jeg frem til fstab som kan automatisere dette for os fremadrettet.

Der er flere måder hvorpå man kan identificere de diske man ønsker at mounte. Mange ynder at bruge det unikke UUID for disken, men da jeg er sikker på at min disk engang dør, og ikke ønsker at skulle opdatere UUID hver gang jeg skifter harddisken ud, har jeg valgt blot at pege på den første enhed vi finder under dev. Nemlig sda1. Denne tilgang er ikke nødvendigvis favorabel for dig hvis du har flere diske eller USB-enheder tilkoblet, men i mit scenarie er det helt perfekt.

Først navigerer vi ind i fstab med nano

sudo nano /etc/fstab

Og derefter tilføjer vi følgende linje der fortæller hvilken disk vi ønsker at mounte, hvor den skal mountes, hvilket filsystem der skal bruges samt hvilke defaults der skal bruges.

/dev/sda1 /mnt/usb ext4 defaults,nofail 0 0

Når dette er gjort, dobbelttjek da at din nye konfiguration virker med kommandoen 

sudo mount -a

Hvis du får fejlmeddelelser her, er det noget du bør undersøge inden du genstarter din Raspberry Pi. Ellers risikerer du at din Raspberry Pi ikke vil starte igen. Det oplevede jeg desværre et par gange.

For at vi kan få vores disk vist som et netværksdrev, skal vi have installeret Samba på vores raspberry pi, da det er denne protokol vi bruger til at udstille disken.

sudo apt install samba samba-common

Nu hvor vi har klargjort disken, og installeret Samba, er vi klar til at konfigurere Samba, så vi får styret hvordan vi vil have vist vores netværksdrev.

I konfigurationen for samba har jeg navigeret til bunden af konfigurationsfilen, og sat det op som vist herunder. Jeg har bevidst blot ladet alting været åbent og usikkert. Jeg kører alligevel i forvejen med SMB1 (se mere længere nede).

sudo nano /etc/samba/smb.conf

[Music]
Comment = Pi shared folder
path = /mnt/usb
writeable = yes
create mask = 0777
directory mask = 0777
public=yes
Browseable = yes
Guest ok = yes

Samba share settings

Hvis du vil bruge dit nye netværksdrev sammen med Sonos S1 skal du have åbnet op for SMB1, da dette er den protocol de gamle enheder snakker over.  SMB1 er ikke sikkert, men hvis du vil bruge netværksdrevet til deling af musik, er det ikke et reelt problem.

Heldigvis er det nemt at slå SMB1 til på din Raspberry Pi. Det er blot at slå følgende til under global i konfigurationen for samba

sudo nano /etc/samba/smb.conf

[global]
# enable SMB1
client min protocol = NT1
server min protocol = NT1
# enable v1 authentication for Sonos access
ntlm auth=yes

Samba global settings

For eksterne referencer omkring dette, se da disse sider

• https://askubuntu.com/questions/1265923/configuring-20-04-samba-for-smbv1
• How to set up a NAS drive with Sonos? – Billede Backup Side 1, Billede Backup Side 2
• https://en.community.sonos.com/troubleshooting-228999/samba-share-6863779
• https://support.sonos.com/s/article/78?language=da

Siden 2018 har mine kollegaer, især de der har deres primære fokus på C#, snakket meget om Blazor, hvor vildt det var og at det skulle være fremtiden for frontend-udvikling.

Jeg må indrømme, at jeg altid har været skeptisk. Da jeg først hørte om det var alle mine associationer knyttet til Razor pages fra ASP.NET, som jeg ikke havde de bedste erfaringer med. Hvis man gerne ville have den typestærke tilgang, hvorfor ikke bare bruge Typescript. Hvad er problemet i at snakke med et GraphQL API gennem en JS klient?

Hvis du har det som jeg, er du kommet til det rette sted. I det følgende vil jeg forsøge at redegøre for hvilke dele af Blazor hypen der kan retfærdiggøres, og hvor jeg tror evangelisterne tager fejl, samt hvor vi som skeptikere måske har misforstået Blazor.

Det bliver ikke en lang gennemgang, men jeg linker løbende videre til en del kilder hvis du er interesseret i at lære mere.

Blazor udnytter introduktionen af WebAssembly (WASM) i 2015, til at muliggøre eksekvering af C# på klient-siden af en webapplikation.

Blazor er et frontend framework for SPA (Single-Page Applikation), som bruger C# som fullstack. Blazor gør det dermed muligt at skrive klient-side applikations-kode i C#, uden at skulle gøre brug af JavaScript, som du ellers ville gøre det med jQuery, Angular, React og lignende. Tanken er at Blazor i din webapplikation skal erstatte disse JS-frameworks.

Kombineret med en .NET Core backend, muliggør det at have .NET kode end-to-end. En .NET backend udvikler bliver pludselig en fullstack udvikler, i stand til også at skrive klient-koden i webapplikationen.

Der er som udgangspunkt to udgaver af Blazor. Der er den server-side renderede udgave, og så er der den klient-side renderede. Hver har sine fordele og ulemper, men fordelen ved dem begge er at det er samme kode, der bruges begge steder.

Ved server-side rendering sendes alle UI ændringer fra serveren til browseren via SignalR. På den klient-renderede udgave, sendes DLL’er til klienten, som så renderes af dotnet.wasm. Klientudgaven (WebAssembly udgaven) er hvad vi bedst kan sammenligne med moderne JS frameworks så som Angular & React.

Debugging af koden kan ofte være en stor del af arbejdet. Derfor er det også meget relevant for os at se på hvordan den oplevelse egentligt vil være i Blazor i forhold til traditionel frontend (JavaScript).

Med frameworks som Angular & React vil en stor del af debugging oplevelsen foregå direkte i browseren med de indbyggede værktøjer der er at finde her. Det er også muligt at debugge direkte i browseren med Blazor, men det kræver lidt ekstra opsætning, og er ikke en lige så lækker oplevelse som det er det for JavaScript/TypeScript. En uddybende gennemgang af hvordan debugging af Blazor fungerer kan findes på StackOverflow.

Blazor introducerer, sammen med WebAssembly, et nyt paradigmeskifte for den måde vi tænker frontendudvikling.

• Gør det muligt at eksekvere C# i din frontend
  • Bryder JS monopolet på frontend
  • Hvis du allerede kender C# har du lynhurtigt også en frontend, uden at du behøver være programmerings polyglot
• Hurtig udvikling, kort Time To Market
  • Det er nemt for en enkelt udvikler at producere både frontend og backend, og sende begge dele til produktionsserveren 
• Baseret på WebAssembly
  • Muligt at dele forretningslogik & validering i både front og backend
• .NET IL har potentialet for at være hurtigere end JavaScript kode. Dette kan gøre Blazor til det foretrukne værktøj ved udvikling af spil og andre performance-afhængige applikationer
• Hvis du ikke er glad for WPF, kan du forholdsvist nemt bruge Blazor sammen med WPF i .NET6
• Blazor applikationer er natively stateful
• Samme kodebase for web, desktop & mobil
• Samme kodebase for WPA, native & hybride cross-platform apps

Desværre kommer Blazor ikke uden sine egne udfordringer. 

• Blazor kan ikke arbejde med DOM elementerne direkte. Derfor vil der fra tid til anden være brug for JavaScript Interop, til at udfylde de huller denne manglende funktionalitet resulterer i. Det er derfor i mange tilfælde ikke muligt helt at droppe javascript.
• Blazor er i øjeblikket (2021) langsommere end JavaScript. Microsoft har dog en god track record i forhold til performance optimeringer, så dette skulle gerne være et mindre problem på længere sigt
• Debugging er ikke en lige så god oplevelse som  den er det ved etablerede JS frameworks.

Alt efter hvilken renderings-tilgang du bruger, har de også hver deres ulemper.

• Stor payload.
  • Ud over at skulle downloade applikationens WASM og .NET biblioteker til browseren, skal Mono.wasm også hentes ned. 
  • En “Hello World” applikation har en payload på ca. 1Mb i .NET 6, men det løber efter sigende hurtigt op i 5-6Mb når man først har en færdig applikation. Nogle melder om +10Mb.
  • 1Mb for en “Hello World” applikation er meget når man sammenligner med størrelsen på andre frontend frameworks: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1
  • Lazy loading kan løse lidt af disse problemer, men det er stadig noget begrænset og omstændigt

• Kræver konstant adgang til backend.
  • Hvis forbindelsen brydes, stopper applikationen med at virke, indtil forbindelse kan genetableres
  • Hvis serveren genstartes, vil applikationen stoppe med at virke og state tabes 
• Svært at skalere, klienten vil kun fungere med den server som gemmer dens state. Kan løses med Sticky Sessions i SignalR
• Ikke muligt at lave til en PWA
• Introducerer en del crosstalk frem og tilbage mellem klient og server. Kan give store problemer hvis responstid er høj / hvis du er en mobil-bruger

Med ulemperne ved henholdsvis klient-rendering og serverside-rendering, kan det være svært at finde det oplagte sted at bruge Blazor. Især hvis man er afhængig af at applikationen starter hurtigt op.

Det er dog muligt at køre en hybrid af de to renderinger, ved at køre en hybrid løsning. Sergey Zaikin har lavet en gennemgang af hvordan han formåede at løse denne hybrid Blazor opsætning i et demoprojekt.

Blazor er et stærkt værktøj, i den rette usecase.

Som landskabet for Blazor ser ud lige nu, er Blazor rigtigt stærkt hvis du laver enterprise applikationer, hvor du er sikker på at dine brugere altid tilgår applikationen med en computer. Hvis dine brugere bruger mobile enheder, skal du være villig enten til at:

• Lade dine brugere vente et stykke tid på at applikationen er indlæst (WASM)
• Acceptere at applikationen ikke kan virke offline (ServerSide)

Blazor viser rigtigt sine styrker når der er tale om at størstedelen af applikationen består af CRUD operationer mod en .NET backend. Især fordi man så har muligheden for at dele forretningslogik mellem backend og frontend gennem webassembly. Denne centralisering af fx valideringslogik gør det noget nemmere at vedligeholde komplekse forretningsgange.

I fremtiden vil payload på download af mono.wasm, .NET DLL’er samt applikationens DLL’s blive mindre og mindre. Vi har allerede set dette da vi gik fra .NET core til .NET5. Og .NET6 ser også ud til at give massive performance forbedringer.

Hvis  Blazor skal blive bredt accepteret som en platform for webudvikling, er der dog stadig et behov for nedbringelse af payload. Det er en hård konkurrence at skulle kæmpe med JavaScript, når JavaScript eksekverer direkte i browseren, uden at være afhængige af at skulle køre ovenpå en runtime skrevet i WebAssembly (som skal hentes ned som det allerførste i applikationens levetid).

Jeg kan ikke forestille mig en fremtid hvor Blazor erstatter JavaScript. Blazor vil derimod sikkert blive som så mange andre frameworks, biblioteker og værktøjer. Nogle vil undgå det, andre vil omfavne det. Uagtet vil internettet forsætte sin vante udvikling, præcis som vi har set det med udviklingen af de forskellige JavaScript frameworks.

Hvis du ønsker at lære mere om Blazor, kan du finde links til yderligere læsning samt referencer til demoprojekter på Awesome Blazor‘s git repo.

At få etableret et multirumslyd setup kan hurtigt blive dyrt. Især hvis du har et eksisterende anlæg du gerne vil have koblet på multirumslyd.

Jeg er typen som gerne vil spare penge hvor det er muligt. Derfor har jeg længe ønsket mig at finde en måde hvorpå man kunne lave et velfungerende billigt multirumslyd system. Indtil videre har jeg mest kigget på Chromecast Audio og Sonos, hvor Sonos er den løsning jeg i øjeblikket kører med.

Siden slutningen af 2015, og frem til Chromecast Audio blev discontinued i 2019, var Chromecast Audio den absolut billigste måde at tilføje billigt multirumslyd til hele huset. Her udgav Google nemlig en opdatering til enheden, som gjorde multirumslyd muligt på Chromecast Audio.

Inden jeg endte med at skifte vores setup ud, havde vi selv Chromecast Audio som multirumslyd i huset. Det fungerede fint, og har du en bunke Chromecasts liggende kan man stadig lave nogle rigtigt fine og kompetente multirumslyd systemer.

Skal du ud og anskaffe dig Chromecast Audios kan det hurtigt blive en dyr affære. Sidst jeg tjekkede priserne her, kostede en enkelt brugt Chromecast Audio lige så meget som brugt Sonos S1 udstyr, ofte mellem 400,- og 800,- pr. enhed. Hvilket også var grunden til at jeg endte med at sælge mit Chromecast Audio setup, og i stedet skiftede over til Sonos S1.

Det skal nævnes at selvom Chromecast Audio er discontinued og ikke længere kan købes fra ny, kan man stadig bygge sin egen med blot 3 komponenter:

1. Chromecast
2. HDMI Audio extractor
3. 230V USB lader

Der findes masser af YouTube videoer, som viser hvordan man laver en normal Chromecast om til en Chromecast Audio. Du kan se en af dem herunder.

Selvom Sonos i maj 2020 stoppede support for deres S1 / gen1 produkter, betyder det ikke at produkterne stopper med at virke. De gamle Sonos produkter vil ikke modtage softwareopdateringer med ny funktionalitet da de interne computere i produkterne ikke kan følge med til at kunne håndtere disse opgaver. Dog vil de (for nu) vedblive at modtage sikkerhedsopdateringer.

Dette betyder at der siden maj 2020 har været mange som er begyndt at udnytte Sonos’s TradeUp program hvor man får (op til) 30% rabat ved køb af en nyere version af produktet. Derfor er der nu også en masse billigere Gen1 Sonos enheder at finde på brugtmarkedet.

Fx kan man i skrivende stund (sommeren 2021) ofte købe en Play5 for ca. 1.000,-. En Sonos Connect for 500,- og en Sonos AMP for mellem 750,- & 1.000,-. Dette før det pludseligt til et forholdsvist billigt multirumslyd setup.

Det at der ikke kommer nye features til de gamle Sonos produkter, betyder også at der ikke vil blive tilføjet nye streaming services. Men da der allerede findes Tidal, Sonos, YouTube Music, Plex & diverse radio stationer er vores forbrug derhjemme længe dækket ind.

Risikoen du løber ved at købe det gamle Sonos udstyr, er at Spotify, Tidal eller de andre streaming services engang i fremtiden ikke vil droppe supporten for de gamle Sonos enheder. Eller at enhederne går i stykker gennem at være blevet slidt. For selvom det hele er bygget på microchips, bliver selv microchips slidt i stykker med tiden.

Denne risiko er dog ikke noget jeg frygter bliver et stort problem og en stor udgift. Når det engang i fremtiden kommer til at ske, vil det sikkert være muligt at købe S2 (eller måske S3, hvem ved) systemer brugt til billige penge, da der til den tid sikkert er blevet lavet et generationsskifte af Sonos enhederne igen.

I forbindelse med opsætning af Sonos systemet hos os, løb jeg ind i lidt problemer med de Sonos enheder som ikke er koblet direkte på netværket med netværkskabler.

Kør om muligt på eget WiFi netværk, og kabel så meget som muligt.

Sonos enhederne vil helst køre på deres eget SonosNET. Så hvis der findes bare én enhed på netværket som er kablet, vil den lave et trådløst SonosNET, hvorefter de andre enheder vil koble på dette net som et mesh-netværk.

Denne tilgang kan skabe nogle problemer hvis der er for langt mellem to Sonos enheder (derfor findes Sonos Bridge enhederne). Dette problem ville ikke opstå hos os hvis enhederne blot kørte på det “rigtige” WiFi netværk, da vi har Accesspunkter fordelt jævnt ud over hele huset.

For at få slukket for SonosNET, skal man igennem en mindre procedure for at få netværket dræbt helt. Jeg fik vores SonosNET slukket således:

1. Sluk alle de trådløse enheder.
2. I Sonos appen: Naviger derefter ind under den enkelte kablede enhed, og deaktiver WiFi.
3. Når WiFi er deaktiveret på de kablede enheder, kan man tænde WiFi enhederne igen.
4. Nu bliver der ikke oprettet et SonosNET de kobler på, og de vil derfor forsøge at oprette forbindelse til det i appen definerede WiFi.

Jeg måtte gennemgå processen et par gange før det rigtigt slog igennem. Til gengæld har vi ikke haft problemer med udfald og dårligt signal siden vi fik deaktiveret SonosNET.

Det viser sig at Sonos fjernbetjeningen CR200 (og sikkert også CR100) kun kan koble sig på dit netværk via SonosNET. Hvilket også betyder at hvis du aktivt har tvunget alle dine enheder over på dit eget netværk, kan du ikke længere bruge CR200 enheder, uden at koble en Sonos Bridge på, til netop dette formål. Det er værd at have i mente som et tradeoff, hvis man ønsker at gøre brug af CR200 i systemet.

Kender du til et godt setup, så fortæl mig endeligt om det i kommentarsporet herunder. Der er helt sikkert et billigt multirumslyd setup jeg ikke kender til, endnu.

Når man kigger på min LinkedIn profil, vil man se at jeg gennem årene har været hos en del forskellige virksomheder. Derfor har jeg også efterhånden en del erfaring med hvad det er man, som funktionæransat, skal være opmærksom på at få skrevet med i kontrakten, da det ikke som standard følger med gennem funktionærloven.

• Barnets første sygedag
• 6. ferieuge/5 feriefridage/omsorgsdage
• 2 ugers fædreorlov med løn
• Tilladelse til andet hverv under ansættelsen
• Betalt pension fra arbejdsgiver, meget gerne en fast % af din løn, så stiger bidraget sammen med din løn
• Firmabetalt telefon & internet

Indmeldelse til “Danmark”, hurtigst muligt, gerne inden hælprøven tages

Bestilling af personattest

Få oprettet børneopsparing med aktiedepot hos din bank

Oprettelse af opsparingskonto for børn hos Nordnet

• Kræver Personattest
• Begge forældre skal skrive under

Kontakt forsikringsselskab og informer om barnet (og få gratis ulykkes forsikring for barnet i 1-3 år)

Få barnet skrevet op til dagpleje / vuggestue

• Vent ikke med dette, der er meget ofte rift om pladserne, og det er først til mølle de fleste steder

Få barnet skrevet op til privat børnehave

• Flere og flere steder kan man skrive op allerede ved fødsel. Vent derfor ikke med dette, der er meget ofte rift om pladserne, og det er først til mølle de fleste steder

Få barnet skrevet op på venteliste ved privat folkeskole

Få barnet skrevet op på venteliste hos efterskoler

• Hvis de da har åbent for tilmelding allerede, nogle steder kan man først tilmelde når barnet er startet i skole

Hvis man har et fastforrentet realkreditlån, er det meget normalt at lægge lånet om løbende, for at udnytte den enten stigende eller faldende rente. Derfor findes der også virksomheder som specialiserer sig i netop dette aspekt af lånemarkedet, hvor et eksempel kunne være RealkreditKonsulenten med deres låneberegner. Disse virksomheder tilbyder at holde øje med dit lån, og endda lægge lånet om for dig når et nyt lån ligger i en favorabel kurs.

Ens for alle disse produkter er dog, af hvad jeg kan se, at de alle lægger om til en kurs tæt på, men stadig under, kurs 100. Det er ikke altid favorabelt for dig, hvilket er hvad vi vil se nærmere på i det følgende.

En omlægning af et realkreditlån er ikke gratis, det er altid forbundet med en række udgifter. Lad os tage et eksempel på hvilke udgifter der er ved Realkredit Danmark, hvis man skal omlægge et lån på 2.500.000kr i februar 2021, til kurs 99,8 (“ideal” kursen).

• Kurtage / Afregningsprovision – 0,15% = 3.750,-
• Kursskæring – 0,25% = 6.250,-
• Kurstab –  0,2% (100 – 99,8 ) = 5.000,-
• Lånesagsgebyr = 2.850,-
• Ekspedition af ejendomssag = 3.600,-
• Tinglysning = 1.730 ,-

Samlet: 23.180,-

Listen er som du kan se lang, og udgifterne løber hurtigt op. En omlægning af et fastforrentet lån koster hurtigt 25.000kr, eller mere, alt efter hvor stort et lån der er tale om, samt hvilken kurs man tegner til.

De to store poster i forbindelse med en omlægning er kursskæring og kurstab. Hvor kurstabet er den mest variable og potentielt dyreste udgift ved en omlægning af lånet. Derfor ønsker man som oftest kun at at lægge lån om når kursen er i 99,6 eller højere. Så sætter vi kun 0,4% af lånet til ved en omlægning.

På et lån med en hovedstol på 1.000.000kr, udgør de 0,4% kun 4.000. Det er ikke ret meget, men havde du lagt om til kurs 100 havde du sparet de 4.000.

Det omtalte kurstab er også den primære grund til at mange banker anbefaler man først lægger lånet om når der er:

• 1½ – 2 procentpoint i forskel (fra fx 4% til 2% lån)
• Resterende løbetid på mindst 10 år
• Betydelig restgæld, 250.000+

(Disse eksempler er fundet hos Jyske Bank februar 2021.)

Men dette er en meget snæversynet tilgang til omlægning af lån, og jeg vil komme med mit input til en anden tilgang til omlægning af lånet. Det kan nemlig fint give mening at lægge lånet om selvom der kun er et ½ procentpoint i forskel på lånene.

I stedet for at sætte penge til, ved kurstab når kursen på det nye lån er under 100, er det faktisk muligt at lægge lånet om når kursen er over 100. Dette ville resultere i et negativt kurstab (et kurstab til din fordel, en kursgevinst). Så ville de samlede omkostninger falde, og er kursgevinsten god nok vil du få penge for at lægge lånet om. Lægger du om til kurs 101 ville du på et obligationslån med en hovedstol på 1 million, få 10.000 i negativt kurstab.

Nu sidder du sikkert og tænker “Men, jeg kan ikke få et lånetilbud hvis kursen er over 100“, og det har du helt ret i. Men, du kan sagtens få et lånetilbud mens lånet er under kurs 100, og så eksekvere på tilbuddet senere. Bare fordi du har fået et tilbud behøver du ikke eksekvere på tilbuddet samme dag.

Et lånetilbud holder i 6 måneder, så hvis du sørger for at få et tilbud inden kursen på dit ønskede lån overstiger 100, vil du det næste halve år kunne gå og vente på at kursen (måske) stiger nok til at du ønsker at lægge om.

Netop dette trick gjorde vi brug af da vi lagde vores 2% lån om til et 1,5% lån. Der lagde vi om til kurs 101,5 og fik derfor 1,5% af lånets hovedstol udbetalt. Det kan hurtigt mærkes.

Graf over obligationskurs prisudvikling

Den 7. august 2020 blev 1% fastforrentet (obligation DK0004612454 fra Realkredit Danmark) handlet i kurs 100,2. Denne obligation fik vi personligt et lånetilbud på inden den krydsede kurs 100, og kunne derfor blot sidde tilbage og vente på at kursen steg, sammen med vores potentielle fortjeneste ved at lægge vores fastforrentede 1,5% lån om.

I februar 2021 ramte denne obligation kurs 101,42 som sit toppunkt. Denne kurs ville man kunne have lagt om til, hvis man havde et lånetilbud fra august 2020, da tilbuddet her kun ville være 5 måneder gammelt.

1% obligation februar 2021

Hvis du inden for de 6 måneder er heldig nok at kursen kommer godt op, fx til kurs 101,5 (hvilket er meget muligt, selv har jeg lagt om til kurs 101,4 et par gange), ser regnestykket for en omlægning pludselig således ud:

• Kurtage / Afregningsprovision – 0,15% = 3.750,-
• Kursskæring – 0,25% = 6.250,-
• Kurstab –  -1,5% (100 – 101,5 ) = -37.500,-
• Lånesagsgebyr = 2.850,-
• Ekspedition af ejendomssag = 3.600,-
• Tinglysning = 1.730 ,-

Samlet: -19.320,-

Altså vil du til en kurs 101,5 få udbetalt næsten 19.500,- i forbindelse med at du lægger om til et (forhåbentligt) billigere lån.

I stedet for at få pengene udbetalt er det også muligt at trække dem fra hovedstolen hvis man skulle ønske dette. Personligt går jeg ikke efter dette, da jeg mener at realkreditlån med så lave renter, er blandt de gode lån.

Der er, ifølge firmaet RealkreditKonsulenterne, rygter om at bankerne forsøger at lukke dette “hul” hvor man lægger om til en kurs over 100. Eller blot udnytter et lånetilbud som har en anderledes kurs end den kurs der står på tilbuddet.

Derfor kan hele denne finte være en stakket frist. Vi må se hvor længe det er muligt for os at tjene lidt ekstra penge på denne måde.

Bankerne forsøger at lukke omlægning til over kurs 100

Det skal tages med i beregningen at der alt efter hvordan man vælger at lægge lånet om, om man vælger at kurssikre, etc., kan der være flere udgifter end angivet ovenfor. Disse udgifter kunne være fx differencerenter, eller yderligere kursskæring ved at kurssikre.

Sammenligningerne er dog stadig valide og taler deres tydelige sprog. Kurstabet er vigtigt at holde øje med. Og så længe vi kan lægge om en til kurs over 100, kan det hurtigt være forsøget og ventetiden værd.

Bemærk at dette kun virker ved en nedkonvertering. Ved en opkonvertering består gevinsten udelukkende i at man får skåret en luns af hovedstolen.

Du har helt sikkert, ligesom mig, oplevet det. Gardinerne er rullet for, popcornene er poppede, din drink står klar og du har endelig fundet tid til at sætte et par timer af til at se en fantastisk film fra Netflix.

Og så sker det, midt i den store action scene, eller liiige når de to hovedroller er ved at finde hinanden. Kvaliteten falder drastisk, eller måske stopper filmen ligefrem fordi den er i gang med at buffer. Du blevet hevet ud af stemningen, og det bliver bare aldrig rigtigt det samme.

Der kan være mange grunde til at dette sker, men ligesom mig har du helt sikkert overvejet om ikke det er muligt at downloade filmen på forhånd, så man kan sikre sig mod at dette sker. Med Netflix’s app på Microsoft Store er det muligt for dig at downloade nogle film (ikke alle, men det føles som om antallet af titler stiger dag for dag). Men burde du downloade filmene på forhånd inden du skal se dem? Vil kvaliteten være god nok? Dette har jeg forsøgt at svare på i denne artikel.

For at vi kan lave nogle acceptable tests, er vi nødt til at have et fast datasæt som vi kan teste op imod.  Netflix tilbyder nogle test-patterns man kan lege med: https://www.netflix.com/dk/title/80018499. Disse tests blev valgt til vores tests da vi regner med at disse tests vil forblive på platformen fremadrettet. Disse tests kan også downloades, hvilket det ikke er alle film på Netflix der understøtter.

Ud over de konkrete målinger består en stor andel af mine data herunder stammer fra telefonisk dialog med en tekniker / programmør hos Netflix. Jeg har derfor heller ikke konkrete referencer til at bekræfte hvad jeg skriver herunder. Jeg arbejder på at få noget på skrift fra Netflix, men tror aldrig jeg får det, desværre.

Netflix Download på Windows

I det følgende er der taget udgangspunkt i “Sæson 1, EP8” af testfilmene. Det er en version der understøtter op til 4K & 60FPS.

Samtidig viser de også opløsning på det billede du får leveret, samt FPS. Disse oplysninger gør det meget nemmere for os at lave tests på flere enheder og være helt sikre på hvilket medie vi får leveret fra Netflix.

Grunden til at vi i første omgang kigger på størrelsen af vores downloadede, er at størrelsen af en film passer meget godt overens med billedkvaliteten af en film. Til en vis grænse.

Hvis du har to versioner af en film, hvor den ene fylder 1GB og den anden 10GB, vil den store fil i langt de fleste tilfælde være den der er i den bedste kvalitet. Dette skyldes at de to film vil være komprimeret på hver deres måde, hvor større komprimering (og dermed mindre filstørrelse) ofte betyder dårligere kvalitet.  Vi er gået mere i dybden med hvordan billeder og video komprimeres, så tjek den artikel ud hvis du ønsker at vide mere om hvad det er der egentligt foregår.

Det er værd at bide mærke i at en gennemsnitlig 1080p BluRay film fylder ca. 30Gb for 1½ times film.  For en streamingtjeneste som Netflix er dette mange gigabytes at sende over internettet, for ikke at snakke om at du som minimum ville skulle bruge en 70Mbit internetforbindelse for at kunne streame filmen i den kvalitet (hvis der ikke sker andet på netværket samtidigt). Derfor ser vi også at Netflix, og alle andre streaming udbydere, har komprimeret filmene yderligere end “blot” den komprimerede version vi får på en BluRay.

Lad os se på de konkrete tal herunder og se hvor store film vi får lov at få serveret fra Netflix når vi enten downloader eller streamer film hos dem.

• 720p stream -> 3,2Gb
• 1080p stream -> 6,2Gb
• 4K stream stream -> 14Gb

Ved vores downloads har vi noteret størrelsen på den enkelte enheds skærm.

• Honor 10 (1080×2280 = 2.462.400 pixels) -> 514Mb
• Galaxy S9 (1440×2960 = 4.262.400 pixels) -> 295Mb
• iPhone 8 (750×1334 = 1.000.500 pixels) -> 485Mb
• iPad fra 2018 (1536×2048 = 3.145.728 pixels) -> 485Mb
• Windows PC med 1080p skærm koblet til -> 1,4Gb
• Windows PC med 4K skærm koblet til -> 1,4Gb

Som vi ser det på ovenstående tal, er der en meget stor forskel på hvorvidt man downloader filmene eller om man streamer dem. Selv hvis man streamer i 720p er der langt ned til størrelsen på en downloadet version af filmen. Og dette især når vi ser på de mobile enheders downloads.

Vores tal stemmer meget godt overens med de tal HowToGeek fandt frem til da de testede streaming forbrug på en browser i 2018. I forhold til forbruget på mobile enheder passede det også meget godt overens med de tal MyBroadband.co.za fandt frem til i 2018.

Endvidere viser vores tests at downloads lader til at være låst til 720p 30fps. Vi prøvede dette af med flere titler for at se om det kun var vores testfilm der var berørt af dette, men det lod til at dette gjaldt alle de film vi hentede ned. De fyldte alle lige omkring 1,5Gb.  Dette stemmer desværre ikke helt overens med hvad Netflix selv skriver på deres hjælpeside. Her skriver Netflix at downloads der er låst til “høj kvalitet” kan levere “op til 1080p”, afhængig af den downloadede titel.

Efter dialog med Netflix, viser sig at Windows downloads ofte er låst til 720p. Hvilket passer meget godt overens med at vores 720p downloads er den halve størrelse af vores 720p streams.

En af grundene til at filstørrelserne er lavere ved downloads i forhold til streams, er at der ved downloads bliver brugt et x265 codec i modsætning til x264 eller lignende i streams. Ved brug af x265 (HEVC) i stedet for x264 (AVC) kan Netflix gøre størrelsen på deres film op imod 50% mindre.

For at Netflix kan levere disse optimeringer til os er der et stort bagkatalog der skal re-encodes fordi der skal leveres forskellige filer alt efter om vi snakker download eller stream. For ikke at snakke om forskellen for de enkelte platforme. I 2020 var de stadig i gang med denne process.

Netflix gør hvad de kan for at gøre downloads så små som muligt, uden at gå for meget på kompromis med kvaliteten. Et af de steder Netflix kan spare mest plads på de mobile enheder, er ved at encode de enkelte scener i filmen forskelligt, alt efter hvordan scenen er. Scener hvor der ikke er meget bevægelse, bliver encoded med en lavere bitrate end resten af filmen. De enkelte scener bliver så stykket sammen, og samlet til én film i sidste ende.

Dette betyder også at der vil forskel på størrelsen af film afhængigt af hvorvidt der er tale om en film med med mange stille billeder og dialog, eller om det er en hæsblæsende actionfilm med en masse skiftende scener, og hvor der sket meget i scenerne.

Vores tests viser at streaming giver ofte adgang til bedre lydformater end downloads. Downloadede film tilbød højest et 5.1 lydspor hvor streaming tilbød os 7.1 og nogle gange endda Atmos.

Hvis du har et godt lydanlæg (5.1 surround eller bedre), vil vi derfor ikke anbefale at pre-loade filmene da det ikke er det fulde lydbillede du får hentet ned ved downloads. På det rigtige anlæg vil dette tydeligt kunne høres.

Hvis du har et 4K TV vil vi på ingen måde anbefale at du “pre-loader” film til din Windows maskine, men derimod bør du altid streame dit indhold for at få det bedste ud af dit abonnement. Netflix selv oplyser at den maksimale opløsning er 1080p hvis du downloader film, men vores tests viser at der ofte er tale om downloads i 720p (vi fandt kun The Umbrella Academy som var i 1080p). Dette alene gør det til et no-go, da du vil få en masse uønsket opskalering på TV’et hvilket ikke gør noget godt for billedet.

Selvom at h265 formatet tilbyder størrelser på omkring halvdelen af den oprindelige størrelse, kan vi se at downloadede film på Windows er under halvdelen af den størrelse som bliver streamet. Dette kommer ikke uden en konsekvens for kvaliteten af de downloadede film. Det er muligvis et resultat af en konkret strategi fra Netflix hvor downloads ikke er ment som den primære måde at se deres film.

Hvis du dog konsekvent har problemer med at dine film skal buffer hele tiden, ville jeg nok overveje at downloade filmen på forhånd. Dog ville jeg så nok i samme omgang overveje om det er værd at betale for den store pakke hos Netflix, da du ved downloads aldrig ville få udnyttet den kvalitet du betaler for.

Det er værd at nævne at der er en del krav man skal leve op til hvis man overhovedet skal have muligheden for at nyde 4K streams fra Netflix på ens TV. Bruger du en browser skal det fx være Microsoft Edge, og dit HDMI kabel skal have en høj nok kvalitet / være minimum HDCP 2.2 (HDMI 2.0).

Dertil skal din computer enten have en Intel processor der er nyere end 2016 (7ende generation intel processor), eller et Nvidia grafikkort som er fra 2016 eller nyere (Nvidia 1050 eller bedre).

De samme krav gælder hvis du vil se indhold i HDR.

Alternativt kan du bruge en Chromecast Ultra. Det vil give dig muligheden for 4K & HDR så længe dit TV understøtter 4K & HDCP 2.2. Desværre er min erfaring at dette til tider er på kompromis af lydkvaliteten.

Såfremt at du ser hele filmen på din mobile enhed, er jeg tilbøjelig til at anbefale altid at downloade en film inden du ser det. Det kræver mindre data, og kan spare dig for både strøm og data. Ser du kun en lille del af den ville jeg nok ikke downloade den, men blot streame den smule du lige får set.

Personligt har jeg ikke lagt mærke til de store kvalitetsforskelle på downloads og streams på min mobiltelefon.  Dette nok primært fordi jeg har set filmene på en mobiltelefon, og at jeg primært ser de downloadede film i tog eller bus, hvor man ikke nyder filmene på en anden måde. Det skal dog bemærkes at jeg ikke har lagt mærke til pixelfejl og andre tydelige fejl som følge af komprimering, hvilket i sig selv må være en stor kado til Netflix og deres evne til at komprimere filmene troligt effektivt.

Det skal også nævnes at de film jeg har downloaded på telefonen primært har været komedier eller episoder i en serie. Disse to kategorier af materiale er heller ikke kendt for at være de flotteste da budgettet her ikke er det samme som de kæmpestore flotte action-baskere med en masse CGI

Den store fortaler for at pre-loade Netflix film på din telefon eller tablet er sikkerheden i at kvaliteten ikke falder drastisk mens du sidder i toget eller bussen, hvis den da ikke stopper helt og venter på at du får forbindelse igen.

Jeg er meget på farten, og pendler hver dag til og fra arbejde.

Når jeg rejser med tog kan jeg for det meste arbejde, men når jeg rejser med bus er det noget sværere, og her bruger jeg for det meste tiden på at se lidt af en serie på Netflix eller hvor end jeg lige har et streaming abonnement i den måned.

Efter at have set en del offline video fra Netflix, i stedet for at streame det, er det kommet bag på mig hvor flotte billederne egentligt er.

Der er noget lækkert over selv at have styr på sine lydfiler (jeg har hørt om folk der har mistet hele deres podcast fordi de kun havde deres lydfiler hos en tredjepart som gik konkurs).

At miste dine filer kan du dog sikre dig imod ved selv at håndtere backups af dine lydfiler. Du bør altid have styr på ved at have dine filer flere steder, og ikke kun ét sted. Det uanset om du har filerne hos en tredjepart eller hos dig selv.

Jeg plejer at bruge Seriously SImple Podcasting til at styre podcasts på mine wordpress websites. Det er nemt, og det genererer et RSS feed der er til at arbejde med.

Mange online melder at man ikke kan bruge Cloudflare sammen med sit podcast, men der er jeg dybt uenig. Det kan man sagtens, og med meget god fordel endda. Hvis du indstiller Cloudflare rigtigt kan du få dem til at cache alle dine lydfiler for dig, resulterende i at du ikke engang lægger meget ekstra arbejde på dit wordpress site.

Dette kræver dog at man opretter specifikke page-rules for at inkludere disse filer.  Reglerne kan have sideeffekter du ikke ønsker, men de er værd at overveje.

Hvis du bruger Seriously SImple Podcasting til at oprette dine podcast episoder, er det vigtigt at huske dine metadata. Disse data bruges forskelligt hos de forskellige podcast udbydere, så jeg plejer at udfylde dem alle, og lade det være op til den enkelte udbyder hvordan de vil fortolke mit feed.

iTunes især har en masse særlige felter de gerne vil have udfyldt. De vil gerne vide konkret hvilken episode og hvilken sæson der er tale om. Samt at de gerne vil have en eksplicit titel. Flere af disse data er duplikerede, men vi tilføjer dem for at gøre Apple glad.

På det nedenstående billede kan du se der er en del felter. Felterne “Varighed” og “File size” bliver udfyldt automatisk når du har uploadet din podcast-fil, og gemt dine ændringer. Alt det andet skal udfyldes manuelt.

Podcast detaljer

Som du måske har lagt mærke til på billedet herover, er der et inputfelt der hedder “Serier”.  Serier indenfor det enkelte podcast bruges ofte som konkrete opdelinger i tidsperioder eller emner. Hvilket muliggør det for et længeregående podcast at skabe en form for sortering og overskuelighed for deres lyttere. Men giver også mulighed for at differentiere sig indenfor det samme podcast, da man så kan afgrænse det til en enkelt sæson hvis man vil prøve noget nyt af.

Serier er derfor heller ikke det samme som når man ser flere forskellige podcasts fra samme udbyder. Fx som når vi ser at DR tilbyder mange forskellige podcasts. Disse podcasts er selvstændige podcasts med samme udbyder. DR har flere forskellige podcasts hvor de står som forfatter / udgiver. Dette gør at man på fx iTunes kan klikke på udgiveren og få et samlet overblik over alle podcasts fra denne udbyder. Dette er rigtigt meget brugt af især journalistiske bureauer, da de så får en samlet portefølje af indhold samt skaber genkendelighed.

Som udgangspunkt er forfatteren den der opretter den enkelte episode, det er ikke nødvendigvis hvad du er ude efter.

Måske har du en podcast der separate udgivere for hver episode, eller måske veksler du mellem forskellige talere. Her er det vigtigt at du angiver hvem forfatteren for det enkelte indlæg er.

Angivelse af forfatter

På billedet herunder vises der en forfatter under hvert enkelt episode af Hedensted Valgmenigheds podcast. Det er denne forfatter man angiver når man vælger forfatter ved oprettelsen af den enkelte episode.

Forfatter på enkelt podcast episode

I forhold til afspille dit podcast på din egen blog kan jeg varmt anbefale Podcast Player. Det er muligt også bare at indlejre de enkelte episoder som lydfiler på bloggen, men hvis ikke dit tema understøtter dette ordentligt kommer det hurtigt til at se grimt ud, og bliver tungt at arbejde med / indlæse.

Samtidig sættes Podcast Player op til at følge dit RSS feed, så den bliver automatisk opdateret når du har tilføjet et podcast til dit feed.

Ud over at afspille podcasten på din egen blog, er du nok også interesseret i at få din podcast ud til de forskellige udbydere. Jeg har lavet en lille guide over hvor og hvordan du får dit podcast publiceret hos de forskellige udbydere.

I forhold til hvordan du håndterer fremvisningen af dit podcast på din hjemmeside er det meget afhængigt af hvad planen for dit podcast er.

Hedensted Valgmenigheds oversign over podcasts bliver ikke brugt nogen steder, og er blot automatisk genereret af Seriously Simple Podcasting.

Standard oversigt over podcast episoder

Navigerer man ind på en af siderne får man standardopsætningen for en podcast episode. En afspiller samt lidt forskellige oplysninger og muligheden for at abonnere på de forskellige platforme hvor deres podcast er tilgængeligt.

Standard Podcast layout

På Hedensted Valgmenigheds oversigt over prædikener kan de se hvordan deres podcast som udgangspunkt er tænkt vist på hjemmesiden. Tanken er blot at bruge det tidligere omtalt plugin “Podcast Player”, samt linke til andre sider med mere konktere players hvis man gerne vil høre en prædiken fra et specifikt år.

Hedensted Valgmenigheds Podcast oversign

Denne tilgang er valgt hos Hedensted Valgmenighed da deres podcast ikke er deres primære produkt. Hvis dit podcast er det primære produkt vil jeg klart anbefale at gøre mere ud af de enkelte episoder. Bare det at tilføje et “Udvalgt billede” samt at udfylde beskrivelsen for et podcast kan gøre en verden til forskel.

Pragteksemplaret på dette synes jeg vi kan se hos 99 percent Invisible. De har valgt at gengive alle deres podcasts som tekst, samtidig med at de beriger deres historier med billeder. Dette giver en helt anden oplevelse når man går gennem de enkelte episoder.

99pi podcast layout

Udgangspunktet her er at du ikke vil have dine podcasts til at ligge hos en tredjepart men selv vil hoste dine lydfiler på din egen server. Samtidig antager vi at du bruger WordPress til at håndtere dit podcast.

Hvis du bruger tredjeparts-løsninger som fx Buzzsprout eller Blubrry håndterer de meget af arbejdet for dig, og har ellers gode guides til hvad du skal gøre for at komme i gang.

Du kan bruge https://castfeedvalidator.com/ til at validere om dit podcast opfylder de krav der stilles af de forskellige udbydere. Det er en god start, men ikke en garanti for at dit podcast vil blive valideret de forskellige steder. Her er der kun at forsøge, og så rette til hvis der er problemer.

Artiklen vil løbende blive opdateret når jeg får tilføjet mine podcasts til nye services.

Hvis du vil have dit podcast publiceret ud til masserne, er du nødt til at kunne blive fundet på iTunes.

For at få din podcast på iTunes, skal du oprette en personlig Apple bruger. Ja, det skal være en personlig bruger, Apple kender desværre ikke til udtrykket virksomheds-konto. Så opret en bruger som I kan dele internt, gem den gerne i en password manager så I altid kan finde den
Når kontoen er oprettet skal du ind på https://podcastsconnect.apple.com/, her skal dit feed valideres inden du kan komme videre

Apple er, som vanlig, ret kræsen omkring hvordan tingene skal være. De kræver at du skal have et billede for din podcast. Billedet skal være i RGB farver (så ikke CMYK), det skal være kvadratisk, og det skal være større end 1400×1400 pixels. Denne del brugte jeg, og en del andre kan jeg se online, meget tid på. Så få tjekket godt op på dette i god tid.

Dertil kræver de at din server understøtter tillader HTTP HEAD-anmodninger.

Et andet sted du er nødt til at være, er på Google Podcasts. At få dit podcast publiceret her kan enten være lidt udfordrende, eller super nemt. Hvis du allerede har publiceret dit podcast på din hjemmeside er der stor sandsynlighed for at Google allerede kender dig.

Problemet er, at man ikke ringer til Google, Google ringer til dig. Det er den tilgang Google har når det omhandler podcasts. Du kan ikke manuelt tilføje dit podcast til Google Podcasts, derimod skal Google selv kunne finde og indeksere dit podcast. Når dette sker, bliver dit podcast automatisk tilføjet til Google Podcasts.

Fordelen ved denne tilgang er dog at der er større sandsynlighed for at Google forstår dit podcast godt nok til at det bliver vist på en pæn måde i dens søgeresultater. Dette er fx tilfældet ved 99 percent invisible som jeg selv lytter meget til.

99 percent invisible podcast søgning

Du kan dog godt bede Google ringe til dig. Naviger ind på din Google Search Console, og indtast i toppen dit link til dit RSS feed. Når linket så checkes kan du anmode om at få linket indekseret.

Anmod om indeksering af webadresse

Google tester at side kan indekseres

Indeksering af webadresse anmodet

Anmodningen kan nogle gange være gennemført på et par timer. Men du skal væbne dig med tålmodighed, der kan nogle gange gå op imod en uge. Er du dog ikke indekseret efter en uges tid, bør du nok dobbelttjekke at din siden kan indekseres, og derefter anmode igen. For mig tog det ca. 4 dage.

Spotify er gået hen og er blevet den største Podcast platform på markedet. Derfor har du også interesse i at få dit podcast listet hos Spotify, så du ikke går glip af potentielle lyttere.

At få din podcast publiceret på Spotify er meget nemt og simpelt. Det kræver at du har en bruger, men efter oprettelsen af din bruger, er det blot at navigere ind på  https://podcasters.spotify.com/submit. Her vil du blive mødt at en guide der hjælper dig med at få tilføjet din podcast til Spotify.

Nå du er færdig med den guide Spotify stiller til rådighed vil du kunne se den i dit katalog her: https://podcasters.spotify.com/catalog. Her kan du også følge med i hvor langt den er med at processere din podcast.

I mit tilfælde var processeringen hurtigt overstået, og podcasten var tilgængelig inden for en dag.

Hvis I er flere der skal håndtere podcasten hos Spotify, er det blot at følge deres guide til hvordan du kobler flere brugere på.

Jeg bruger personligt Podcast Addict til at lytte til podcasts. Hvis du har brug for det, kan du manuelt tilføje din podcast til Podcast Addict på det følgende link: https://addictpodcast.com/submit.

Jeg må ærligt indrømme at jeg ikke ved om Podcast Addict selv finder dit podcast hvis du får den lagt op hos enten Apple eller Google. Jeg nåede manuelt at tilføje min podcast her inden den blev indekseret hos Google.

Stitcher er et meget populært sted at finde podcasts. Det er gratis at få din podcast lagt op til dem, så man kan lige så godt bruge de 5-10 minutter det tager og sørge for at de også kender dig og dit podcast.

1. Opret en Content Provider profil, ved at klikke på knappen Join Us Today
2. Indtast dit RSS feed, og klik “next”
3. Bekræft din e-mailadresse og accepter “terms and conditions”.
4. Du vil modtage en bekræftelsesmail når din podcast er tilgængelig på Stitcher

TuneIn er endnu en meget populær service til at finde podcasts og live radio. At få din podcast vist hos dem, kræver at du udfylder en formular. Du kan finde deres formular her: https://help.tunein.com/contact/add-podcast-S19TR3Sdf

At blive tilføjet hos Pocket Casts er nemt, det er blot at indtaste din mail på deres  tilføjelses-side, og så er du kørende. https://www.pocketcasts.com/submit/

For at få din podcast vist i Podimo skal den først godkendes hos iTunes. Fra den er godkendt i iTunes kan der gå et par dage før den bliver synlig hos Podimo. Så at blive publiceret hos Podimo sker helt af sig selv.

Podimo giver dig muligheden for at tjene penge på din podcast. Først når din podcast kan søges frem hos Podimo, kan du “claim” din podcast, og få 20% af indtægterne fra de premium-brugere der lytter til din podcast.

Før du overhovedet kan få del i indtægterne fra din podcast skal du have oprettet en bruger. Her er det samme princip som ved Apple, og du skal derfor oprette en privat bruger som I så kan dele internt i jeres team hvis I er flere om jeres podcast.

Podimo Claim Show

Jeg bøvlede i starten meget med at jeg ikke synes jeg fik vist ret mange episoder af mit podcast på de forskellige podcast platforme.

Om det er fordi jeg lagde mange episoder op på én gang, eller om det er grundet at de løbende holder sig opdateret med feeded ved jeg ikke. Men jeg fandt ud af at feedet som standard kun viser 10 episoder.

Dette kunne dog hurtigt løses, ved at ændre på mængden af elementer i dit Syndikeringsfeed. Jeg satte mit feed op til at vise 1.000 emner, og siden da har jeg ikke haft problemer med at jeg ikke kunne finde alle mine episoder i de forskellige podcast afspillere. Det skal dog også siges at jeg har under 1.000 podcasts i mit feed.

Længde af syndikeringsfeed sat til 1.000 emner