Paretje's blog

Blog

04/05/2014, 01:50
Zaterdag wou ik, toen ik aankwam in Gent nu eindelijk ook op mijn Raspberry Pi beveiligen met iptables. In principe is er welliswaar niets overbodig aanwezig, maar stel nu dat dit wel het geval is? Of dat ik op een gegeven moment een nieuwe service installeer? Dan is het misschien toch veiliger dat die onbereikbaar blijft van buitenaf, tot alles volledig is ingesteld. Of wat als ik op een gegeven moment een andere gebruiker op mijn server toelaat? Dan is het toch zo leuk dat die niet per ongeluk een service zou kunnen starten op een poort > 1024, of in ieder geval niet zichbaar zou zijn van buitenaf. Ook een eventuele exploit zou op die manier echt wel root-rechten moeten verkrijgen voor het een voor de buitenwereld toegankelijke server kán starten ...

Enfin hoe dan ook, baadt het niet dan schaadt het niet zullen we maar zeggen ... Maar, toen ik en eerste versie van de iptables file wou inladen (de versie die ik gebruik op mijn virtuele server thuis, en die nog geen rekening hield met de e-mailservices (om eerlijk te zijn, ik had er niet meer aangedacht om die ook open te zetten ;)), kreeg ik een error dat bepaalde modules niet gevonden konden worden in /lib/modules/... Even zoeken bleek dat dit met de firmware van de Raspberry Pi zou te maken hebben, en ik installeerde rpi-update, en voerde die vervolgens uit.

Op het einde werd gevraagd om te herstarten zodat alles opnieuw geladen kon worden (achteraf gezien, via een modprobe commando had het waarschijnlijk ook wel gelukt), en dat deed ik ook. Alleen ... hij kwam niet meer te voorschijn. Dus ofwel is de verbinding met het netwerk niet in orde, ofwel is er een probleem met de firmware, ofwel is het herstarten gewoon ergens blijven steken ... Ik heb danook een ticket aangemaakt bij PCextreme. Maar, voor de Raspberry Pi's is er geen 24/24 onderteuning (niet dat ik het hen kwalijk neem, het is uiteindelijk een gratis service. Ik dacht dat w nu zouden moeten betalen, maar op de factuur vorige maand stond een bedrag van 0 euro wat de Pi betreft), dus ik vermoed/verwacht dat het voor maandag zal zijn ... Ik heb het blog tot zolang terug op http gezet, en tja, voorlopig geen e-mail meer ...

08/05/2014, 19:45:
Ondertussen is het probleem opgelost. Blijkbaar hebben de Raspberry Pi's (in een datacenter) problemen met een reboot. Er zijn nog een aantal pogingen nodig geweest om deze terug te starten. Uit de logs leidt ik af dat er bij een van de boots een probleem met het tot stand brengen van de verbinding geweest zou zijn. Zou het geweest zijn omdat mijn hostname niet meer kon gederefereerd worden (ik had die aangepast zodat blog terug via HTTP bereikbaar zou zijn)? Enfin, het is terug in orde gekomen ...

Ik heb toen onmiddellijk de DNS terug aangepast, en toch werkte het nog bijna een dag niet. Ik had het niet meer kunnen testen, maar nginx was er mee gestopt toen bleek dat blog.online-urbanus.be niet naar hem verwees, wat ook zo was op het moment dat de server gestart werd. nginx even herstarten was hier de oplossing.


Nieuwe laptop

Woensdag kwam mijn nieuwe laptop toe. Ik zou normaal gewacht hebben tot na de examens, maar ik was er de laatste dagen veel te veel mee bezig, en daarom heb ik besloten hem nu toch maar te kopen. Het is een Acer C720. Dit was uiteindelijk de enige optie. Het is een van de enige (geen hybride!) zonder touchscreen, mat scherm, minder dan 12 inch, met ssd voor minder dan 500 euro. Veel minder wel te verstaan, de laptop (chromebook) zelf kostte me 269 euro. Dat is eigenlijk nauwelijks meer dan mijn Eee PC. Het totaal was wel iets hoger, omdat, in tegenstelling tot mijn Eee PC, er geen hoesje werd meegeleverd.

Nu, het is een van de best presterende chromebooks (er zijn er geen die strict beter presteren) beschikbaar, en heeft een mooie batterijduur van geadverteerd 8,5 uur, maar dat kan zelfs meer worden. Daarnaast is hier standaard reeds SeaBIOS aanwezig, zodat er geen nieuwe firmware geïnstalleerd moet worden om een ander OS te installeren, want het spreekt voor zich dat ik niet van zin ben om Chrome OS te gaan gebruiken. Allereerst is het te beperkt, te fancy en een aanslag op mijn privacy. Verder werkt ook alle hardware met free drivers en firmware. Voorlopig moet de driver voor het touchpad echter wel nog handmatig gecompileerd worden en in de modules folder geplaatst worden, aangezien die nog niet opgenomen is in de main kernel.

Echter, SeaBIOS start standaard niet. Dit kan geactiveerd worden met Ctr-L, maar dat is natuurlijk niet echt handig. Om dit op te lossen moet je een hexadecimale waarde naar het flashgeheugen schrijven. Echter, dat geheugen is natuurlijk readonly, en om deze beveiliging uit te schakelen moet je even een schroef losdraaien op het moederbord. Dit verliep voortreffelijk, en zelfs gemakkelijker dan gedacht. Uit deze post concludeerde ik namelijk dat er gefoefeld moest worden om de case open te krijgen, maar er is aan de kant van het scherm een stukje dat "los" zit. Als je daar een beetje aan vriemmelt klikt de case los. Het lijkt er ook echt op gemaakt, want ik kon niets zien wat dit stukje plastiek anders een functie zou geven.

Enfin, dan het installeren. Een verbinding maken lukte inderdaad niet, zoals in het artikel van the_unconventional al waarschuwde, al heb ik hem wel doorlopen en dan na de poging verder gedaan, hierdoor werd wel mijn hostname ingesteld tijdens de installatie. Verder lukte het me niet met de iso voor xfce4. Er waren corrupte bestanden. De iso was echter correct (hash), dus ik vermoed dat het aan de USB stick lag. Het gaat hier om Debian Jessie, aangezien de kans nogal klein is dat alles zou werken met een nieuw apparaat als dit.

Nu, ik heb alle bestanden op mijn home folder naar mijn nieuw machien gekopieerd. Echter, ik gebruik nu wel Firefox sync op mijn laptop, en ik synchroniseer zelfs met de config folder in mijn cloud. Mijn hele cloud map synchroniseren zou te veel onnodige ruimte in beslag nemen. Dit doet het nu eigenlijk al, want ook bij de config staan een aantal grote mappen die ik niet gebruik op mijn laptop, maar bon. Ik zal van de zomer toch echt eens proberen werken aan unisister zodat ik meerdere mappen afzonderlijk kan synchroniseren, en zo bijvoorbeeld wel de map van het huidige semester synchroniseer, maar niet die van 2 jaar geleden.

Nu, er is een nadeel aan mijn nieuwe laptop: er ontbreken een aantal toetsen: F11 en F12 zijn er niet, de andere hebben een logo ipv nummer. Maar erger is het ontbreken van de Delete toets, en Home en End, bijvoorbeeld via FN. Maar, op de plaats van Caps Lock is er een zoek toets, en die is gecodeerd als de super key, of beter bekend als de Windowstoets. Die gebruik ik als Fn toets die de functies van de logo's op de F-toetsen aangeven. Voor Delete, Home, End gebruik ik Ctrl. Echter, ik wou dit niet alleen in de grafische omgeving doen (waar ik het xvkbd commando gebruik, zoals ook in het artikel van the_unconventional werd gedaan), maar ook in de tty's. Nu, er bestaat een bestand /etc/kbd/remap, maar dat is een sed-script, en dat is niet echt handig. Er wordt veelvuldig gebruik gemaakt van spaties en tabs voor de input van dit script, en daar moet je dan op controleren, want anders zou je kunnen ook alle toetsencombinaties die die van jou bevatten aanpassen. Uiteindelijk heb ik het gehouden op een loadkeys in /etc/rc.local:
loadkeys /etc/kbd/keymap

/etc/kbd/keymap:

control keycode 14 = Remove
control keycode 103 = Prior
control keycode 105 = Find
control keycode 106 = Select
control keycode 108 = Next

En, dit wordt trouwens ook zeker nog doorgevoerd op mijn computers, want dit is veel handiger dan steeds naar home, end ... te moeten gaan/zoeken.

Verder heb ik ook, op basis van de Arch Wiki, de volgende /etc/modprobe.d/paretje.conf aangemaakt:

# Needed in order to have sound (Arch wiki is the best!)
options snd_hda_intel index=1

# Disable webcam
blacklist uvcvideo

Verder heb ik ook even geëxperimenteerd met mate-power-manager, ipv xfce4-power-manager, aangezien die statistieken aanbiedt over de evolutie van de batterij. Echter, wanneer ik mate-power-manager gebruik kan je de brightness instellen, echter, zeker als je uit een tty komt, wordt die op 98% gezet, ipv de 60 die ik ingesteld heb. Misschien dat ik in de toekomst eens kan kijken om de statistieken als afzonderlijk programma te compileren?

Nu, standaard start hij met 100% brightness, maar ik vind dat te veel, en verspilling. Daarom heb ik een script toegevoegd aan lightdm, met name display-setup-script. /etc/lightdm/backlight.sh:

#!/bin/sh
xbacklight -set 50

fontconfig voor Chromium

In Iceweasel maak ik gebruik van NoScript, Ghostery en Addblock Edge, en heb ik Lightspark geïnstalleerd voor flash. Echter, op sommige sites zorgt dit voor problemen. En dan kijk ik welke scripts nodig zijn, en of er een afhankelijkheid is van een tracker, maar wanneer dit een site is die je anders nooit bezoekt, is dit soms gewoon vervelend.

Daarom ben ik een tijdje geleden beginnen Chromium opstarten voor dit doel. Er is echter één probleem hiermee: de fonts in Chromium zijn afschuwelijk. Nu, er is wel meer mis met Chromium, maar om occasioneel eens een site te openen uit gemakoverwegingen, is dat geen probleem, ik zal het gewoon nooit als default browser gebruiken. Met name het feit dat er geen afzonderlijke search-bar is vind ik een beetje vervelend, dat is handig om even snel de searchengine aan te passen tijdens het surfen, want ik selecteer vaak tekst om die dan via de rechtermuisknop op te zoeken. Erger vindt ik dat er geen echt equivalent van NoScript is. Je hebt wel Scriptsafe, wat in de buurt komt, maar telkens op dat icoontje gaan klikken ... Verder heb je toch echt heel veel extensies nodig om bijvoorbeeld er nog maar voor te zorgen dat Chromium niet afsluit als je een tab sluit, of voor autoscrolling, het uitschakelen van de geschiedenis, ...

Maar bon, de fonts dus. Ik las op een paar oude discussies dat Chromium fontconfig negeerde, en enkel de Xfdesktop deamon opvolgde, maar dat er wel aan gewerkt zou worden. Nu, het lijkt erop dat het nu omgekeerd is ... Enfin, met het volgende .fonts.conf bestand is dit opgelost:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
	<alias binding="same">
		<family>Verdana</family>
		<prefer>
			<family>DejaVu Sans</family>
		</prefer>
	</alias>
	<match target="pattern">
		<edit mode="assign" name="dpi">
			<double>96</double>
		</edit>
	</match>
	<match target="font">
		<edit mode="assign" name="antialias">
			<bool>true</bool>
		</edit>
	</match>
	<match target="font" >
		<edit mode="assign" name="hinting">
			<bool>false</bool>
		</edit>
	</match>
	<match	target="font">
		<edit mode="assign" name="hintstyle">
			<const>none</const>
		</edit>
	</match>
	<match	target="font"	>
		<edit mode="assign" name="rgba">
			<const>none</const>
		</edit>
	</match>
</fontconfig>

Klok

Voor de examens van januari heb ik gezocht naar een manier om een klok te tonen in de tty's. Dit bleek uiteindelijk te kunnen met vcstime uit het pakket kbd, en je kan dit automatisch activeren door in /etc/kbd/config te zorgen dat je het volgende hebt:
DO_VCSTIME=yes


WordPress Upgarde + SSL

Gisteren heb ik op mijn Raspberry Pi bij PCExtreme een proxy geïnstalleerd om zo mijn blog via https aan te bieden. Nu is enkel de verbinding op het netwerk van PCextreme onbeveiligd. Daarnaast is WordPress upgradet naar 3.9. Er werd nog een oude versie gebruikt, en ik botste dan ook op een probleem dat blijkbaar geïntroduceerd werd in versie 3.5. Sindsdien wordt de keuze tussen http en https in door WordPress gegenereerde URL's niet meer (alleen) gebaseerd op de URL uit de instellingen, maar (ook) op $_SERVER['HTTPS'], maar dat werkt natuurlijk niet aangezien de encryptie pas start vanaf de proxy. Er bestaat echter een plugin die dit oplost, al heb ik die wel aangepast, aangezien de JavaScript code volgens mij meer problemen kon veroorzaken dan oplossen.

Er is echter nog een klein ongemakje. Met name de editor plugin werkt niet meer, maar dat is geen prioriteit. Het is geen zo'n last om de bbcodes zelf te typen.

De proxy, daar had ik 2 opties, met name stud of nginx. Ik had eerst stud genomen, maar dan had ik enkel nog https, waardoor alle oude links niet meer zouden werken, en daarom koos ik toch voor nginx, via het pakket nginx-light. Bij stud had ik wel eerst een ander probleem, want het werkte gewoon niet. Uiteindelijk bleek het opgelost te zijn door de crt en key file samen te voegen in één pem file. Uiteindelijk koos ik dus voor nginx, en voor dit blog gebruik ik de volgende config:

server {
	listen blog.online-urbanus.be:443;
	ssl on;
	server_name blog.online-urbanus.be;

	ssl_certificate blog.pem;
	ssl_certificate_key blog.key;

	ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:ECDH+AES128:DH+AES256:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
	ssl_prefer_server_ciphers on;

	error_log /dev/null;
	access_log /dev/null;

	location / {
		proxy_pass http://blog.online-urbanus-be.nl02.members.pcextreme.nl:80;
		proxy_redirect off;
	}
}

server {
	listen 80;
	server_name blog.online-urbanus.be;

	error_log /dev/null;
	access_log /dev/null;

	return 301 https://blog.online-urbanus.be$request_uri;
}

De SSL configuratie is gebaseerd op dez pagina.

Daarnaast is ook de password hashing gewijzigd, zodat nieuwe wachtwoorden niet langer md5 zullen gebruiken.


Motif

Van tijd tot tijd gebruik ik wel eens Athena van de UGent. Probleem is echter dat daarvoor de non-free Citrix client nodig is, en die is enkel beschikbaar voor 32-bit systemen. Er is weliswaar een 64-bit pakket, maar dat werkt dus niet met et nieuwe multiarch systeem. Nu, een tijdje geleden, ik vermoed dat het op het einde van vorig semester was, concludeerde ik dat ook libmotif4:i386 nodig is voor een correcte werking.

Onder wheezy is dat nog non-free, maar inmiddels is dit beschikbaar onder de LGPL. Dus, ik heb maar even de nieuwe versie gebackport naar wheezy, zo hoef ik dus geen non-free pakket te installeren, al blijf ik natuurlijk zitten met de Citrix client zelf ...

01/04/2014, 18:39:
Nu weet ik het weer, het was voor de configuratie, die vereist motif.


GRUB Default kernel

Bij ons thuis in Eggewaarts zijn er al een tijdje verbouwingen aan de gang. In november werd er gewerkt aan de elektriciteit, en daarbij is de elektriciteit ook even uit geweest, waardoor mijn server offline was, en bijvoorbeeld alle opnamen van TV stopten. Nu had ik een dag daarvoor wat zitten rommelen in het BIOS van mijn computer in Gent, en daarbij werd ik er aan herinnerd dat je in het BIOS doet na een stroomonderbreking: de computer opstarten, de toestand (aan/uit) van voor de onderbreking herstellen, of uit laten. En dit heb ik dus toegepast op mijn server thuis.

Dat was echter nog niet voldoende, want voorlopig draaien de virtuele servers nog OpenVZ, tot ik eens tijd vind om over te schakelen op LXC. Tot dan gebruik ik de OpenVZ-kernel van Debian Squeeze. Dat wil echter wel zeggen dat ik niet wil dat de server start met de nieuwste kernel, want dat is natuurlijk de standaard kernel van Debian Wheezy. Ik wil dus dat automatisch de derde kernel in GRUB geselecteerd wordt.

Na wat opzoekwerk vond ik deze website en heb ik de volgende regel aangepast in /etc/default/grub:
GRUB_DEFAULT=2


Raspbmc naar OpenELEC

Toen ik vorig jaar mijn IR-receiver ontving heb ik Raspbmc op mijn Raspberry Pi geïnstalleerd. Dit deed ik vanwege het feit dat ik zo zowel een kleine Debian-server als een mediaspeler kon maken van mijn Raspberry Pi. Het was echter al een hele tijd (zo ongeveer altijd?) dat de apt-database enkele fouten bevatte, in die zin dat een aantal pakketten steeds errors gaven. Daarnaast begon ik me ferm te ergeren aan het feit dat er, in plaats van gebruik te maken van het uitstekende apt-systeem van repositories met Debian pakketten, er een eigen update systeem gebruikt werd, wat voor heel wat mensen ook problemen bleek op te leveren bij elke update. Persoonlijk heb ik hier weliswaar geen last van gehad, of toch zeker niet zo vaak als vele anderen, maar nu had ik in december een probleem dat de Raspberry Pi constant vast liep tijdens het afspelen van bestanden.

Het was praktisch onbruikbaar geworden, en aangezien Raspbmc steeds verder afweek van Raspbian/Debian heb ik beslist om OpenELEC te proberen. Die laatste zou sneller moeten zijn, stabieler, en samenhangender, maar heeft als nadeel dat het praktisch onmogelijk is om zelf software toe te voegen. Toch heb ik besloten OpenELEC op zijn minst eens te proberen, aangezien Raspbmc toch niet meer te doen was, en ik liever een paar beperkingen heb, waar ik dan misschien uiteindelijk rond kan werken, dan steeds schrik te moeten hebben of de update wel zal werken, en of de vele vertragingen van de laatste updates misschien terug een beetje ongedaan gemaakt zullen worden ...

Enfin, ik heb in december uiteindelijk OpenELEC geïnstalleerd, en dat was wel een grote verbetering qua prestaties. De Raspberry Pi presteerde bijna beter op stock speed met OpenELEC dan ferm overklokt met Raspbmc. Uiteindelijk heb ik toch nog een kleine overklok gedaan, en op deze manier heb ik toch een mooie prestatiewinst.

Van de beperkingen heb ik eigenlijk weinig last. In de praktijk doe ik namelijk maar 1 ding buiten de functionaliteit van XBMC, en dat is met name het tunnelen van verschillende poorten van mijn netwerk in Eggewaartskapelle. Met Raspbmc deed ik dit met een daemon met autossh. Wat ik nu gedaan heb is de basisfunctionaliteit van autossh met behulp van enkele shellscripts. Die scripts worden opgeroepen door een cronjob die elke 5 minuten wordt uitgevoerd:
*/5 * * * * /storage/bin/sshtunnel.sh 9981 192.168.1.4:9981

#!/bin/sh
echo "" | nc localhost $1
if [ $? -ne 0 ]; then
	killall ssh
	ssh -TCNgL $1:$2 kevin@paretje.dyndns.org &
fi

De 2de regel van de code test hierbij of er enige reactie is op de lokale poort van de tunnel. Indien niet, dan wordt een nieuwe tunnel gestart. Dit doet in de basisch ongeveer hetzelfde als wat ik verwachte van autossh. Dat wil wel zeggen dat er altijd tot zo'n 5 minuten vertraging is wanneer er een probleem is, of wanneer OpenELEC opgestart is.

Verder is er maar een ding spijtig: het is enkel mogelijk als root gebruiker in te loggen via ssh. Het is ook onmogelijk om een nieuwe gebruiker aan te maken, er is immers geen volledige omgeving die je tegenwoordig zou mogen verwachten. OpenELEC is immers bedoeld voor de beste prestaties als mediacenter, niet als een volledig OS.


Citrix ICA Client

Om gebruik te maken van Athena, wat van tijd tot tijd handig/noodzakelijk is, heb je de Citrix ICA Client nodig. Spijtig genoeg is dit proprietary software, en (dus?) binary-only. Ze bieden een deb aan, voor zowel i386 als amd64. Echter, de 64-bit versie maakt gebruik van, voor Debian, verouderde concepten. Het lijkt er op dat het 32 bit software is, echter steunt het pakket nog op allerlei compatibiliteits-lagen, terwijl Debian overgestapt is naar multiarch. Die verouderde lagen zitten zelfs niet meer in de Debian repo's voor Wheezy. Nu kan ik eventueel nspluginwrapper van squeeze of zelfs Ubuntu proberen, echter wist ik al via mail dat die weg toch, naar alle waarschijnlijkheid zou floppen.

Wat ik dus deed was multiarch activeren:

dpkg add-architecture i386
apt-get update

En nu het i386 pakket installeren. Nu gaf dit een error op, omdat op lijn 696 van het postinst-script nspluginwrapper werd opgeroepen. Blijkbaar controleerde het script zelf nog eens de architectuur, en riep dan maar nspluginwrapper op, die uiteraard niet geïnstalleerd stond, het was uiteindelijk ook geen dependency, en zou dus nooit mogen opgeroepen worden door het script. Nu dat aanpassen leverde dan later in het script een fout op, en wou niet zo mijn hele systeem laten vervuilen, en heb in prerm dezelfde wijzigingen doorgevoerd en het pakket verwijderd. Vervolgens heb ik de tar.gz gedownload, uitgepakt en de bestanden gewoon in ~/bin geplaatst. Vervolgens het root certificaat voor Athena toegevoegd aan ~/bin/icaclient/linuxx86/linuxx86.cor/keystore/cacerts.

Toen ik naar Athena surfte en een programma aanklikte wist Iceweasel uiteraard niet wat te doen met het bestand, aangezien er geen plugin geïnstalleerd is, enkel de bestanden in een lokale map uitgepakt, en geen enkel installatiescript uitgevoerd werd. Echter, gewoon het bestand laten openen met ~/bin/icaclient/linuxx86/linuxx86.cor/wfica "does the trick".

Dit bleek echter nog niet voldoende, en er kwamen errors over missende ini's. De oplossing was de ini's uit linuxx86/linuxx86.cor/nls/en te kopiëren naar linuxx86/linuxx86.cor/config. Nu werkt het!

Echter, we zijn nog niet klaar. Immers, de libraries die geïnstalleerd werden met icaclient, die zouden met een autoremove nu worden verwijderd. Dus moet ik die handmatig installeren. Nu, ik heb liefst zo min mogelijk handmatig geïnstalleerde pakketten, en dus heb ik eens getest welke nodig zijn om te voorkomen dat er pakketten verwijderd worden, en daarmee kwam ik tot het volgende:
apt-get install libgtk2.0-0:i386 libxmu6:i386 libxp6:i386 libxpm4:i386 libasound2:i386

Dit heeft één nadeel: wanneer de dependencies van één van die pakketten verandert, dan zou het in theorie kunnen dat ik ze opnieuw moet installeren, maar niet noodzakelijk. Maar zeker op gebied van libraries heb ik liefst niet (te veel) handmatig geïnstalleerde pakketten, dus doe ik het zo.


Horizontale offset

Een paar dagen terug wou ik terug beginnen aan mijn digitalisering, nadat het stil had gelegen om te gaan werken. Ik twijfelde echter of ik wel wou terug beginnen. Immers, ik had opgemerkt dat de nieuwe video speler een zeer goede beeldkwaliteit had, maar, zeker na digitalisering, viel het op dat de offset van de horizontale lijnen instabiel was/is. Na wat research bleek dat het feit dat dit niet zo was met de oude JVC te maken heeft met het feit dat de oude JVC naar alle waarschijnlijkheid een ingebouwde TBC had, aangezien het nu optredende effect een normaal effect is.

Hierdoor begon ik te twijfelen of ik wel verder wou gaan, en begon ik te denken wat de mogelijkheden waren. Zeker geen nieuwe videospeler kopen, noch een afzonderlijk apparaat, daarmee zou de kost van de digitalisering te hoog oplopen. Maar, ik zou wel kunnen vragen of ik de video-spelers van familieleden eens zou kunnen testen. Maar, uiteindelijk heb ik er vanaf gezien, immers, op die manier kan ik nog lang doorgaan, en weet ik nooit zeker of ik nu al dan niet kan beginnen. Daarnaast zijn dat allemaal oude spelers, waardoor dan weer het beeld zelf van lagere kwaliteit kan zijn. Daarnaast is het maar de vraag of ze dan TBC hebben, en heb ik dan misschien wel een jaar vergooid op het vlak van de digitalisering.

Ik zal dan ook gewoon meteen beginnen met het digitaliseren, maar enkel knippen met DVBCut, welke ook MPEG PS streams ondersteund, naast de TS streams van DVB(-T). Wanneer het dan klaar is zal ik dan eens moeten kijken om die storing weg te filteren. Eventueel door een eigen implementatie (of zelfs algoritme), eventueel met DeJitter voor AvxSynth. Die laatste is echter nog niet bepaald op punt gesteld, waardoor de kans relatief groot is dat ik gewoon eens zal uitzoeken als het moment daar is hoe ik zelf een filter kan schrijven voor Avidemux, eventueel aan de hand van de source code van DeJitter.