program exits after hours while ripping, then have to delete the xlm to restart about thelastripper HOT 9 CLOSED

Dying after a few hours would not be usual... A you guess probably the of the 
stream
from last.fm...

The disabled password box is because TheLastRipper remembers your password. All 
you
have to do is press "login" or alter you username field which would reenable the
password field, and then press login... Then the "ok" will be enabled again...
I know that it would seam more logical if the password field was populated with 
stars
i.e: ********. But I don't save the password, only a hashsum of the password... 
Which
ensures that your account cannot be compromised if someone steals your config 
file
i.e. "thelastripper.xml".
(a hashsum of the password is all that needed to listen to radio from last.fm, 
but
the hashsum will not enable anyone to login using the webinterface and modify 
your
account).

By the way, the config file should be safely stored on you system, so there's 
no risk
anybody gets their fingers on it, unless your systems is compromised...

indeed it "dies" after a few hours (between one and three). Then if i don't 
delete 
thelastripper.xml, not only items on the settings dialog are disabled, which 
obviously is correct, but also all items in the main window, so i cannot enter 
a 
station nor tune in. But no big problem for me, i just del the xml, and it 
works 
fine.

If you click "login", and wait for "ok" to enable and click it too, instead of
closing the settings dialog. Then TheLastRipper will have loggedin and the 
buttons on
the mainwindows will not be disabled.

Sorry, i felt that i already have tried it the normal way hitting the login and 
ok-
button, but i am not sure, so today i did another testing procedure, which led 
me to 
the origin of my workaround i.e. deleting the xml.

1. i am ripping
2. the lastfm playlist ends, in follow the program dies.
3. i restart the program, login and then click the released Ok-Button, enter 
the 
station, press "tune in"
4. program freezes, after some time bringing a longer error message about a 
time out.

Now if i click "quit" and then restart the program, it's the same as from point 
3. 
If i click continue, it's the same from point 4.

Then if i delete the xml, it works fine again. I tested exactly that 3 times 
today.

I am glad with your program, "awaiting" the first end of playlist today took me 
more 
than four hours of constant ripping. 

Maybe there's a problems saving the config file, when the program crashes 
instead of
being closed correctly...

I'll probably have to implement some kind of "end of stream" handling, in the 
next
bugfix.. :)

yet another revision on point 2.

2. Program dies (not because playlist ends). My traffic-meter still indicates 
the 
higher download rate, and the size of the temp file (TheLastRipper.mp3) 
constantly 
grows up to 82 Kb, then ressets to 0 KB, grows again in seconds zo 82 KB and so 
on.
Also the lastfm website scrobbler tells me i am actually "hearing" some music.
So the program is still downloading the stream, and the error  lies somewhere 
in how 
the tempfile is written.

revision of revision on point 2. (arghh, plz ignore Comment 5)

2. Sometimes program dies, means the window disappears, entry in task list 
disappeares, internet traffic goes down.
Sometimes  program stays active and window is still there and responding to 
action 
like move and close, but tells me ripping the same piece of music forever, 
while the 
progress indicator stays at maximum. My traffic-meter still indicates the 
higher download rate, and the size of the temp file (TheLastRipper.mp3) 
constantly 
grows up to 82 Kb, then ressets to 0 KB, grows again in seconds zo 82 KB and so 
on.
Also the lastfm website scrobbler tells me i am actually "hearing" some music.
So the program is still downloading the stream, and the error  lies somewhere 
in how 
the tempfile is written.

 just saw your earlier comment:
> Maybe there's a problems saving the config file, when the program crashes
> instead of being closed correctly...

No, i already had tried it with a config file saved before any unexpected 
behaviour.
Actually, if i do not "save password", leaving the config file as it is works. 
Its 
that password thing.


> I'll probably have to implement some kind of "end of stream" handling,
> in the next bugfix.. :)

Probably not, concerning the "still ripping" phenomenon :)

The reason the temp file grows is because the stream returns "not enough 
content",
when the stream ends, and TheLastRipper just writes whatever is returned from 
stream
to the tempfile... Or at least that's a possibility...
It may also be the lack of metadata or some other mysterious bug... But I don't 
think
the bugs are associated with the config file... As far as I know the password 
feature
works on windows... With the current implementation...