MiLo

De bouwserver is nog druk images en feeds aan het bakken, en waarschijnlijk zijn de feed servers ook nog niet in sync.

After integrating the mailine OpenEmbedded core changes to fix a few versioning problems, tomorrow upgrade will be huge again. You'll see something like 300+ upgradable packages.

My advise: Reflash, it's much quicker than running through the upgrades.

- op de smartcard: kaart uithalen en met tissue voorzichtig een paar keer de chip  afvegen.

Tip: Smartcard contacten (en meer van die dingen met koperen strips, zoals PC insteekkaarten) kun je het beste schoonmaken met een gum. Gewoon zo'n zachte gum om potlood mee te wissen.

Erik, da's onzin, *Windows* ondersteunt al heel lang UTF-8 (en ook UTF-16 en nog veel meer), en heeft nog nooit enige eis gesteld aan karaktersets.

Van gebras met encoding moet je gewoon de betreffende applicatie de schuld geven.

/media is in RAM, hence volatile, which means it will not survive a reboot.

Either use enigma2 to mount, or use /etc/fstab to create the mounts. Both will automatically create folders as needed.

Otherwise, you'll have to create a "volatile" package to pre-populate the /media/ RAM filesystem.

The "overlapping" problem will go away on its own if you're just a bit patient. I intend to fix it in the EPG handling code, so you won't need hacks like that.

The cause of the versioning weirness is in openembedded-core. Here's a link to the patch that will fix it:

http://lists.openemb...ary/100593.html

If you want to get rid of the messages, just re-flash. Otherwise, wait until that patch has been merged into OE.

The cause of the versioning weirness is in openembedded-core. Here's a link to the patch that will fix it:

http://lists.openemb...ary/100593.html

If you want to get rid of the messages, just re-flash. Otherwise, wait until that patch has been merged into OE.

Hilarious - all that effort to install a plugin from an author known to add extra "features" to his code, just to be able to create a "backup".

It's like building a wall around you for protection by stacking gunpowder kegs...

Wouldn't it be much simpler to just keep a copy of your previous firmware around, along with the plugins you really want, and a backup of your settings. creating and restoring that would take less time than what you've spent on this already.

Dit stukje vond ik ook wel cool en heb ik zelf ervaren toen ik eens "vreemd" ging... Vooral de uitleg waarom dit komt....
 

Nog wat tijden: een volledige herstart ging in 48 seconden, een Enigma-herstart in 10 
seconden. 
 
De ervaring in zappen etcetera met OpenATV is identiek aan die van OpenPLi. Wel is de 
reboot-tijd wat langer (1.04 minuut) en de Gui herstart (19 seconden). Maar OpenATV is ook 
een ‘zwaarder’ image.

Met het gewicht van het image heeft de boottijd weinig te maken. De standaard OpenPLi plugins gebruiken allemaal een constructie waarbij de plugin zich alleen maar registreert bij het opstarten, maar verder nog geen code en data laadt tot die echt gebruikt wordt. Dat scheelt veel tijd bij opstarten van Enigma2. Ook intern in E2 is daar aandacht aan besteed. Plugin programmeurs die zich daar niet aan houden kunnen makkelijk vele onnodige seconden aan de laadtijd toevoegen, evenals wijzigingen in de "core" van E2.

Het kan allemaal nog wel sneller, zo kan netwerkinitialisatie en een aantal andere zaken worden aangestuurd vanuit Enigma, dan hoef je er bij het starten niet op te wachten (want ook zonder netwerk kun je TV kijken) en start de GUI eerder op.

Als alles goed loopt vannacht zit in de upgrade morgen een nieuwe "C" library, de onderste regionen van de software, waardoor bijna alles opnieuw gebouwd is. Resultaat is dat dus ook bijna alle pakketten worden bijgewerkt in een online upgrade. Dus verwacht een melding dat er 300 pakketten te upgraden zijn.

Aangezien ook netwerk componenten worden bijgewerkt, zal de upgrade halverwege falen omdat het netwerk herstart tijdens het downloaden. Dat kan geen kwaad verder, wacht gewoon op de reboot en start de upgrade opnieuw op. Het kan zijn dat dit meer dan eens moet.

Op zich zal het morgen sneller zijn om de hele box opnieuw te flashen dan de upgrade te draaien.


O ja, en als je via telnet of SSH probeert te upgraden gaat het helemaal lomp mis omdat ook telnet en ssh worden vervangen...

The most interesting choice to make here is what key to use for selecting items?

(the obvious choice would be "ok", but that's not really an option. Maybe the "0" key?)

The rest is simply a matter of adding a "selected" box to the items and giving an iterator to the callbacks.

Maybe the movie list should have "modes" for several things, like "file management", "movie selection", "audio playback" etc.

By the way, if you want to "round" the outcome, add half the divider:

 

kHz = (MHz + 500)/ 1000

 

That will work better than the "+1" later on.

1/2 delivers an integer result in Python, hence it's "0". If one of the numbers is a floating point, it will use floating point output.

 

>>> 1/2
0
>>> 1.0/2
0.5
>>> 1/2.0
0.5

So use "1000.0" instead of "1000" and it'll probably do as you expect.

Laat ik nou net bi-wiring gebruiken
Ik vond 't daarom wel interessant om 't artikel te lezen.

Bi-wiring, dus het verbinden van de (enkele) uitgang van je versterker met twee kabels naar de speakers, is totaal onzinnig. Het is helemaal nergens op gebaseerd. Je kunt beter stellen dat kabels die door elfjes bij maanlicht zijn gesmeed veel beter klinken, want dat kan niemand weerleggen.

Ze stellen dat bi-wiring onzin is en baseren zich op lineaire systemen. Nu vraag ik me af of een versterker en luidsprekers wel lineair zijn. Alleen al omdat er tegenkoppeling is, is het hele systeem al niet lineair en gaat dat superpositie-beginsel (hun argument) al helemaal niet op.

Ik heb echt geen flauw idee wat je met deze opmerking bedoelt. Tegenkoppeling speelt hier geen rol, dat gebeurt in de versterker, en tegenkoppeling maakt een systeem juist beter lineair.

Een "lineair systeem" is niet een of ander wazige kreet waar alleen wiskundigen mee spelen ofzo. Een audio systeem is het beste voorbeeld van een lineair systeem dat ik zo snel zou kunnen bedenken.

Maar goed, praktisch: een woofer is gebaat bij dikke kabels omdat er relatief veel vermogen in de lage tonen zit. De tweeter is echter gebaat bij een kabel met weinig capaciteit. Capaciteit is funest voor hoge tonen en er zit bovendien nauwelijks vermogen in de hoge tonen. Het sluit elkaar wel uit: dikke kabels hebben ook meer capaciteit. Ik kan me dus goed voorstellen dat je met bi-wiring twee verschillende kabels gebruikt: eentje die beter is voor tweeters en eentje die beter is voor woofers.

De capaciteit van een 2,5 mm dikke koperen kabel ligt nog steeds in de orde van enkele pico-farads. Dat gecombineerd met de impedantie van enkele Ohms van de speaker levert je een cut-off frequency in de orde van gigahertzen op. Ja, dat betekent inderdaad dat je die dikke luidsprekerkabel prima kunt gebruiken voor transport van bijvoorbeeld satelliet signalen of ethernet. Daar heb ik al weddenschappen over gewonnen bij een ander satelliet forum, waar iemand het gewoon geprobeerd heeft. Die 20kHz die je tweeter moet weergeven (en die je oren niet kunnen waarnemen) heeft echt geen last van een systeem dat pas bij de gigahertz begint te dempen.

Bi-wiring kan ook geen kwaad. Zelfs als je de kabels niet even lang maakt heeft het geen enkel effect. Pas bij een verschil in lengte van enkele kilometers begint er een faseverschuiving op te treden in de orde van een procent die dan misschien wel hoorbaar zou kunnen zijn.