patch1

Thanks I take it that means [T] is all that is really required to support partial file downloads ([C] is not essential) Either way it points to a mldonkey problem. Currently looking at replacing it with some other perhaps using X11 redirects on the headless server.

Mek I think you are spot on the mark. The person I was mainly trying to download from was running a new computer / set up. I got confused as a second person I tried to download from also had no [C] with the same result. When I tried a third person it worked as expected, supporting [C]. As it turns out the new system I was trying to download from is A FreeBSD server, which runs a CentOS vm The files are shared from the FreeBSD system to the CentOS box by SMB The CentOS vm runs mldonkey. Debug window shows mldonkey "Supports MiniSlots XmlBZList ADCGet TTHF" vs ApexDC "Supports MiniSlots XmlBZList ADCGet TTHL TTHF ZLIG" Getting the other user to mount the files via another computer running ApexDC enabled [T][Z][C] from that client. Interestingly I could then download from the original mldonkey client using [T][C] but the user list then showed that client greyed out. (still with a blue shield) So yes it looks like a problem with mldonkey capability or configuration. Anyone know a better client for a headless Linux server?

If a download is interrupted for any reason then it goes back to the start of the file even if 12-50% of a 0.7 to 4.5GB file is already downloaded. Stopping and restarting ApexDC reliably demonstrates this. I have noticed this behaviour since upgrading to 1.3.4 which I did from the previous version (1.3.3) via the installer, retaining the previous configuration in the process. The downloads start with [T] or [T][Z] ie do not contain [C] Enable segmented downloads is ticked. I couldn't find any other relevant settings but that maybe as I don't know where to look. What am I doing wrong or is this normal? btw I am running windows 7 ApexDC runs from an ordinary users account (not administrator), and the program is installed into the program folder (c:\Program files\ApexDC\).

I agree auto update should be able to be readily disabled by the user, ApexDC then having no reason to phone home. I use ApexDC only on an internal network, unmetered by my ISP, and strongly prefer ApexDC accesses no addresses outside this private range. I enforce this via my PC firewall, which does prevent ApexDC from phoning home atm.

Agree it could be improved but this probably isn't going to happen. See earlier discussions

+1 I find ApexDC has trouble rehashing (at start up & refresh) what has previously been added. Seams to be more an issue with path length, not depth as I have some long directory names without reaching 15 levels deep. Yep, I can remember asking a similar thing in the past and believe I got a similarly useful answer. The point is I would prefer not to have my filing system limited by ApexDC limitations. None the less I do appreciate the comment which I interpret as "As a programmer of much of the code, I can see much better ways to spend my time than on this feature"

Agree automating display of what is new on a hub is desirable. I suspect the ideal solution varies depending how many users are typically logged into a hub. If the hub us reasonably large with many users contributing information with considerable overlap, then a release system displaying the information sorted in topic groups is going to be preferred, probably together with a flexible search engine with saved searches. This was also discussed here. The difficulty being how to create a high level categorized display with minimal effort by the person uploading, where the display benefits the downloading user. If the hub is relatively small with only a few users adding new content, then it is probably more efficient to have an easy way to display new content from these users since a time I looked in the past. As this is my situation I'm particularly interested in it. See here of which I suspect retaining the information from previously displayed file lists, then displaying differences would provide the most useful display.

I would prefer it isn't. The suggestion is posted in a feature request forum. We know it keeps the hash tables, so could re-share when they became available. Safe automatic re-sharing when available would probably also require showing the current share as well as potential share in the setup screens. It's inclusion would benefit at least some users. It has not been implemented yet.

I agree some method of being able to browse new additions to a users share would be very valuable. Similar thread looking at time stamps or difference from previously viewed file lists Another more automated announcement script The fact there are multiple threads suggesting different methods of viewing what is new in another users share suggests there is a genuine need. My order of preference for the solutions is 1) Filter users file list to exclude things that were there when I looked in the past (old file list filter) 2) Date stamp other users filelist (problem with file list download time & server compatibility) 3) Computer assisted announcement thread, as described here. (Could work well but required poster to do work of no direct benefit to himself (only other users) 4) Automated announcement script. (risks large volume low information density - eg different announcement for each file in multi-part object (rar files, .nfo etc).

Thanks Crise It was several things I run ApexDC as a normal user (no admin privilages) While running my usual instance of ApexDC I choose it update at the start up prompt ESS detected the application modification, I clicked allow (as normal user) Above appeared to cause 2 problems Wrong read write privileges for new ApexDC files (fixed by resetting inherit read/write/ modify privileges to all files in ApexDC directory) ESET not remembering application change allowance (fixed by restarting computer, login as administrator, run new ApexDC, approve application modification).

Since upgrading to ApexDC 1.2 I can no longer connect to any hubs. Works fine if I downgrade to 1.2 beta Works if I disable the firewall. Anyone found a way of making them work together? BTW I'm running XP professional ESET ESS V4, Firewall in interactive mode. Firewall log occasionally showing "No application listening on the port" Source 0.0.0.0:68 Target 255.255.255.255:67 Protocol UDP

1) Some method of readily finding things added to some ones share since last I looked. I prefer a local store (or database) of filelist contents as this would be a client side change and storage penalty could be customised by user wanting the feature. For discussion / details see http://forums.apexdc.net/index.php?s=&...ost&p=22114 2) If external drive with share content goes offline, try and reconnect next time file list is refreshed or ApexDC is restarted. For discussion see http://forums.apexdc.net/index.php?showtopic=3123 BTW, this probably should be a poll thread to give some idea of user priorities (which developer could take note or ignore on a case by case basis).

The problem with an automated system is it would tend to broadcast detail and not concepts. For example if a shared a new album with 20 mp3 songs, would that generate 20 new release messages Or if a shared a movie with 40 par files would that generate 40+ new release messages. If I renamed a high level directory that may generate 1000's of new release messages (unless there is the facility to restrict monitoring to a subset of the share and I'm carefull to not rename folders within this share) - ??complexity and error prone by naive users. A possible solution would be only broadcast the highest level directory which was new (so only announce the folder containing the album or movie, not the individual files). Coding this maybe more difficult though as files a added and hashed one at a time. Some sort of time out would be needed to ensure a further files were not being added to the set, prior to additions being announced.

I agree it is not hard for me to do, it simply requires me to be there and notice the problem. However I run ApexDC on my folks computer (I put a link in the start up folder). I visit there every few weeks. As a result "me to be there" is not a trivial requirement. Also "notice the problem" should be done much more efficiently by software than a human. So I would like to add support for not automatically un-sharing folders which become (temporarily) un-available.

To see what is new I think I would prefer drop down menu in the file list screen enabling ready display of changes since I last looked at that file list. As described http://forums.apexdc.net/index.php?s=&...ost&p=22114 The reason is an automatic system would be spammed by minor changes to the shared files. For example changing the genre or album art for several mp3 albums would trigger lots of low value traffic. Renaming a root directory may also generate lots of messages depending how the software was written. BTW I fully support some way of readily finding out about newly shared files on small hubs. I suppose I just have little experience with the solutions you propose.