Sunday, August 22, 2010

digicorder and recording subsequent programs

Digital television is getting the norm in Belgium, and typically people rent a "digicorder" from the TV provider. This allows you to watch television and also record programs for later consumption.

In practice my family only records a few programs and watch them later. It's very convenient not to be bound to a specific schedule. (On the other hand it would probably be cheaper to just buy the DVD boxes of the series we like instead of having television at all, but that is another discussion :) ).

In general, the digicorder works fine, I have one big gripe with it though: recording of subsequent programs.

Lets say we're recording subsequent programs A and B from channel 0. Let's assume there is some advertisement in between programs. This gives as timescale something like this:

Now, there are three ways the digicorder can record the program, not counting the completely faulty ways when timing goes all wrong.

Both programs want to record a time-slice before and after their program, but this goes wrong in the middle, and only one recording ends up with the middle part.


The correct recording is with the break point in the middle like this:

I presume there are not some kind of markers in between the broad-casted programs on commercial television because it makes their advertisement store even worse.

Therefor, in practice you typically end up with one if these two:

B in recording 1

This is problematic because if you don't remember not to erase recording 1 after watching program A, the start of program 2 will be lost.

A in recording 2

This is even worse. Lets say you want to watch program B first.

You first have to open recording 1, fast forward all the way to the start of program B, start watching and after a few minutes switch to recording 2. This will also leave recording 1 marked as "watched" even though you didn't watch program A yet. More confusion!

A simple solution

In the end this is a simple technical problem with an even simpler solution: record the overlap in a separate file and make it part of both recordings. Visual:

If you watch recording 1, you get recording 1 + X. If you watch recording 2, you get X + recording 2.

If you erase recording 1, X stays. Only if both recording 1 and recording 2 are erased, X gets deleted.

More in general there will be X areas both in front and at the end, etc...

Would be nice if the biggest TV provider of Belgium could implement this. If the digicorder was open source I would've done this already months ago...
I guess I'll have to look into some kind of MythTV like setup one day.

Saturday, August 14, 2010

Saturday, July 17, 2010

arduino-0018, avrdude and usbtiny programmer

For some reason the avrdude binary that is shipped with arduino-0018 has no support for the USBtiny programmer which I use to burn bootloaders on blank AVR atmega328 microcontrollers.
On Debian the workaround is simple: first install avrdude via apt-get/aptidude and then enter the hardware/tools directory in the arduino-0018 dir and replace avrdude by a softlink to /usr/bin/avrdude like this:

$ cd arduino-0018/hardware/tools
$ mv avrdude avrdude.old1
$ ln -s /usr/bin/avrdude .
$ mv avrdude.conf avrdude.conf.old1
$ cp /etc/avrdude.conf .

After this burning a bootloader via the menu in arduino works fine again. A similar approach will probably work on other Linux distributions.

Friday, May 7, 2010

amavisd-new clamav crashes tmp files

Since I still run my own mail infrastructure, I also run anti-spam and anti-virus on it.
Today I noticed that free space on my server running lenny was ALOT less then usual. Turned out that clamav was crashing all the time causing lots of temporary files in /var/lib/amavis/tmp.

An upgrade of clamav also stopped the crashes.

While at it I also disabled quarantining virus mails, I never had to retrieve any mail out of there anyway...

Friday, February 12, 2010

Nokia N82 Bluetooth + GPRS/3G

A few months ago I did an interesting discovery about using my cellphone to go on the internet via bluetooth. I had this strange situation before where it just stopped working, and after revisiting all configs it worked again.

What really happens is that my cellphone somehow crashes, after which I power cycle it by removing the batteries. The phone then boots again, but here is the twist: the service channels in the phone are re-allocated and apparently in a random order!

This implies that the RFCOMM channel configured in the /etc/bluetooth/rfcomm.conf file is possible wrong now!

Solution: just browse the services again with sdptool browse, adapt the file and it should work again!