AutoNap - Automatizable Napster client / News: Recent posts

It took me a while to finish this one. Since AutoNap can now also share songs it is compliant to the idea of file-sharing and P2P. Thus it is Beta now.
I want to erase any new occuring bugs as soon as possible so please send me your reports.

Despite the fact that it looked as though I hadn't been working on AutoNap recently, it is advancing slowly but steadily. Due to my new DSL connection I can finally test it reasonably on my own computer (which is new as welll due to the death of my old one). The 0.5-release will introduce file-sharing and from then on the tracking down of bugs. There are still a few as I have realized in the meantime.

I had to do this release earlier than I expected as 0.4.0 really had a large number of bugs, especially in automatic mode when configfile was not in the expected form.
The new feature is the IP validation by the daemon. You now have to grant access to multiple single IPs and/or IP-ranges. Only connections from clients matching this set of IPs is granted.

After having prematurely and a little over-optimistically made announcements on when the next release would finally come out, this moment has now come!
I had to change the client/server model so often which astonishes me since the final approach isn't that far-fetched and only has advantages compared to a telnet-based solutions (command-history etc.).

Have a look at the 'KNOWN BUGS' section in the AutoNap.pl(1) manpage as it will explain some securitly-related issues and....well, known bugs.

After having lingered a but during the past days in comp.lang.perl.misc to get a few necessary hints, things seem to advance again. I decided not to supply a separate client-application for the daemon but instead a simple telnet-session will do.
I am, however, not sure whether I will be able to implement the full pager mode (that is: with only one key-stroke necessary). This is due to the fact that the server reads the client's input by-line while input is taken by-character when being in pager mode. But we'll have to see as to that. At least, there'll be no difference in functionality comparing interactive-mode and daemon-mode.

As I am right now lacking a little bit of inspiration how to improve the automatic mode I decided to add a new feature to AutoNap of which I think it might get useful later or even in first instance.
The next major release will actually split up AutoNap into two applications, a server and a client which communicate through tcp/ip. The basic idea is that the server can run more or less the whole time running either locally or on a remote machin while commands are passed to it through a little client application which will also receive AutoNap's output. So far I implemented the server and a very simple client, but yet have to deal with displaying the server responses correctly which rather is a pain as it will require quite a lot of rewriting.
This daemon-mode is started with a new switch (-D) so that not giving this switch wont change AutoNap's behaviour so there is still the ordinary interactive-mode.

I suppose there must sooner or later come the moment when a piece of software can actually be considered free of really annoying bugs. Not so AutoNap. ;-)
However, two more have been wiped out (see changelog for details) and currently I am working on a better way of handling the streaming by making the whole matter fork a new process so that the player can be killed independently from the underlying tee that is also started.

I am sorry for the inconvenciences that arose from having obviously not tested the 0.3.0 well enough. Letting AutoNap prompt you for username and/or password led to an 'undefined subroutine'-error. I moved two subs into a different module but forgot to export these subroutines in this module so they weren't there for AutoNap. This is now fixed.
Apart from that, I made the promised change in the ping-command so you do not give a timeout value as second argument anymore. It'll just ping the user and return the time it took.
I added a few lines of code that enable the rnd_exclude_patterns directive from the configfile. This is useful when you massively employ the random search in non-interacting mode which I can only encourage anyone to do.

And it really has major new features, namely the non-interacting mode that I promised right from the start but that took me ages to code. It is far from perfect. But the problems are not with instabilities or so but rather with some behaviour of AutoNap that is not always extremely intelligent. Still it is already usable, especially letting him search randomly is a true source of inspiration! Having it run overnight will present you with a bunch of MP3s you would have never dreamt of downloading deliberately...there is probably at least one amongst these that you'll like, promise. However, as Murphy's Law heavily applies to random searches, you will have to live with certainly one song of the Village people as well. ;-)

...my current activities concerning AutoNap: you should from time to time have a brief look at the CVS-repository to see when I commited something the last time.
As a matter of fact, development advances more slowly than I had expected. Yesterday I thought I would be able to finish a pre-release with an already working non-inceracting mode. But then I realized it was quite a bullshit what I had so far coded and so today I had to rewrite the internal data-structures. It took me about two hours to track down a strange behaviour. Now it looks as the toughest part is done. :-)
AutoNap searches automatically according to the configfile, pings results and rates them. It now distinguishes between results occuring from different search patterns (you can have, like, an infite amount of them) and will no longer merge them.
Now I can tackle the downloading thing and before the release gets out I also have to implement a useful logging of AutoNap's doings.

After just again having a crash of my harddrive and compiling a new kernel it looks as though I solved this annoying thing for all times. :-)
That means that it can't be long till the next new AutoNap release is coming. In fact, I already finished half of it. The real enhancement will be the robot mode. Right now, a user can already specify as much search patterns as he wants, a range of bitrates and file lengths and a linespeed and AutoNap contacts the server and performs multiple searches (actually a permutation evolving from the different ranges and search patterns).
The results are merged and matched against the criteria the user specified in the configfile. It is really quite neat so far.
What's still missing? Well, AutoNap then will have to ping each owner of a song and make a ranking of the pings thus being able to select the quickest parties for download. Ah, and by the way, yes, this downloading thing also needs to be implemented yet. But this cannot take very long. I hope to finish a pre-release in due course of this day.

I am sure that if something like that happened it would certainly happen to me....and so it did. :-(
Last night I crashed my Debian box...there was only the solution of an installation from scratch which was no fun over a slow ppp-line. (mkfs.ext2 /dev/hdc5 != mkfs.ext2 /dev/hdc2...by the way, the first of this killed 3 gigs of MP3s...all of mine, TO CRY OUT LOUD!!!)
However, I have again set up a running Perl (the first thing was testing AutoNap which still works) so the development will go on during this week. Not exactly tomorrow, as I'll need to do two exams this week :-(, but after the second one on Thursday. So stay tuned, as some lamers say!
:-)

Ok now, after finising a reasonably stable 0.1.3, I started working on the initially announced automatizable stuff.
This thing is decisively more complicated than the interactive mode since the user still wants control over what AutoNap is doing...control in beforehand.
I am setting up some kind of scripting language for AutoNap, an extremely basic one. I though about something like that:
GET * WITH
pattern=beatles+michelle
AND
bitrate=128-160
AND
length=2:00-5:00
AND
linespeed=T1
END... read more

In theory it should be stable. But before being sure I need comments from users because the one writing a program is the least likely to find bugs in it.
After a while of testing (and the conviction that is rather free of bugs), it'll become 0.2.0 and then I can start with major feature enhancements, in first place the non-interactive mode.

So I really need your help now.

Right now, AutoNap is in a sort of 'freeze'-state, which means: no new features in the soon coming 0.1.3 release but instead I intend to do a complete (and this time I mean it!) review, checking and testing procedure. I re-did the commandline-stuff which now looks good and in this moment I am improving command parsing in interactive-mode. The problem is not a technical one but rather one of taking all possible user input into account. Example with 'ping'. The user might type:
'ping nickname 3' which already worked perfectly.
But also:
'ping____________nickname___ 3' which probably couldn't be parsed by AutoNap. Same with most other commands requiring arguments. Even this confused AutoNap so far:
'help _____' where each underscore is again a whitespace. AutoNap said:
'____ - unkown command' which should be considered a bug.... read more

Fixed a bug with browse and the new key bindings in paging mode.
There is a new command, 'blast', which is similar to 'last' but corresponds to browse searches.
And: caching for browsing users has been added and I changed the caching mechanisms so that searches and browses with no results aren't cached...wouldn't make sense.

Well, see Subject and Release Notes for what has changed. As to a new bug: just after adding the new release and updating CVS, looking at the diff of Shell.pm made me suspect about 'browse' and hitting 'q'. It may then download the very first song of the list. But I'm too tired to check that now. ;-)

A little ponderous, but, well, on topic:
0.1.2 is the current release that should be used...it contains all the features of 0.1.2pre1 and is less buggy.
Next things I'll be working on:
- starting with the non-interactive stuff (otherwise I woudl have to rename the project;-)
- working some suggestions from other people into the code
- plus: having a look how to glue a little bit of CDDB into it and where it makes sense... read more

This was caused by the fact that the perlmodules corresponding to AutoNap reside in a directory that is highly dependant from the setup of a user's box. AutoNap now takes this into account and wont raise SIGDIE any longer, when the server didn't yet report the size of a song being downloaded to the user. Till now, it said something about a division by zero error.

Well, I did the review with 'hot fingers' as they say. install.sh will care for installation. Run it with "install.sh install" for setting up AutoNap on your box. "install.sh uninstall" accordinly for removal.
Manpages, as far as they are necessary, added and will be installed by default to /usr/local/man/man(1|5)

After all, this upgrade really is worth the hefty download of 19k. ;-) It looks quite stable now (this time I mean it). If there is, however, anything that seems to be broken and doesn't seem to work for you, you should tell me about it. I'll then fix it as soon as possible.

I thought it would be time to again work on a non-devel release and so I am right in this moment working on tracking bugs and eliminating them from the source (thus violating my own Todo.txt).
The caching stuff for 'search' will be included plus a manpage for AutoNap.pl. There'll also be an install-script in the package and an uninstall one for those who consider AutoNap to be a little bit dubious. ;-)
All features from the current 0.1.2pre will be included in 0.1.2 but none more, just because I do not want to break the code again. Besides, I am rather getting to the point of considering some of the strange behaviour to be invoked server-sidely. Napster and OpenNap do differ in a way which complicates matters a little bit.

This new package contains the latest developer's release which will at least not crash your machine. Compared to the default package it will at least contain ONE additional feature. ;-) See Changlog and Release Notes for that.
As for 0.1.2pre, you should prefer this one over 0.1.1 as it in fact fixes a bug with 'browse' which makes it impossible to ever get the user's mp3-list. The new feature (registering an account) might however be not that stable yet.

Not a revolution but a huge step into the right direction. Now connects reliably to Napster and MusicCity...DJNap works sometimes but damn slow.
Cleaned up the configfile/commandline-switches mess so that commandline-arguments now override configfile's options.
Much improved error-handling, some new messages and, furthermost, new 'ping' and 'browse' commands.
After all: 13 kBytes of worthwhile download.

If anyone happened to browse the CVS-tree some time ago and quickly withdrawing due to the messy code, should now again have a look at it:
Much better now, more readable and also resulting in more stable start-up and logging in. Really, trust me, it is no joke!

This release is not really a revolutionary progress but overcomes some shortcomings of the previous 0.1.0 release. Especially getting the server list is MUCH quicker and works more reliably. You may now specify a network to connect to as well.
Additionally a simultaneous streaming to an external player and downloading is possible with the 'stream'-command. As the download stream is tee'ed to the player application it is probably not a wise thing to try to stop it playing.
Also, a feature not very well tested yet since streaming is no fun with my slow modem-connection. ;-)