Erik Slagter

Wat was eigenlijk de changelog van deze versie van de drivers, weet iemand dat? Schieten we er zowiezo iets mee op?

Dit is allemaal driver-kwestie... Dus was je eigenlijk zou moeten doen is een origineel dmm image flashen, kijken of het probleem dan optreedt en zoja, een bugmelding maken bij dmm.

Ach een smilie ontgaat je en meteen weer een -1, kinderachtig hoor

Ja inderdaad door die smiley is de ernst (of de afwezigheid daarvan) wel duidelijk. +1 van mij.

Ik vind dat "mikken" anders helemaal niet moeilijk (ook niet op een wolkenloze dag)... gewoon alle vrijheden met hele kleine slagjes variëren en kijken wat voor effect het op de SNR heeft. Ik geloof er niks van dat er mensen zijn die 100%/18 dB SNR hebben en dan ook nog hun schotel kunnen draaien!

Je begint met de grote hoeken: de schotel links/rechts, op/neer, dan de lnb's (per stuk) op-en-neer en als laatste per de lnb de draaiing. Dan kun je weer van voor af aan beginnen, maar de schotel blijkt dan meestal toch wel optimaal te staan. En als je dan een gare BiSat hebt (zoals ik), dan kan de arm ook nog eens een centimeter zwabberen, dus als je daar toevallig tegen aan tikt, kun je overnieuw beginnen :-(

Ik blijf er bij, het is een kwestie van geduld en perfectionisme. Ik zal ook geen last hebben van een 8PSK transponder...

I am sorry once again, but troubles with bootloaders/second stage firmware, always remind me of clone boxes...

En nog even helemaal terugspoelen naar de eerste post. Er wordt hier gesproken over "linux3" en er wordt (impliciet) gesuggereerd dat een enorme sprong vooruit is boven de 2.6 kernels. Dit is absoluut niet het geval! Linux 3.0 bestaat omdat Linus Torvalds het wel eens tijd vond voor een nieuwe versie na 2.6.39. Het verschil tussen 2.6.39 is 3.0 is MINIEM. Het verschil tussen linux 2.6.18 en linux 2.6.35 is daarentegen iets van acht jaar ontwikkeling, in computertermen een eeuwigheid.

Met andere woorden: 2.6.18 = antiek, zowel 2.6.35 als 3.0 zijn bij de tijd. Dus de kernels van DMM zijn echt antiek, die van CT zijn netjes bij de tijd, ook al zijn ze geen 3.0.

Heeft niks met avi te maken. Materiaal (meestal illegaal verkregen ) uit de VS is meestal 24 fps. Dat is dan "puur" bioscoop-rate of met 3:2 pulldown gedeinterlaced vanaf 29.97 fps (normaal in de VS) naar 23.98 fps.

Als je dat gaat afspelen op je "25 fps" apparatuur, dan moet de stb na elke 24 frames één dupliceren omdat je anders niet uitkomt. Je kunt dat goed zien in scenes met veel beweging, het hikt dan telkens even.

Als je televisie 24 fps kan afspelen (dat is dan meestal als 1080p24 "BluRay" mode), dan kun je dit soort films afspelen zonder hikken omdat er geen frames gedupliceerd hoeven te worden. Autoresolution heeft daar twee instellingen voor, de "echte" BluRay 1080p24 mode voor films die in dat formaat zijn opgenomen. Daarnaast nog de 24 fps "SD" mode, waarbij "SD" materiaal, dat toevallig 24 fps is, ook als "BluRay 1080p24" aan de tv wordt aangeboden, dat is voor films zoals ik hierboven heb beschreven. De TV moet dan wel zelf upscalen naar 1080.

Om een lang verhaal kort te maken: als je televisie geschikt is voor het weergeven van 1080p24 BluRay films, dan zet je deze optie aan, en anders uit.

Uitzending gemist heeft zo z'n nadelen en dat weet je best jeroen .

De oplossing van MiLo is best slim. En anders zou er een extra suboptie onder "file-naam formaat" moeten komen "laat datum en tijd weg en overschrijf bestaande file", volgens mij is dat op zich best simpel te maken. Of anders (en daar ben ik meer in thuis) een cron-scriptje. Maar nogmaals, ik zou eerst eens die oplossing van MiLo proberen.

Dat is geen oplossing, enkel symptoombestrijding....

Mee eens, maar er is weinig keus voor ons gewone stervelingen, wij kunnen niet aan het knopje bij de bron draaien

Yep, dit komt mij zéér bekend voor.

Zo zie ik het niet, da's gewoon iemand met gezond doorzettingsvermogen

Analoog is altijd ellende, altijd brom, ruis, aardlussen. Ik kan me voorstellen dat je liever alles digitaal optisch koppelt.