LM does (not?) understand how2 use osx safe-mode?

[davidf01]

Does Limewire know or care in what mode osx is launched? eg in saftey mode or even something as simple as 'default' mode

(by default mode i mean the option to not load the _users_ startup/login items not the _system_ startup items ... fyi: this is accomplished with the shift key /after/ the kernel has loaded, while the progress bar is being completed)

my downloads.dat/bak files have been nuked (which Limewire does to me at the worst possible times) -- and i am trying to figure out the reason why! ...

normally, Limwire will destroy the .DAT/.BAK files if they are open when Limewire quits in an unstable manner -- crashes are not so frequent but (alas) Limewire is notorious for hanging (for hours or days at a time!), with the resultant forced-quit.

however, in recent versions Limewire has proven (marginally) more resiliant to forced-quits, so usually there is NOT catastrophic data loss after a hang is terminated; thus i want to examine another possibility that involves a subtler interaction between LM and osx ... namely the launch state of osx (in this case in 'default' mode).

here is the aspect of the LM interaction that is a bit indirect:

tvshows.sf.net is a torrent tracker which integrates with Limewire - it allows users to be put on a 'wait list' for new torrents to which they subscribe ...

tvshows.app will then automatically launch the default torrent client (eg Limewire) when a torrent becomes available.

however, tvshows.app binds torrent files to a _specific_ version of Limewire -- so if you have more than one copy of Limewire installed (eg a stable release and a beta release), then the designated (and maybe obsolete) version of Limewire is activated when tvshows notifies LM of a new torrent (only in the 'deafult' start-up mode?)

normally, launching a different (older) version of LM would not be a big deal, since different versions of Limewire should respect the same "downloads.dat/bak" files, so all the old downloads in progress should still be (re)loaded into that instance of Limewire.

however, in this case - by coincidence - tvshows.app launched Limewire at the exact moment just as i had restarted osx in 'default' mode (ie skip login/startup items for my user account) ....

and the DAT/BAK control files had been wiped by (some version of) Limewire.

so: what i am trying to determine is whether the restart into osx's 'default' mode meant that // older application bindings // for the (newly arrived) torrent were being used instead of the 'normal' data bindings (which would have presumably launched the 'current'/normal version of Limwire) .... and if this launch/binding order is an expected part of osx behavior then does limewire properly anticipate it? .... and even if the 'wrong' version of limewire is launched anyways, would the difference in osx startup mode effect how limewire (whether the older version or newer one) would handle the (corrupt?) dat/bak control files?


or: is the osx launch state merely a coincidence? ...

ie: is the loss of the control files NOT due to some subtle interaction between LM and osx at all?! ... but instead due to the general stability problems Limewire has always experienced? -- which IMO is due to the on-going lack of diligence and attention to detail at Limewire, as well as the lack of project management foresight to use UML as the engineering S.O.P. ?

personally, i resent the colossal waste of my time duplicating the search for names of all the files orphaned by Limewire (which represents many hundreds of hours of tedious manual data entry) ...as well as the waste of my disk space (hundreds of gigabytes that i have been forced to archive to preserve the crashed entrails left behind by Limewire, in the vain hope that one day i would be able to figure out how to make them come back to life!) ... not to mention all the lost bandwidth that those hundreds of gigabytes of orphaned files represent!

some insight would be appreciated into the cause of this most recent Limewire destruction of my control files.

thanx.

[Lord of the Rings]

Actually running older versions of LW will cause issues with the download.dat file. Though going back to the new version and forcing them back via the Library window > incompletes will get them back to the download window & though initially show zero %, once start downloading will show their previous download %.

It sounds like the torrent site binding to a specific version of LW is an issue.
Is there anyway to change that?

AFAIK regular programs should not be used in safe boot mode under normal circumstances. I have not attempted to do what you are doing.

BTW if you are still having problems with download.bak, there was a backup system posted before LW introduced an improved download.bak management system (my guess is based on the one that was posted or at least their own approach to the issue). Check the OSX section stickies on the forum to locate it.

Mac makes their own Java unfortunately. It has never been as good as the Java for other OSs. It has always tended to have memory leaks, and difficulty releasing VM when no longer needed. Keeping in mind LW is mostly made from a type of java and runs on java.

When running LW with either or both large shares and incompletes, VM (Virtual Memory) will run up fast, and LW will after a period of running get slow and potentially get close to crash status easily .... losing responsiveness. Simple answers are: to close LW periodically; reduce incompletes, Tip: Purge the Downloads Queue! (click on blue link); keep shares below 2,000; not share from slow external drives such as FW400 or usb.

As far as keeping old incomplete files, they are useless unless you have a healthy download.dat/bak file that recognises them. Else LW will just ignore them or think of them as an empty incomplete file. Not sure if hash info will be stored either, which means the file(s) identity and source may have been lossed. Stief will probably know more.

[davidf01]

UPDATE:

good news, i hope ... when i re-launched the newer (beta) version of LM, the app was able to see all my old downloads correctly - whereas the previous launch of an older version of LM (which was provoked by the torrent aggregator MyTVShows) had /seeminlgy/ wiped out all my incompleted downloads --

so this is a minimal amount of good news (this LM has special restore powers!) ---

perhaps part of the reason why is that the beta version of LM now seems to store its control files in the user/lib/prefs/limewire/ folder ... not in the user/incomplete folder.

i dont know if this helps somehow but it my case it seems to have made the difference - at least after 1 restart.

Originally Posted by Lord of the Rings

Actually running older versions of LW will cause issues with the download.dat file. Though going back to the new version and forcing them back via the Library window > incompletes will get them back to the download window & though initially show zero %, once start downloading will show their previous download %.

hmm, i guess this must be limewire's "revive" feature :-)

Originally Posted by Lord of the Rings

It sounds like the torrent site binding to a specific version of LW is an issue. Is there anyway to change that?

yes, osx does seem to bind the data (the torrent file) to a specific program (a stable version of LM - not the beta version, which is what i mostly use).

the only way to _manually_ change the binding is to use GETINFO ... the the command for associating a file with an app is displayed in the "open with" setting .... but this wont solve a problem retrospectively (ie once an older version nof LM is already launched & doing stuff to the control files).

Originally Posted by Lord of the Rings

AFAIK regular programs should not be used in safe boot mode under normal circumstances. I have not attempted to do what you are doing.

i was actually NOT referring to safe mode - but instead to its cousin, "default" mode (which only disables the login items for a user-level startup ... not the system-level startup, which is actually 'safety mode')

Originally Posted by Lord of the Rings

BTW if you are still having problems with download.bak, there was a backup system posted before LW introduced an improved download.bak management system (my guess is based on the one that was posted or at least their own approach to the issue). Check the OSX section stickies on the forum to locate it.

nice to know that a) LM has explictly addressed the brittle backup issue in general and that b) there was some separate utility available before (and still now).

Originally Posted by Lord of the Rings

Mac makes their own Java unfortunately. It has never been as good as the Java for other OSs.

the inadequecy of apple's jvm must come as a shock to all those devs at sun who are using apple gear :-) ....

supposedly java6 is supposed to deliver substantial performance improvements and memory effeciancy ... has any beta of LM be built against java6 yet in order to get some preliminary benchmarks?

Originally Posted by Lord of the Rings

re responsiveness: Simple answers are: to close LW periodically; reduce incompletes, Tip: Purge the Downloads Queue!; keep shares below 2,000; not share from slow external drives such as FW400 or usb.

wow.

that is frightening advise! (albeit useful).

Originally Posted by Lord of the Rings

As far as keeping old incomplete files, they are useless unless you have a healthy download.dat/bak file that recognises them. Else LW will just ignore them or think of them as an empty incomplete file. Not sure if hash info will be stored either, which means the file(s) identity and source may have been lossed. Stief will probably know more.

damn!

[Lord of the Rings]

I wasn't aware Java for OSX was developed at SUN, I was under the impression it was a mac dev team. But that's from my own ignorance. However, it is well known amongst the LW devs and beta testers that Java on OSX has always been below par compared to other OS's. And if you check java history of releases for mac, you will find some were a bit buggy for one reason or another. But then it's not a simple issue, since it needs to tie in with the system, etc.

Would like to see Stief's input here, since I am less involved in betas than I used to be.

The change in location of download prefs for the beta is an interesting one. Makes one wonder that if you delete your LW prefs folder, you may also be deleting your download prefs which doesn't sound good. For windows new version LW, they changed the download location, which has confused many people who couldn't find their downloads ... like you, but of course different reason.

[davidf01]

* re: java::

u misunderstand my point about apple gear at sun: many devs at sun (presumably java not solaris hehe) _use_ mac laptops ... but yes they do not work on the osx jdk (apple does that) ... and yes java on mac has always seemed in a state of neglect (just look at the ridiculous delays in java6).

* re java6::

so LM is being built against java5, correct?

* re DL history::

yes, the beta stores the control files (dat/bak) inside the prefs folder not inside the working folder ('incomplete') ... so that has saved my *** from te crruption czuased by teh last crash :-) ...

however, i agree that it might not be a good idea to put transient data in the same location as static data.

btw: i dont understand why u say that the download folder ('incomplete') - ie the working sirectory - has been moved!? ... it still is in the same place that i manually assigned it to be located (thougfh there is a strange artifact of seeing a limewire folder - with a reference to purchases from the "store" - located at the root of my user account!?