Sorry about that Eric, you are sitting in the middle of a range of IP addresses I had blocked due to spam. I have removed the block now so we can communicate.
I've tested it a lot more since reporting that bug, and I have a work-around that I'm using at the moment (piping the results out to a perl script which parses them for result numbers, then writes a shell script with a seperate get command for each file on a line by itself, and a sleep command in between each one, and then tells the user the command to type to run the shell script) e.g. > res 12 | ~/bin/mp3-get now do 'load do_get' > The shell script looks like this: get 1 ! sleep 1 get 2 ! sleep 1 get 3 ! sleep 1 get 4 ! sleep 1 get 5 ! sleep 1 ! rm do_get I then just go away and leave it to run and come back later and bulk delete the ones I don't want... e.g. the selection interface is too time consuming to use because I can't do "get 1-25" without it hanging. It seems it's not a matter of how many numbers are requested with a get command, it looks more like it's to do with how many mutella is trying to add to the queue within a short period of time, because if you ran a script with: get 1 get 2 get 3 get 4 get 5 get 6 get 7 get 8 get 9 get 10 and no sleeps, it would be likely to hang mutella as well. I have never *ever* had mutella come back after hanging, even if I've left it for 24 hours. The only way to get it back is to <Ctrl-C> it and restart it. I hope this helps. Kind regards, John On Wed 23/02/05 16:18:07 -0800, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > #191241: mutella: "get (3 or more numbers)" causes hang, > which was filed against the mutella package. > > It has been closed by one of the developers, namely > Eric Warmenhoven <[EMAIL PROTECTED]>. > I've sent two emails to [EMAIL PROTECTED] and both have returned: > > ----- Transcript of session follows ----- > ... while talking to smtp.a32.net.: > >>> DATA > <<< 550 Administrative prohibition > 550 5.1.1 <[EMAIL PROTECTED]>... User unknown > > Since I'm unable to reproduce this and I'm unable to get hold of the > submitter, I'm closing this. If the submitter still uses the package and > wishes to reopen this bug, he can send mail to [EMAIL PROTECTED] > with the commands 'reopen 191241' and 'submitter 191241 !'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
