Opname op HD hapert

[Tonskidutch]

ik begrijp het elend...

maar ondanks dat ik soortgelijke haperingen had met 1.08 en radegast is nu NIETS meer aanwezig van een stotter of hapering op de 4xx dreambox..

 

let wel ik heb net na 1.08 menig maal een nieuw image volgens de facts erop gezet..

(met vooraf een eeraze image dus helemaal volgens de regels der kunst)

 

bepaalde plugins draai ik niet ( <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> eigenlijk geen plugins)

evocam scheen de oplossing maar draai toch lekker newcam de laatste en ook daar is het cardsharing (beter keys stelen) ingebouwd doch niet actief.

 

cheers

[M€®LïÑ]

inmiddels is mijn hd vervangen (deze werkte eerst probleemloos maar later happeringen) ik heb nu ook de eerste sesamstraat opgenomen (juist daarin barste het van de happeringen, meer als alle andere opname's die ik maak)

en tot nu toe nog geen happering... morgen weer een opname .. :-) we wachten af.

[M€®LïÑ]

tja ook vandaag geen happeringen meer met sesamstraat.

Ik denk dat het probleem idd aan de harddisk ligt, gek is wel dat e.a wel probleemloos werkten met de andere hd (samsung 80 gig 7200 toeren).

Maar goed ik blijf nog ff testen...

[Gast]

(Samenvatting: bij mij was het de Aston SECA CAM)

Omdat van de stap van 1.06 naar 1.07 opeens de Aston SECA moeilijk ging doen met netwerk traffic ben ik rond 1.07 op een ronaldd image gestapt, en heb via een softcam maar gekeken. Dit werkte perfect.

Omdat in 1.08 de netwerk behoorlijk zoog heb ik alsnog een harddisk toegevoegd. In 1.08.1 en 1.08.2 beta heb ik ontdekt dat ik heel veel happeringen had (en dus ook out-of-sync problemen). Ben toen overgestapt op PLI-3009, en heb de aston SECA er weer uitgehaald. Sindsdien geen haperingen meer.

Dus als je een officiele Aston SECA gebruikt zou ik daar ook eens naar kijken. Bepaalde CAMS werken gewoon niet goed samen met de DB (en dat zal wel aan de DB liggen). Ik weet wel dat de MM wel altijd goed heeft gewerkt (zonder haperingen dus en via nfs).

(En nu eens kijken hoe ik mijn officiele canaal digitaal en mijn officiele canal satellite kaart tegelijk in de DB kan gebruiken)

[M€®LïÑ]

Ik heb inmiddels al behoorlijk wat opname's gemaakt met deze nieuwe Harddisk enne..... geen problemen meer.

Kortom.. het lag dus niet aan de 108.x ook niet aan de serie 3 Dreambox want de serie 4 had dezelfde happeringen.

Ook de warmte was het probleem niet (kap eraf, extra koelrib geplaatst enz.)

Rest alleen nog een externe voeding (dat heb ik niet geprobeerd, vond dat moelijk te plaatsten).

Dus heb toen de laatste optie genomen... mijn Samsung 80 gig 7200 sp0802n vervangen voor een Seagate 380021a 80 gig 7200 toeren.

het probleem was daarmee direct verdwenen..

Dus tja, het kan dan alsnog een voedings probleem zijn, maar wat ik zo vreemd vind, mijn samsung heeft namelijk enkele maanden zonder happeringen gewerkt.

 

Maar goed een ieder die ook happering problemen heeft.. probeer ook eens een andere Harddisk, ik denk dat het zwakke punt van de dreambox is omdat dat het alles met warmte en spanning heeft te maken.

[Gast]

Merlin, zou het kunnen dat het met de nieuwe harddisk beter gaat omdat die vers geformatteerd, dus leeg, dus snel is? Ik krijg het idee dat opnemen met de dreambox niet alleen een voedings/warmte/stabiliteitsprobleem is, maar vooral vaak ook een snelheidsprobleem. Als de processor het te druk heeft, lijdt de opname daaronder. Vergelijk het met de 'buffer underruns' die je vroeger bij CD branden had.

 

Dat de ene softcam meer problemen geeft dan de andere wijst in die richting; de ene cam is waarschijnlijk efficienter geprogrammeerd, en geeft dus minder processorbelasting.

AU uitzetten: zelfde verhaal. Bij Autoupdate krijg je een extra processorbelasting wanneer er nieuwe keys binnenkomen.

Sesamstraat: volgens mij wordt die in zeer hoge kwaliteit (dus met hoge bitrate) uitgezonden. Dit zou je kunnen nagaan door te kijken hoeveel MB per minuut er opgeslagen wordt. Als je meer storingen krijgt naarmate het aantal MB/min. hoger is, dan ligt een snelheidsprobleem voor de hand.

 

Ik heb zelf net een 5620 gekocht. Opnemen daarmee gaat zeer moeizaam. Alleen over netwerk, want geen harddisk aan boord. FTA zenders gaan nog, al heb je dan regelmatig pixelfouten in de opname. Ik heb na flink zoeken nog niemand gevonden die met een 5620 een fatsoenlijke opname kan maken waar een softcam aan te pas komt.

 

De reden volgens mij: een 5620 heeft een andere PowerPC processor dan de 7000. Die van de 5620 mist de DMA die de processor ontlast tijdens het opnemen. Dus moet de processor al het werk zelf doen. Als-ie dan bezig is met de cam, mist-ie dus een stukje film. Ik denk dus dat ik mijn 5620 weer verkoop, en een 7000 koop.

 

Waar ik benieuwd naar zou zijn, is hoe het opnemen gaat op de oude harddisk als je die eerst vers geformatteerd hebt. Dan is de overhead voor het zoeken van plek voor de op te nemen programma's lager (schijf is nog niet gefragmenteerd), en zou ik dus minder problemen verwachten als mijn idee juist is.

 

Maar wie weet zit ik er wel totaal naast.

Als ik wat tijd kan vinden zou ik hier wel eens dieper in willen duiken.

Maar ja, eerst maar eens zien dat ik een 7000 krijg...

[Barabas]

Citaat:

Dat de ene softcam meer problemen geeft dan de andere wijst in die richting; de ene cam is waarschijnlijk efficienter geprogrammeerd, en geeft dus minder processorbelasting.
AU uitzetten: zelfde verhaal. Bij Autoupdate krijg je een extra processorbelasting wanneer er nieuwe keys binnenkomen.
Sesamstraat: volgens mij wordt die in zeer hoge kwaliteit (dus met hoge bitrate) uitgezonden. Dit zou je kunnen nagaan door te kijken hoeveel MB per minuut er opgeslagen wordt. Als je meer storingen krijgt naarmate het aantal MB/min. hoger is, dan ligt een snelheidsprobleem voor de hand.

De reden volgens mij: een 5620 heeft een andere PowerPC processor dan de 7000. Die van de 5620 mist de DMA die de processor ontlast tijdens het opnemen. Dus moet de processor al het werk zelf doen. Als-ie dan bezig is met de cam, mist-ie dus een stukje film. Ik denk dus dat ik mijn 5620 weer verkoop, en een 7000 koop.

De processor heeft niets te doen in de 7000 zie hieronder... gebruik hiervoor het tooltje 'top' in een telnet sessie!

Code:

Mem: 29104K used, 736K free, 0K shrd, 4452K buff, 11908K cachedLoad average: 0.00, 0.00, 0.00    (State: S=sleeping R=running, W=waiting)  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND  565 root     R        660   563  1.1  2.2 top  406 root     S N     6192   405  0.0 20.7 enigma  379 root     S       6192   336  0.0 20.7 enigma  508 root     S N     6192   405  0.0 20.7 enigma  405 root     S       6192   379  0.0 20.7 enigma  460 root     S       6192   405  0.0 20.7 enigma  563 root     S        652   562  0.0  2.1 sh  529 root     S        448     1  0.0  1.5 newcamd  562 root     S        388   299  0.0  1.3 telnetd  542 root     S        372   527  0.0  1.2 cs_clnt  299 root     S        364     1  0.0  1.2 inetd  327 root     S        240   138  0.0  0.8 daemond  526 root     S        240   327  0.0  0.8 daemond  527 root     S        208   526  0.0  0.6 cs_clnt  138 root     S        204   137  0.0  0.6 rcS    1 root     S        200     0  0.0  0.6 init  137 root     S        200     1  0.0  0.6 init  336 root     S        196   138  0.0  0.6 start_enigma  528 root     S        112   327  0.0  0.3 sleep

[Gast]

Oke, hier de uitvoer van mijn 'top':

Code:

Mem: 19420K used, 11332K free, 0K shrd, 3304K buff, 7068K cachedLoad average: 1.17, 1.11, 0.73    (State: S=sleeping R=running, W=waiting)  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND   76 root     R        648    74  1.1  2.1 top    2 root     SW         0     1  0.1  0.0 keventd   39 root     S       7420    10  0.0 24.1 enigma   43 root     S N     7420    42  0.0 24.1 enigma   72 root     S N     7420    42  0.0 24.1 enigma   45 root     S       7420    42  0.0 24.1 enigma   46 root     S       7420    42  0.0 24.1 enigma   42 root     S       7420    39  0.0 24.1 enigma   74 root     S        644    73  0.0  2.0 sh   38 root     S        624     1  0.0  2.0 dccamd   33 root     S        524     1  0.0  1.7 inetd   10 root     S        480     9  0.0  1.5 rcS    1 root     S        476     0  0.0  1.5 init    9 root     S        476     1  0.0  1.5 init   49 root     S        456    39  0.0  1.4 udhcpc   73 root     S        360    33  0.0  1.1 telnetd    7 root     SW         0     1  0.0  0.0 mtdblockd   16 root     SW         0     1  0.0  0.0 fe_thread    3 root     SWN        0     1  0.0  0.0 ksoftirqd_CPU0    4 root     SW         0     1  0.0  0.0 kswapd    5 root     SW         0     1  0.0  0.0 bdflush    6 root     SW         0     1  0.0  0.0 kupdated   15 root     SW         0     1  0.0  0.0 ci_poll   17 root     DW         0     1  0.0  0.0 avwdt   22 root     SWN        0     1  0.0  0.0 jffs2_gcd_mtd1

(Vraagje: hoe krijg je in dit board een fixed width fontje voor je listings?)

 

Hm, wel raar: een load van ongeveer 1 bij nog geen 2% CPU totaal. Maar de gemiddelde processorbelasting is niet zo'n probleem; het is eerder de latency. Als een proces gedurende een korte tijd de processor volledig claimt, kan hij in die tijd niets anders doen. Ik weet niet of het opneem-proces met realtime priority draait, of dat het gewoon als de andere processen gescheduled wordt. En ik weet ook niet hoe vaak de processor (eventjes) nodig is als je aan het opnemen bent. En hoe lang een cam aan het rekenen is als er een key gedecrypt moet worden... Het probleem is dat je bij het opnemen met realtime processen bezig bent. Als je maar 1 ms te laat bent met het afhandelen van een binnenkomend datapakketje, ben je hel kwijt, tenzij er een goede hardwarebuffer is.

[M€®LïÑ]

Ik heb natuurlijk al meerdere keren die eerste HD geformateerd (met de DB) maar dat heeft niet geholpen..

Ik heb deze HD nu in de pc zitten... ik zal hem er nog eens uithalen en opnieuw formateren met linx (er staat nu ntfs op) dan is die HD tenminste een paar x met verschillende systemen geformateerd en kan het daar niet meer aan liggen.

 

Ik kom er op terug.. nu ff niet het loopt net lekker...

[Tonskidutch]

heel interressant die stelling...

Mem: 25928K used, 3912K free, 0K shrd, 2560K buff, 9312K cached

Load average: 0.22, 0.06, 0.02 (State: S=sleeping R=running, W=waiting)

 

PID USER STATUS RSS PPID %CPU %MEM COMMAND

1488 root R 664 1485 16.8 2.2 top

239 root S 9992 148 0.0 33.4 enigma

292 root S N 9992 242 0.0 33.4 enigma

243 root S N 9992 242 0.0 33.4 enigma

246 root S 9992 242 0.0 33.4 enigma

242 root S 9992 239 0.0 33.4 enigma

1440 root S 1024 1 0.0 3.4 newcamd.ppc

1476 root S 1024 1441 0.0 3.4 newcamd.ppc

1441 root S 1024 1440 0.0 3.4 newcamd.ppc

1486 root S 744 1483 0.0 2.4 in.ftpd

1483 nobody S 684 214 0.0 2.2 in.ftpd

238 root S 664 148 0.0 2.2 emubroker

1485 root S 632 1482 0.0 2.1 sh

1438 root S 508 1 0.0 1.7 cardserver.drea

148 root S 492 145 0.0 1.6 rcS

1 root S 460 0 0.0 1.5 init

145 root S 460 1 0.0 1.5 init

 

in standby

 

uh dus wat nu

 

cheers

[Gast]

Citaat:

heel interressant die stelling...
Mem: 25928K used, 3912K free, 0K shrd, 2560K buff, 9312K cached
Load average: 0.22, 0.06, 0.02 (State: S=sleeping R=running, W=waiting)

uh dus wat nu

cheers

Ah, een 7000 zeker? Load van bijna 0, tegen 1 bij die 5620 van mij.

Maar als het probleem ligt waar ik denk dat het ligt, dan worden we hier niet wijzer van.
Dan is namelijk niet de gemiddelde load (die top aangeeft) van belang, maar de latency, dus hoelang een bepaald proces incidenteel zonder processortijd kan komen te zitten.
Als ik mijn 7000 heb, wil ik eens kijken hoeveel moeite het kost om zelf wat testprogrammatjes te schrijven. Linux met gcc heb ik, nu nog de omgeving om code voor de PowerPC en de libs van de Dreambox te kunnen maken.

[Gast]

Ik heb mijn 5620 nog even niet teruggestuurd, en ben nu een PowerPC crosscompiler aan het bouwen zodat ik nog even wat testjes kan doen.

Ik wil bijvoorbeeld even kijken of ik ngrab kan renicen zodat-ie met hogere prioriteit draait.

Geen idee of dat zal helpen, maar een testje lijkt me geen kwaad kunnen. Ben benieuwd!

 

Hm, nu ik kijk hoe die ngrab gestart word, zie ik dat het een loadable module is.

Lijkt er dus op dat-ie niet als afzonderlijk proces gestart wordt, en dus niet apart te renicen valt.

Helaas, volgende idee...

[Pirahna]

ik ben eigenwijs en ga niet meteen naar een andere HD.

vorige week had ik ook , (na pli 3009 erop geknalt te hebben) problemen met haperende opnamen. het geluid loopt wel door maar het beeld geeft dus de haperingen.

de hd is een seagate 7200 toeren 120 Gb.

de nieuwe software (pli 3009) blijkt niet helemaal samen te gaan in combinatie met de HD. daarom de oude ronald image van 28 12 2003 er weer opgezet en hij loopt, vooralsnog, weer als een trein.

[belened]

Ik had zelf tot 15/10 geen problemen met opnames.

 

Dreambox met sn 4.x

Samsung SV0802N 80G

Pli 3009

SCAM_CS

 

Op 15/10 keys geupdate en op sommige, niet alle, kanalen haperingen bij de opnames.

Van wat ik heb kunnen testen, alleen problemen met franse kanalen TCM fr, TPS. Op het duitse board wordt dit ook ondervonden.

Andere kanalen Canal rood, TCM sp, ... geen problemen.

 

Door Newcamd_CS te selecteren als EMU en AU = No, lijken op alle kanalen de problemen voorbij <img src="/ubbthreads/images/graemlins/smile.gif" alt="" />

 

Uit alle voorgaande reacties blijkt dat er niet een eenduidige oplossing voor het probleem is.

 

Vraag: waar kan ik meer informatie over die extra voeding vinden?

[M€®LïÑ]

na het wisselen van HD heb ik geen problemen meer.

Probeer eens die hd te formateren met je pc (naar ntfs)

 

Ohja ik had ook een samsung SP802n... toeval ?

dan in de DB opnieuw formateren.. ik heb namelijk het idee de DB niet netjes formateerd...