newsbin.com

Is it a bug or is it a new feature?
How to freeze the download list so it stays the way I like it?

Weird thing. I move some files to the top of the list, some others - to the end. I chek: ok, the files are moved.
After a while the list gets rearranged.
Sometimes it happens when moving other items in the list, but probably just coincidence, because not always.
On the other hand, with passing time, the list gets rearranged more and more. More and more files seem to be appearing at the end of the list.

I thought, ok, let's sort the whole list by the date. A confirmation is requested: do I really want to sort the entire list?
After the list is sorted, the dates remain not sorted.
After sorting by date several times, little-by-little I finally got the dates sorted. Seems like it required several iterations or it was done with delay.

After doing nothing, just downloading, after a while the order of the dates gets again rearranged - more and more files seem to be dropped to the end of the list.
So I have most of the files still sorted at the top of the list, but at the bottom of the list more and more files are appearing with unsorted dates.
So this seems to be only a question of time: the download list is getting unsorted again.
It keeps being rearranged by itself - it seems, by dropping some files to the end of the list - but the files being dropped to the bottom are not necessarily the ones that are at the very top. They seem to be close to the top, though.

That is not normal behaviour. I wonder if the downloads.db3 file in the Newsbin DATA folder has been corrupted?

I have more than 300 GB in the list. Perhaps the size of the list causes this behavior

And I really don't want to clear the list and try again. A lot of work went into the making of the list. The order is not all that important, just a bit inconvenient and strange.


Oh!!! I previously reported issues with duplicate files appearing gradually in the download list in beta 3. Beta 2 was fine.
Perhaps the list is not rearranged at all but duplicate items are added to the end.
And also, I am downloading and downloading, and the size of files in the download list remain pretty much the same, always a bit over 300 GB while I already downloaded well over 200 GB - should be perhaps 100 GB left.
I did not see that this issue was fixed in the later betas or in RC1.
Still, I assumed it was - otherwise how come it has a RC status, this serious bug will not be left in the final 6.30 version, will it?
Because now I see that I have to switch back to beta 2 again. So 6.30 final would not be usable if this issue is not fixed.


UPDATE:

So I switched back to 6.30 beta 2:

Now, instead of > 300 GB in the download list I have only 92 GB and decreasing rapidly as I am downloading at 70-80 Mbps speed. With RC1 the download list always kept staying over 300 GB even though the download speed was similar.
And I mean, with RC1 it was 309 GB and after launching beta 2 immediately - just 92 GB. Without the duplications in the download list, apparently.

I read what is new in RC2 and this issue not fixed?

Come on, it is a critical error!

I had to switch back to beta 2 because of that.
Using RC1 was impossible.
RC1 keeps downloading the same files - once downloaded, they appear at the end of the list again.
I was stuck with 300 GB in the download list, not decreasing at all.

I don't want even to test RC2 because I don't see in the change history that this was fixed. You cannot possibly make it the final release?!
The problem continues from beta 3.

No clue. I didn't change anything that should impact this. Until more people chime in with similar problems I'm probably just going to wait and see what happens. As of this moment, you're the only one seeing this. If I can't reproduce it, I can't fix it. There have been other reports of re-ordering the list not taking but, again, I've not managed to repro it. Nor have the testers on the IRC channel. Lets put it this way, I love fixing bugs but, I have to see them first.

If you can tell me some way I can trigger this on my machine in a way I can reproduce then it's fixable. Otherwise it's not.

It could be related to how much you have in the download list for all I know.

I am really surprised.
I thought that everybody must be experiencing it.

I think, if I expanded each post and added to the download list only the inside of it, everything would be fine.
But it would be so much work.
Now, when I add a post in its original collapsed state to the download list, it is somehow added twice (as if it is added collapsed but including the inside + the inside of it added again), but the second instance actually appears in the download list when the first one is downloaded, even then, with some delay and not all at once.

I already reported this problem in another thread earlier. you responded about it as if you knew what was going on, with some explanation about "5.59 mode":
viewtopic.php?f=44&t=29835


Here, when I opened this new topic, I was experiencing the results of this behaviour and wrongly assumed that the items in the list are rearranged when, in fact, they were being added at the end of the list when they were downloaded.
So I observed this unsorted / rearranged patterns at the bottom of the list - expanding gradually as more and more duplicates were added.
At least I think that is what happened here.

As the result of it, the total amount of files in the download list does not decrease while the original files (the 1st copy if you will) are still not finished downloading.

The first copy appears in the download list in the collapsed form, exactly as I add them. The 2nd copy begins to appear at the end as groups of separate inner files only.

If I added only simple posts that cannot be expanded, or if I expanded them and added only the inner files - I think there would not be this problem.
But it would take several times longer to put files to the download list.

Anyway, both things are bad, but I think that this list re-arrangement problem might actually be the same one, not a separate issue.

Another issue I hoped for a fix before the final release was switching off completely par2 files when AutoPAR is disabled, so that renaming in descript.ion would give meaningfull information.
But it seems that you went even further in the opposite direction, judging from you comments in "what's new".....

Saying that new records show up at the bottom was all I needed to know to reproduce this It's happening because you have autopar turned off and there's a bug in some code that only fires when autopar is disabled and there's a retry. If I'd know that a week ago, I could have fixed this for 6.3. As it is, it'll be the next beta.

Is it (those retries?) somehow related to this strange thing or not:

I am observing a good download speed (as indicated by NewsBin but also corfirmed by the windows task manager and by the traffic monitor in the router)

But "Current Progress" remains completely white on all the files in the download list, no file is being downloaded

But some files have this as status:
Retry: 5 Next Retry: 0 0% Completed
Retry: 8 Next Retry: 1919 0% Completed

I don't even know how to understand this. Retry: 8, but Next Retry is not 9 but 1919.
And all those files have 0% Completed - this number not increasing either.
It seems to be related to the specific files, not to the connection to the server - if I move other files to the top - they are downloaded, Current Progress is moving.

There are other issues with files not being downloaded: sometimes after some crashes the download speed drops to 0 and remains until NewsBin is restarted. That is not so bad.

Worse is that sometimes, again, probably after some internal crashes, files are being downloaded, the speed is shown, the progress is being indicated, but the files never appear on the disk.
And still, it seems, they are indicated as downloaded in the group tab. So in some cases I believe I have those files downloaded but I really don't.
This behavior continues until NewsBin is restarted.
Anyway, I cannot use 6.30 final because of that bug in it, I am restricted to beta 2, so I don't know, maybe those issues are now fixed.

UPDATE:
Oh, I now see that even though the compound file is all white in those RETRY cases, if expanded, the progress indicator is moving on the inner files.
It seems that those files are already downloaded but being downloaded again after previous internal crashes and Newsbin restart.

UPDATE 2:
I think I put the files into the download list skipping filters and duplicate checks. Still, instead of downloading 1 time (with possibly a dupe downloaded sometime earlier somewhere else) I now see the -(0007) situation.
The same files being downloaded again and again and again. Probably because I restarted Newsbin as many times.
When Newsbin reports multiple internal crashes and eventually the speed drops to 0, I close it, start again, and, turns out, all those files are downloaded again - when a compound post in the download list is downloaded without any indication on the outer line, the inner files are downloaded from the very first again, not continuing.

Anyway, those observations are with beta2, I am not able to use any newer version because with them files keep being added to the end of the download list