13 replies to this topic

[BCW]

Ik heb zaterdag een NAS geinstalleerd - WD MyBook Live 2 Tb. Een van de problemen waar ik tegen aanloop is dat het vertraagd afspelen (chase play) niet goed werkt. Als ik een opname start en hem -tijdens de opname - afspeel, komen na een paar seconden de radertjes in beeld en is het systeem een aantal minuten bevroren. Dit werkt wel goed op de ingebouwde harddisk. Ik kan ook bestanden die al eerder zijn opgenomen op de NAS afspelen. Ik heb het zowel met CIFS als met NFS geprobeerd. Het probleem doet zich zowel op mijn VuPlus Duo als op mijn ET9000 voor.
Heeft iemand een suggestie?
Bedankt!
Ben

Edited by BCW, 6 May 2013 - 07:36.

[MiLo]

Het probleem heeft te maken met het steeds opvragen van de "lengte" van een opname. Op een lokale disk merk je dat niet, die data heeft hij net naar disk geschreven en staat dus nog in de cache. Op een remote disk moet hij steeds wachten op antwoord van de server en dat blokkeert de boel.

Heb nog geen passende oplossing bedacht die voor allebei de situaties goed werkt (opmerking: De box weet niet dat hij over het netwerk speelt, dus een truukje om andere dingen te doen in het geval van netwerk schijven is niet reeel).

Ik zat te denken in de richting van dat een lopende opname wel heel waarschijnlijk groeit met een seconde per seconde. Dus een boel rekenwerk kan dan achterwege gelaten worden.

[WanWizard]

Ik doe dat regelmatig, maar heb daar nog geen echte problemen mee ondervonden (anders dan af en toe een buffer-hikje), op zowel de ET9000 als de VU+Duo.

 

Verschil is wel dat ik geen NAS heb, maar een echte server (met een Core i7 er in ).

[Stephan296]

Ik heb hetzelfde probleem maar hier nooit een oplossing voor gevonden.
Dit was ook op een server en geen nas.
Ik irriteerde mij er aan en heb er een hdd ingebouwd. Bij opnames tot 20 minuten was het geen probleem maar daarna wel.

[catastrofus]

Ho, wacht, niet een nas van wdc gelijk trekken aan die van Synology of Qnap graag. Mijn ervaring met een nas van WDC is ruk, ding (4 x 1 TB, raid 5) bleef haperen maar de huidige (niet wdc) nas'sen doen het prima icm nfs!

 

 

Het probleem heeft te maken met het steeds opvragen van de "lengte" van een opname. Op een lokale disk merk je dat niet, die data heeft hij net naar disk geschreven en staat dus nog in de cache. Op een remote disk moet hij steeds wachten op antwoord van de server en dat blokkeert de boel.

Heb nog geen passende oplossing bedacht die voor allebei de situaties goed werkt (opmerking: De box weet niet dat hij over het netwerk speelt, dus een truukje om andere dingen te doen in het geval van netwerk schijven is niet reeel).

Ik zat te denken in de richting van dat een lopende opname wel heel waarschijnlijk groeit met een seconde per seconde. Dus een boel rekenwerk kan dan achterwege gelaten worden.

[BCW]

Duidelijk. Bedankt voor de input. Een beperking waar we - voorlopig in elk geval - rekening mee moeten houden.

[catastrofus]

Als ik jouw probleem zo lees dan lijkt het veel op de problemen die ik heb gehad om een (volgens wdc fatsoenlijke) nas bruikbaar te maken icm een dm.

Is mij niet gelukt met 2 dm7025+'n, met dus alleen sd opnames, zelfs dat werkte niet 100%. Ik ben toen geswitched naar Synology's en dat werkt heel behoorlijk.

Ik wil dus niet zeggen dat een huidige wdc nas per definitie ruk is maar als ik jouw klacht zo lees is er blijkbaar weinig veranderd sinds mijn ervaring met wdc van wat jaren terug.

[BCW]

Ik heb nog niet uitvoerig kunnen testen, maar tot dusver is het niet-goed-vertraagd-afspelen het enige probleem waar ik tegenaan ben gelopen. Vanmorgen heb ik drie HD streams - een vanaf de VuPlus, twee vanaf de ET9000 - zonder problemen opgenomen en later afgespeeld.

[BCW]

Vanmorgen heb ik nog een test gedaan. Drie simultane HD opnames vanaf de VuPlus naar de WD, drie vanaf de ET9000, en tegelijk op zowel de ET9000 als op de VuPlus (verschillende) bestaande opnames vanaf de WD disk afgespeeld. Niet kwaad (of is het ruk?) vind ik.

Ben

[BCW]

Het probleem heeft te maken met het steeds opvragen van de "lengte" van een opname. Op een lokale disk merk je dat niet, die data heeft hij net naar disk geschreven en staat dus nog in de cache. Op een remote disk moet hij steeds wachten op antwoord van de server en dat blokkeert de boel.Heb nog geen passende oplossing bedacht die voor allebei de situaties goed werkt (opmerking: De box weet niet dat hij over het netwerk speelt, dus een truukje om andere dingen te doen in het geval van netwerk schijven is niet reeel).Ik zat te denken in de richting van dat een lopende opname wel heel waarschijnlijk groeit met een seconde per seconde. Dus een boel rekenwerk kan dan achterwege gelaten worden.

Het zou erg mooi zijn als het systeem niet bevroor, als het op een respons staat te wachten. Kun je de calls niet non-blocking maken? Ik neem aan dat het systeem multiple threads support...

[catastrofus]

Dan heeft WDC zijn lesje goed geleerd. Prima toch en goed voor mij om m'n ervaring, met WDC-spullen van vroeger, te herzien.

 

 

Vanmorgen heb ik nog een test gedaan. Drie simultane HD opnames vanaf de VuPlus naar de WD, drie vanaf de ET9000, en tegelijk op zowel de ET9000 als op de VuPlus (verschillende) bestaande opnames vanaf de WD disk afgespeeld. Niet kwaad (of is het ruk?) vind ik.

Ben

[MiLo]

Het probleem heeft te maken met het steeds opvragen van de "lengte" van een opname. Op een lokale disk merk je dat niet, die data heeft hij net naar disk geschreven en staat dus nog in de cache. Op een remote disk moet hij steeds wachten op antwoord van de server en dat blokkeert de boel.Heb nog geen passende oplossing bedacht die voor allebei de situaties goed werkt (opmerking: De box weet niet dat hij over het netwerk speelt, dus een truukje om andere dingen te doen in het geval van netwerk schijven is niet reeel).Ik zat te denken in de richting van dat een lopende opname wel heel waarschijnlijk groeit met een seconde per seconde. Dus een boel rekenwerk kan dan achterwege gelaten worden.

Het zou erg mooi zijn als het systeem niet bevroor, als het op een respons staat te wachten. Kun je de calls niet non-blocking maken? Ik neem aan dat het systeem multiple threads support...

 

Waarschijnlijk is het de "skin" die vraagt om de lengte van de opname. Dit gebeurt dus vanuit de UI thread, en daarom blokkeert 't nu. Het ophalen van de data en afspelen ervan gebeurt wel in een andere thread.

 

De oplossing voor het haperen van de UI is dus om dit los te koppelen.

[BCW]

Het zou natuurlijk mooi zijn als er in de UI thread helemaal geen blocking calls zouden voorkomen die lang weg kunnen blijven. Het komt toch met enige regelmaat voor dat ik het systeem hardwarematig moet herstarten. Maar dat is mogelijk te ingrijpend...

[MiLo]

Het zou natuurlijk mooi zijn als er in de UI thread helemaal geen blocking calls zouden voorkomen die lang weg kunnen blijven. Het komt toch met enige regelmaat voor dat ik het systeem hardwarematig moet herstarten. Maar dat is mogelijk te ingrijpend...

 

Het is eigenlijk de basis achter het hele bouwwerk (twisted). Geen blocking calls op de main thread.

 

Er zijn legio plugins die gewoon een "os.system()" doen of files openen of URLs via curl op de main thread, en daarmee dat hele idee om zeep helpen. En via verkapte omweggetjes, zoals de vreselijke skin structuur, kunnen er andere dingen toch op de main thread terecht komen. Dat merk je als je de opnamelijst opent, die blokkeert ook de boel omdat de skin om de file data vraagt.