Extra/alternatieve oplossing haperende HD opnames?

[Gast]

Hi guys,

 

ik heb reeds verteld in een vorig topic dat mijn recordings op HD steeds hier en daar blokken en haperingen vertonen. Met externe voeding of niet, maakte geen verschil. Overlaatst was ik nog wat aan het experimenteren en zag ik in de logging console (of via dmesg) dit hier regelmatig verschijnen:

 

[XP1] buffer overflow free: 144 len: 188

 

Om te kijken of jij ook overflows krijgt, voer dit commando af en toe uit wanneer je een recording neemt:

dmesg | grep XP1

 

Als mijn recorded TS stream hier en daar een TS pakketje mist dan is het logisch dat mijn recordings niet fantastisch zijn. Dus ben ik effe op zoek gegaan naar die buffer waar hij het over heeft. Als ik hem groter zou maken dan zou het probleem wel eens kunnen verdwijnen. In record.cpp (van enigma) zag ik dit staan:

::ioctl(dvrfd, DMX_SET_BUFFER_SIZE, 1024*1024);

Dit stuurt hij naar het dvr1 device. Toen heb ik de dream.o gepatcht om de buffersize te forceren op 2 Mbyte. Maar om een of andere reden lijkt enigma die ioctl niet te doen. Normaal schrijft dream.o een XP1 log regel uit maar dit gebeurde dus niet. Enfin, op zoek naar een andere mogelijkheid.

 

In dream.o vond ik de allocatie van een dvr_buffer in functie xp1_DmxDevDVROpen(). Kijkende naar de andere XP1 en DVR functies leek met dat wel de goede buffer te zijn. In die functie wordt er 512 Kbyte gealloceerd voor die buffer. Bij wijze van experiment heb ik dan nog eens een patch geprobeerd: forceren op een allocatie van 2 Mbyte oftewel 4 maal zoveel buffersize.

 

En voila, geen overflows meer (of toch een pak minder). Nu kan ik zonder schokken opnemen <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> Ik zeg zeker niet dat dit een oplossing is voor iedereen, maar alleszins wel voor mij. De HD in kwestie is een ouder geval: een Quantum Bigfoot 1 Gbyte die hier nog ergens lag. Het beste is nog steeds een door dream goed gekeurde HD te gebruiken <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

 

Patch info:

3c 00 00 08 lis r0,8

90 0b 00 04 stw r0,4(r11)

38 00 07 c2 li r0,1986

90 01 00 18 stw r0,24(r1)

3c 60 00 08 lis r3,8

 

==>

 

* 3c 00 00 20 lis r0,32

90 0b 00 04 stw r0,4(r11)

38 00 07 c2 li r0,1986

90 01 00 18 stw r0,24(r1)

* 3c 60 00 20 lis r3,32

 

Greetz

 

[rebootje]

Het is volgens mij geen slecht idee om jouw aan het Dream Multimedia Software Development Team (mondvol) toe te voegen.

 

rebootje

 

 

 

[Gast]

@TeeBee

 

Yep ik dacht wel dat mijn harde schijf te traag was. Maar het is geen uitstel van executie. De grotere buffer vangt plotse vertragingen op, al dan niet veroorzaakt door mijn tragere harde schijf. Daar waar ik vroeger regelmatig een reeks pakketjes na elkaar verloor, verlies ik er nu geen of af en toe nog eentje. Hoe dan ook, in de praktijk werkt het hier bij mij nu beter.

 

Ik realiseer mij wel dat dit een oplossing is voor mijn specifiek probleem: een trage harde schijf.

 

Citaat:

Je hebt trouwens wel een behoorlijk goed idee van de werking van dream.o merk ik wel:)

 

Dat idee zou nog beter zijn als ik de C source zou hebben. Misschien is dat nog eens een idee. Een onafhankelijke open-source C versie maken.

 

Greetz

[Gast]

om nog even op die hdd door te gaan ik heb last van beeld

dan niet bij het geluid past ( ze lopen niet gelijk ) raar hè

 

mijn hdd is 7200 rpm razend snel dus hoe kan dat <img src="/ubbthreads/images/graemlins/confused.gif" alt="" />

[Gast]

spoel in de film een iets na voren of terug.

 

daar los ik het hier altijd mee op.

 

komt hier trouwens ook alleen voor als ik hem op pause heb gehad.

[pukje]

Dit (m)alloc mem probleem bij opnemen heb ik al voor weken

op de bugtrekker gezet en daar werd het afgedaan met

exfs3 is te traag ,bij jou wordt gezegd de hd is te traag

 

ik gebruik een door dream goedgekeurde hd (maxtor) .

 

Ik ben er zeker van dat het een bug in dream.o is.

 

blijkbaar is dream.o heilig ,en de source van dream.o zal ook

wel nooit beschikbaar komen ,ik heb zo wel mijn gedachtes waarom.

 

pukje