375 replies to this topic

[Erik Slagter]

Ik ben pas net "bij" met allerlei andere dingen die ook nog moesten gebeuren

 

Maar maak je geen zorgen, het heeft mijn aandacht.

[siroj]

No problem, take your time! Het is en blijft onbetaalde en goedbedoelde tijdsbesteding die ik zeer waardeer!
Het is lastig aan te geven hoe, maar als ik ergens mee van dienst kan zijn...

[siroj]

Gisteren viel me nog iets op. Ik maakte gebruik van een bouquet wat door de RemoteStreamConverter was aangemaakt en was op die manier TV aan het kijken op de slaapkamer. Op enig moment kwam ik in het menu tegen dat de Fallback Tuner nog ingeschakeld stond. Het blijkt dus ogenschijnlijk niet uit te maken als je deze 2 samen gebruikt, terwijl ik dat wel zou verwachten.

[Erik Slagter]

Dat maakt inderdaad totaal niet uit.

[cobus]

werkt wel super die remote tuner

[Erik Slagter]

We moeten nog even wat vinden voor dat probleem van siroj en het probleem dat enigma bij de timer-conflict-testing geen rekening houdt met remote fallback tuners. Daarvoor komt er nog een optie om dat uit te zetten. Dat klinkt echter simpeler dan het is

[littlesat]

Opnames zou je niet fallback willen hebben... Want een fallback hoeft niet vrij te zijn... Dus voor mij is de opname check nu goed... Lievr dan wel een goede mogelijkheid om een timer fallback te plannen bij een conflict... Zodat die op de timer van de fallback tuner komt ipv lokaal.... Dan weet je ook dat die opname moet lukken... Dan hoeven ook geen opties aan/uit, maar maak je een keuze.... Plannen op fallback tuner als je lokaal de timer niet geplanned krijgt... (Of de movie directory is dezelfde als die op de fallback tuner).

Edited by littlesat, 24 February 2015 - 23:45.

[WanWizard]

Ik hoef ook geen recording van de fallback, ik zou dan liever hebben dat de recording op de fallback receiver ingepland worden.

Hoeft al die data niet over het (niet altijd even betrouwbaar) netwerk...

[Rob van der Does]

Dat is precies wat ik al eerder heb gezegd: gebruik de RemoteTimer plugin (of de WEB-IF) om timers toe te voegen aan de server box. Dan wordt de SanityCheck doorlopen en gaat het altijd goed. en het gaat ook nog eens heel intuïtief.
Plus dat het veel overzichtelijker is om alle opnames in één timerlijst te hebben.

[WanWizard]

Yup, ik doe momenteel hetzelfde.

 

Maar het zou natuurlijk mooier zijn als dat geintegreerd gebeurde, en de timer code zelf naar de remote box gaat indien er geen lokale tuners gevonden worden EN er een fallback is geconfigureerd.

[Rob van der Does]

Dat gebeurt ook (al is het niet gerelateerd aan de tuner configuratie en/of het geactiveerd hebben van de fallback tuner): in de RemoteTimer plugin kan je aangeven dat timers default naar de server moeten gaan (de setting "Remote Timer-default' op 'yes' zetten).
Als je dat hebt ingesteld zie je in de eerste regel van een nieuwe timer 'Remote Timer - Yes' staan.

Als de clientbox ook eigen tuners heeft, kan je die instelling naar believen aanpassen om opnames lokaal te maken.

[Erik Slagter]

Ik wil recording wèl van de remote fallback. Beter een recording van de fallback dan géén opname (want dat gebeurt alleen als geen enkele tuner beschikbaar is). Beseffen jullie je dat wel?

 

Een tuner kan niet beschikbaar zijn omdat er een andere opname op loopt (dat is te voorspellen), maar ook omdat je ze gebruikt om te kijken, streamen, epgrefresh, PiP, fallback van een ándere client en vast nog wel een paar.

 

E.e.a. aftikken met een "remote timer conflict detection" is dus helemaal niet zinnig. Sterker nog, ik vind de huidige "lokale" conflict-detection al zwaar tekortkomen en en daardoor helemaal niet nuttig.

Edited by Erik Slagter, 25 February 2015 - 11:08.

[Erik Slagter]

Maar het zou natuurlijk mooier zijn als dat geintegreerd gebeurde, en de timer code zelf naar de remote box gaat indien er geen lokale tuners gevonden worden EN er een fallback is geconfigureerd.

Geen opname op tijdstip X garandeert niet dat op tijdstip X precies de goede tuner beschikbaar is...

[Erik Slagter]

Dat is precies wat ik al eerder heb gezegd: gebruik de RemoteTimer plugin (of de WEB-IF) om timers toe te voegen aan de server box. Dan wordt de SanityCheck doorlopen en gaat het altijd goed. en het gaat ook nog eens heel intuïtief.
Plus dat het veel overzichtelijker is om alle opnames in één timerlijst te hebben.

Ik gebruik geen timers. Ik gebruik alleen de autotimer. En die wil je niet verspreid over je huis.

[Rob van der Does]

Ik wil recording wèl van de remote fallback. Beter een recording van de fallback dan géén opname (want dat gebeurt alleen als geen enkele tuner beschikbaar is). Beseffen jullie je dat wel?

Ik begrijp niet wat je hier wilt zeggen.

Als je een timer op de serverbox maakt (hetzij lokaal, dan wel via de WEB-IF of vanaf een clientbox), doorloopt die de sanity check. Dat garandeert dat er tzt een tuner beschikbaar is voor de opname.
Als je een timer voor de fallback tuner maakt, heb je geen flets idee of er een tuner beschikbaar zal zijn. Bovendien heb je dan de timers verspreid door over allerlei boxen, waardoor je geen enkel overzicht meer hebt.

[WanWizard]

Ik moet zeggen dat ik het ook niet volg.

 

Als ik een client -> server constructie heb op basis van de fallback tuner, dan zal een opname alleen lukken (op om het even welke box) als de server box een tuner vrij heeft. Dus dat is in alle gevallen voorwaarde nummer 1.

 

En als dat zo is, dan heb ik liever dat de opname op de server loopt, naar de lokale disk (of whatever storage je gebruikt) dan dat de opname op de client loopt waarbij de data via de fallback tuner zonder buffering over het netwerk gesleurd moet moeten. En in mijn geval dan ook weer over het netwerk terug, want de client heeft geen eigen disk.

 

In dat laatste scenario is de kans om een opname met hickups en uitval (hier in ieder geval) 100%, in het eerste heb ik een perfecte opname op de disk van de server box.

 

Dus ik zie geen enkel voordeel in kunnen opnemen van een fallback stream, dat kun je in alle gevallen beter aan de bron doen.

[Erik Slagter]

Julie gaan er (kennelijk) van uit dat de fallback tuner altijd gebruikt wordt voor opnames. Wat niet het geval is. Het is een fallback tuner. Als er een vrije tuner op de client beschikbaar is, dan wordt die gebruikt. Als er geen vrije tuner is, dan wordt (ware het niet dat de conflict-detection dat nu verhindert) de opname vanaf de fallback tuner gestart. Als je geen fallback tuner zou hebben, zou je geen opname hebben, in dat geval.

 

Als je een client zonder eigen tuners hebt (ik niet, Wanwizard wel), dan is het slimmer om de timers en/of autotimers op de server te draaien, dat is een ander verhaal.

[WanWizard]

Ik heb geen vrije tuners, mijn clients zijn tunerloos.

 

Als er wel een tuner lokaal zou zijn, dan wil je opnemen op de box waarop je de timer zet lijkt me. En als deze niet beschikbaar is, dan zou je de opname (de timer entry) willen kunnen verplaatsen naar de server box. En niet via de fallback tuner lokaal opnemen.

 

Want dat levert uitsluitend in zeer optimale omstandigheden iets bruikbaars op (en die heb ik hier absoluut niet).

[Rob van der Does]

Ik heb inderdaad alleen maar clients zonder coax.

Maar dan nog: een timer doorloopt de sanity check. Dat gebeurt aan de hand van de eigen tuner en de reeds geplande opnames, niet zo van 'maar ik heb nog een fallback tuner, als het mezelf niet lukt ga ik die wel gebruiken'. En volgens mij moet dat vooral zo blijven, want de beschikbaarheid van de fallback tuner is zeer ongewis.

[kamei10]

Kan je als client box ook een vu zero gebruiken om zonder kabel te kijken ?