gregoa's blog

the painful problem: when I'm listening to music (with randomplay) mpg321 blocks the sound card. [0] side effect: I don't get sound notifications from centericq, & usually I don't see new messages because of the small window centericq is running in.

the funny solution: cw:

This package contains a simple command line client called cw, which sounds characters as Morse code on the console speaker. [..]

from now on I get morse messages from centericq whenever the sound card is used by an application [1][2] - cute ;-)

[0] & I haven't found a quick solution to open /dev/dsp non-blocking ...
[1] aplay .. || (echo "bla" | cw ..)
[2] & I'm somewhere near the box

my latest project called 'isbn2bibtex' seems to take off finally. the name is the aim: create a complete bibtex file from just a file with isbns. since today I have working beta version. ingredients:

• isbn2bibtex: a shell script that ties everything together, calls the various helper scripts, & manages the temp files etc.
• 4 new perl modules: MARC / libmarc-perl, MARC::Record / libmarc-record-perl, Net::Amazon / libnet-amazon-perl, Net::Z39.50 / libnet-z3950-perl (debian packages available now from the toastfreeware debian respository)
• 3 perl scripts, written by me (i.e. copied from the man pages of the above mentioned modules & adapted): isbn2usmarc, marcclean, isbn2amazon2ris
• 2 binaries (ris2xml & xml2bib) taken from bibutils
• marc2ris, a perl script adapted from refdb

the procedure is rather obvious: isbn2usmarc searches for the isbns on several z39.50 servers, marcclean removes duplicates, marc2ris converts the entries from usmarc (a.k.a. marc21) format to ris format, ris2xml & xml2bib finally produce bibtex output.

unfortunatley the z39.50 servers are not only hard to find & slow & everything, those I use don't find all books I was looking for (fiction doesn't seem to be the strong side of public & scientific libraries). that's where isbn2amazon2ris comes in, it tries to retrieve informations about the missing books from amazon.{de,co.uk,com}. - unfortunately amazon doesn't return any (publishing) address information, though. but now I have an amazon web services account. oh well.

well, and after all the fuzz I have bibtex files which I can open in any (text or) bibtex editor, e.g. jabref (debian package) (and recreate the keys in order to avoid duplicates).

now that the stuff seems to work more or less I have to decide if I really want to

1. type the isbns of all my books
2. store the data in bibtex format

:-)

update 1:
adapted isbn2usmarc to search for only 10 isbns at one time because some z39.50 servers whined & errored out on higher numbers. argl.

update 2:
started to type in some isbn numbers. it's not really that much work especially if many books are from the same publisher (i.e. the first 2 parts of the isbn are the same) & if the isbn is printed on the back (usual for "newer" books).

update 3:
with the help of bibtex2html I publish a list of books in my library in a daily cronjob.

on planet cUG the last entry from my movie feed didn't show up. I tried this & that & changed the feed & ... - you name it.

after turning log_level to INFO in config.ini I knew the reason:

"Obviously bogus year in feed (2004), cowardly not updating"

well, thank you very much, I know that I've been to cinema in 2004, too, & that's ok for me!

I was short of commenting out the whole if-statement in planetlib.py but then decided to only return the last ten movies in the feed. otherwise it would be getting longer & longer anyway ...

finally I managed to get reading PGP/MIME messages in slrn working. cf. my article on this subject.

tried again to work on the named pipe for randomplay (cf. my entry from last weekend). the current status is that I know when randomplay writes to the pipe & when it doesn't, & that my small (reading) shell script can handle the results in a sane way. zombies are left only when I go to the next song; but they are cleaned on exit, & the named pipe is removed as well. - in fact I hardly changed anything — maybe just waiting for 7 or 8 days was enough.

better than nothing. & — oh yes: my ion3 status bar tells me what I'm listening to, too ;-)

update 1: I slowly seem to get rid of the zombies with some $SIG{CHLD} magic.
update 2: & later they re-appeared again.

failure

what I like about xmms is the named pipe (provided by xmms-info) that can be used to read informations about the currently playing track. so I tried to implement a similar feature into randomplay; sometimes success seemed close & sometimes it seemed far away. finally I surrendered - being not able to reproduce phenomena makes debugging meaningless. - I guess I should learn more about named pipes, fork(), zombies, maybe threads, kill signals, and stuff like that.

success

to make up for the failure with randomplay I created an RSS feed for my movie database. - I'm sure it will be read & syndicated by a great many people :-)

I like to go to the movies. I like to have the schedule of my favourite movie theatre in my communicator's calendar. unfortunately they still haven't managed to publish it as a simple CSV file (although the manager has promised me to offer such a thing & it should be a matter of some minutes to create a PHP script for this purpose - cf. the URLs on their schedule page.)

anyway, today's a holiday in austria, so I used the time to write a little script that creates a nice CSV file with some wget/html2text/recode/grep/perl/sed magic.

having some linux tools around often comes in handy ;-)

yesterday my computer suddenly shut down without any warning or beeps or anything while I was rendering a video; obviously the cpu overheated. after opening the chassis I knew why - the cpu fan was hardly visible under an enormous dust cluster.

after cleaning everything my good belanna is working like a charm again.

update: installed lm-sensors & sensord afterwards, compiled a new kernel including the lm-sensors-modules, & I hope that I configured everything right.

submitted a whishlist bug against randomplay containing a small patch, & 28 minutes after sending it (& 18 minutes after the report arrived at the debian BTS) the package maintainer (= upstream author in that case) responds:

Thanks for the patch. That looks good. I'll give it a try and assuming all is well will incorporate it shortly.

view bug #337783 at the debian BTS for details.

update: randomplay 0.49 is released now (incorporating my patch with slight modifications).

randomplay

reading planet debian yesterday I stumbled over adam's post about randomplay. apt-get install'ed it, read the man page & liked it. - summary: a CLI/xterm music player with randomizing capabilities, a history & weighting functionality. the options seem very logical & intuitive, & it has been running here for the last hours ;-)

aptitude

I don't remember where I read about the nice feature, but it's really handy to see which archive a packages is in when using aptitude.