XBMC & Recordin gService

Jo, når man bruger Xbmc, xbmc understøtter ikke timeshift, det skal varetages af backend servicen.

Redigeret af Sæderup - 30-December-2012 kl. 14:40

MCenterFreak skrev: Det er da upraktisk, specielt hvis man har flere klienter der timeshifter samtidigt. Så får backenden jo nok at lave

Det er backenden der står for at optage ting, så det er det naturlige sted at lægge timeshift.

I princippet er der ikke forskel på timeshift og en programmeret optagelse. Du sidder og er midt i at se en udsendelse live når svigermor ringer/du skal på lokum. Du trykker på en knap der sørger for at lynprogrammere en optagelse der hedder "optag resten af programmet her" og når du kommer tilbage fra telefonen/tønden vælger du at afspille optagelsen af sidste halvdel af programmet. Teknisk set er der ingen forskel på "optag den her kanal fra nu af" og "optag james bond filmen fra tv3 iaften kl 21.00", begge opgaver backend bør tage sig af.

MCenterFreak skrev: Bortset fra at det kan blive dobbelt dobbelt op hvis backenden skal timeshifte samtidigt med at den skal optage schedulerede programmer. Der vil jeg foretrække at klienten timeshiftede, for at undgå framedrops i mine optagelser

Din backend kan vel optage fra samtlige sine tunere på en gang uden at gå i knæ?

Hvis din backend har fx. 4 tunere og kan optage 4 timeroptagelser samtidigt uden problemer, så kan den også optage 2 timeroptagelser og 2 gange timeshift på en gang efter som timeshift bare er en optagelse der er startet midt i en udsendelse.

Med andre ord, hvis din backend ikke kan håndtere det antal tunere du har puttet i den uden at framedroppe er det på tide med en bedre backend..

Jeg kan bare ikke se hvorfor det skulle være mere stressende for backend at timeshifte end at lave almindelige optagelser og levere stream, eneste forskel er lidt disk access. En moderne harddisk er flere hundrede gange hurtigere end det hurtigste netkort og et par tusinde gange hurtigere end den mængde data der drypper ind fra et dvb-c eller dvb-t signal, så at tage et indkommet signal, gemme det midlertidigt på disk og streame signalet videre derfra i stedet for direkte fra tuneren bør ikke kunne vælte en backend.

Hvis din klient beder din backend om at afspille den film du optog sidste weekend, så læser din backend lidt data fra filen ind i en buffer og sender til din klient som en stream. Hvis du trykker pause på klienten kommer der signal til backenden om at den lige skal vente lidt med at streame mere, det stresser ikke backenden.

Hvis din klient beder din backend om et live signal, så læser backend lidt data ind fra tuneren i en buffer og streamer det videre til klienten. Hvis du trykker pause på klienten kommer der signal til backend om at du gerne vil have optaget resten af udsendelsen og streamet fra den optagede fil når du er klar igen, det kan jeg heller ikke se burde stresse backend.

Får din backend stress hvis du begynder at se en film optaget via timerprogrammering inden den er helt færdig med at optage filmen?

Du må selvfølgelig optage lige præcis som du har lyst, jeg kan bare ikke få øje på logikken i lade både backend og klienter lave optagelser når det nu engang er det en backend er designet til at stå for.

Du kan ikke køre Recording Service uden at DVBViewer er installeret. De bruger fælles filer, bl. andet channels.dat. Du er nød til at bruge DVBViewer, eller transedit for at scanne kanaler

Kolvig skrev: Ok tak for svar...   Ok, så på servermaskinen skal jeg have installeret RS, DVBViewer og hvis jeg godt vil benytte XBMC som frontend skal den selvfølgelig også installeres, ikke?   Men er det ikke korrekt forstået at klienterne behøver kun at have XBMC installeret?     Mvh.

Det er korrekt, bortset fra rækkefølgen på serveren. Først DVBViewer og dernæst RS Jeg har ikke selv prøvet XBMC på en maskine uden DVBViewer, men jeg er 90% sikker på at DVBViewer ikke behøves på klienterne, men hvorfor ikke bare installere den alligevel? Nogen gange er det rart at have en 100% stabil klient :-)