gadasch

Here's a headline: WHY NOBODY SHOULD HAVE FALLEN FOR THIS APRIL FOOL --or-- THERE NEVER WILL BE A RELEASE 1.0 Shall I be cynical? Of Course I shall...!! :thumbsup: There is a reason why open source software using volunteer staff never gets to Release 1.0: Because it would require somebody to write help files and other documentation. Which, of course, nobody ever will. Much easier to just keep adding digits to the right of the decimal. You will see Release 0.99.99.99.99.01 long before you will ever see Release 1.0. And it still won't have help files or a manual. Thus, we discover the deeper meaning in the April Fool joke! Delight me and prove me wrong! ..gadasch

Yes, not intending this as a rebuke, but your reply to my post was off-topic and sort of resulted in the thread taking a wrong turn. Let me try to get back to the subject: MORE INFORMATION (on the original problem): I can confirm now that Auto Refresh is not always working properly (at least it is not always detecting additions to the share), even though it appears to run as scheduled. My "Auto refresh time" is set to 180 minutes (3 hours). About 13 hours ago, I added a new folder to my share. Within 30 minutes, the Hashdata and Hashindex files had been updated. The list file (files.xml.bz2), however, continued to show a timestamp of early yesterday morning (some 30 hours ago) and the new folder did not appear in the list when I opened it using File\Open Own List. I understand now (from somebody's earlier post) that the files.xml.bz2 file is not actually updated until somebody requests it, either via upload or via File\Open Own List. However, 13 hours and 4 auto refresh cycles after I added the new folder, the list file continued to show the yesterday-early-morning timestamp, and it did not update despite several people uploading it and me opening and closing my "own list" repeatedly. HOWEVER, just now I initiated a manual refresh using the menu command File\Refresh File List. After the manually-initiated process completed, I opened my list again. At this point, the timestamp DID change and the list that opened was a new one that included the new folder. I'm pretty sure this is new behavior in v0.3.0. Something in the Auto refresh process is not always properly detecting the fact that changes in the content of the share require a new list to be generated. Thanks, ..gadasch

STILL MORE INFORMATION Another refresh cycle just occurred. This time the list got updated. I have made numerous additional changes to my share in the past several hours, so I presume that caused the update to succeed this time. It isn't obvious why the list didn't get updated on the previous two refresh cycles. The original change to the share was non-trivial (the complete replacement of one subfolder with another having a different name and mostly different contents). That should have been enough to cause the list to be updated during the next refresh. The fact that it didn't suggests that there are circumstances in which the client is not properly recognizing share alterations that require a new list to be built. ..gadasch

Yes, I noticed that. But it isn't always happening. Another auto update time has just passed. I opened my list again and the contents still haven't changed. Timestamp on the file didn't change when I opened it. The old folder which no longer exists in my share is still shown; the new one isn't. In the past several hours my list has been requested and sent out several times... all, I presume, with obsolete contents. ..gadasch

MORE INFORMATION: Okay, I just caught it in the act. Several hours ago, I replaced one of the subfolders in my share with another folder (the replacement folder had a different name and mostly different contents). When time came for the auto refresh to occur, I could see the client scanning through all the folders... so the auto refresh DID kick off on schedule. HOWEVER... the files.xml.bz2 file in the Settings folder did not change. The HashData.dat and HashIndex.xml files were both updated, but the bz2 file was not. When I open my list, the old folder (which no longer exists in my share) is still present in the list. The new folder is not shown. So the autorefresh kicked off on schedule, but the list was not updated. Never saw this problem prior to v0.3.0. Thanks, ..gadasch

Why are you being so argumentative? I am neither a developer nor part of an official test team for the ApexDC client. I am simply a user who would like to see the client continue to get better. I am doing my duty to report bugs I find, large and small. I don't really care whose software is layered on top of whose. In general, I think the developers are doing a great job as volunteers on this project and I appreciate their work. If not all bug reports are going to get attention, so be it. I know the drill. ..gadasch

Seems to me that auto refresh has become less predictable in v0.3.0. Mine is set to 180 minutes, but changes I made in my share last night were not reflected in the list this morning. The files.xml.bz2 file's timestamp was over 18 hours old, though the HashData.dat and HashIndex.xml files had been updated. I had to do a manual refresh, after which the contents of the list were correct. In any case, hashing and list generation seem to be happening on different schedules. Maybe this has always been this way. I noticed in 0.2.2 that it seemed to take two update cycles for new files to appear in the list. I assumed this was because the hashing process was somewhat independent list updating. But now the list generation process also seems to have become unpredictable, not always happening with the frequency specified in the auto refresh time setting. Did something change here? Is there a new bug? ..gadasch

You're probably right but I don't have/use either one of those clients. Hardly seems worthwhile to go get them just to identify the source of a typo. Was hoping the origin of the message would be immediately obvious to Apex developers and somebody could notify the correct party. Forgive me, I realize that many of the developers are not native English-speakers, and I'm not here to criticize anybody's English skills. But misspellings like that really should be corrected because they give the impression that the developer was careless. ..gadasch

I agree with your point about typos. Here's one I pointed out several releases ago that still has not been fixed: During list generation, there is a progress message that includes the phrase: "user has choosen not to share..." The correct spelling of the past participle of the verb "choose" is "chosen" (choosen is not a word). Please fix. Thanks! ..gadasch

After running v0.2.2 for weeks without incident, I just had the second crash in 24 hours. This time, I returned to the computer after being AFK and pressed the "Download queue" tab (that tab was open but not currently displayed), whereupon Apex crashed immediately and before displaying the contents of the tab. The exceptioninfo file contents are as follows: Code: c0000005 Version: 0.2.2 Major: 5 Minor: 1 Build: 2600 SP: 2 Type: 1 Time: 2006-10-18 15:44:20 TTH: OMHC4NRJLW265TOPH2JTNVVMXH2KAFDJSNQPYAA d:\cvs\apexdc++\022\windows\queueframe.cpp(200): QueueFrame::QueueItemInfo::update d:\cvs\apexdc++\022\windows\queueframe.h(299): QueueFrame::QueueItemInfo::getDisplay d:\cvs\apexdc++\022\windows\queueframe.cpp(1470): QueueFrame::onCustomDraw d:\cvs\apexdc++\022\windows\queueframe.h(92): QueueFrame::ProcessWindowMessage ..gadasch

Looks like I saw the identical crash. I had been AFK for some time. Client was proceeding with a segmented download from multiple sources. Here's the exceptioninfo FWIW: Code: c0000005 Version: 0.2.2 Major: 5 Minor: 1 Build: 2600 SP: 2 Type: 1 Time: 2006-10-17 21:57:56 TTH: OMHC4NRJLW265TOPH2JTNVVMXH2KAFDJSNQPYAA d:\cvs\apexdc++\022\client\filechunksinfo.cpp(755): FileChunksInfo::getChunk d:\cvs\apexdc++\022\client\filechunksinfo.cpp(160): FileChunksInfo::getChunk d:\cvs\apexdc++\022\client\queuemanager.cpp(1069): QueueManager::getDownload d:\cvs\apexdc++\022\client\downloadmanager.cpp(259): DownloadManager::checkDownloads d:\cvs\apexdc++\022\client\downloadmanager.cpp(669): DownloadManager::on d:\cvs\apexdc++\022\client\speaker.h(69): Speaker<UserConnectionListener>::fire<UserConnectionListener::X<2>=0x029BAB00,UserConnection *=0x04FCFE4C,unsigned char *=0x04FCFE5C,unsigned int> d:\cvs\apexdc++\022\client\userconnection.h(375): UserConnection::on d:\cvs\apexdc++\022\client\speaker.h(60): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x04FCFE00,unsigned char *=0x04FCFEB8,int> d:\cvs\apexdc++\022\client\bufferedsocket.cpp(260): BufferedSocket::threadRead d:\cvs\apexdc++\022\client\bufferedsocket.cpp(528): BufferedSocket::run d:\cvs\apexdc++\022\client\thread.h(134): Thread::starter f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex ..gadasch

I also noticed this problem. And I don't think i'm imagining things when I observe it started after the upgrade from 2.1 to 2.2. If it was happening before that, I didn't notice. But it's quite evident now. It might be worthwhile for the developers to doublecheck the program logic. I really don't believe that all uploads that should be appearing in Finished Uploads really are. Thanks, ..gadasch

Granted, but you're telling me there's no way to tell that two requests coming from the same IP through two different hubs are from the same requestor? If that's true then it seems like a deficiency in the send/receive negotiation protocol...whatever that's called in the DC++ world. And, as noted previously, I'm observing this even when the nicks are the same in both hubs. Not trying to start a technical argument here. Was simply trying to find out if the inability to prevent the allocation of multiple upload slots to the same requestor was my misunderstanding or a real software issue. I guess the answer is that it's a real issue. Thanks, ..gadasch

No, actually the nick and the IP are the same most of the time (on both ends). But even if they weren't, seems like multiple upload connections to the same IP should be controllable. If the sender wants to allow it, fine, but the default should be one upload slot per IP. gadasch

Is it the case that there are no controls for the number of upload slots a single user can occupy? The problem occurs when another user and I are both connected through more than one hub. In this case, the software allows the other user one upload slot for each hub we share. Same thing happens in downloading, of course. I find myself in the "embarrassing" position of seeming to demand more than one slot from a sender just because we happen to be in more than one hub together. This seems wrong. Either the software should prevent one user from occupying more than one slot, or there should be controls to set the number of simultaneous upload slots allocated to one user, with the default being one. I have waded through all the settings more than once looking for such controls and cannot find them. I can't believe there isn't a way to control this, but if there is it's not obvious to me. What am I missing? Thanks! gadasch