By limiting downloading to one file I seem to get a higher percentage of correct downloads.
This might have something to do with
- I`m only downloading large, 100-200MB files
- copying these from the temp-directory, to a primary file and then to the final file seems to be a problem, demanding too much CPU time??
- I`m runninng OE-P on a 800Mhz Pentium, but for some reason the hard-disk system is "slow", using a lot of CPU time when this is done.
- additionally, there is the "Recycle Bin" stuff, and I`m additionally running the Norton version. That is, when moving, deleting,etc these large files, other downloads stop.
- I`m using a 40 second delay-between but does not help 100%??
That is, my present prroblem is that even that one download-thread stops after maybe 3-4 dowloads. Restarting sometimes works, but sometimes "RTSP0" is stuck, although if I change numb-threads to 2, this second download starts OK.
However, when closing OE-P after this has happened, I have 2-3 times got a "pointer" error message, as well as some blue screens when OE-P tries to finalize s file.
Additionally I have noted, a couple of times, that "the files get messed up", that is, one file actually containes (at least) some partial ccontent of another file. For example, one rm-file which should be some 1000MB is maybe 10-30MB, and containes the headers (the name of the content) of another one.
That is, is there any way to get "better" log-info on these large downloads?? Like size when the temp-file is done, move to the download directory, etc??
Or is there, but I have not found it??
PS Tough to replicate due to this large files
I fixed one RTSP-related bug when next downloads were not started properly within a long time. I fixed it just before releasing 2.9 SR3 version. Can you please download it and try to see if it works better?
Please keep me informed.
> I fixed one RTSP-related bug when next downloads were not started properly within a long time.
Thanks, will do so.
But totally missing a download is not that bad (except when using only one thread and then it gets stuck), these "corrupted" downloads are worse..
That is, I have noticed that OE-P gets stuck when starting a download, so I should see the difference.
I have "debugged" some of corrupted downloads, reading the DATA header, calculating where the INDX table should be,etc.
It seems like the INDX-tag that is there is in the file is some 20-60 bytes too "early", although the INDX-header is basically correct.
Additionally the INDX-table is usually more or less missing, so the next_header address of that first INDX-header points to a position outside (after) the file (end).
Note, the data-packets are correct "until the very end", that is, I am "walking them" without problems, but without counting how many, yet.
That is, it seems something strange is happening with the last data-packets, missing??
However, given some time I will be able to check the files in a more systematic way.
(note, my original goal was and is to compare rm-files which are binary different but still contain the "almost" the same video+audio streams)
On the other hand, doing the same without installing a new upgrade helped earlier too???
Who said software wasn`t funny.. without (and maybe more with) source code.
Anyway, OE-P is great, soon me has to make than payment, the days are ticking
Note, I have 3 (all C-SPAN) OE-P projects and mainly use them by going properties and replacing the (old) list of files, copy-paste the rtsp-links to download.
#1 for what I hope to get
#2 for what went wrong with #1
#3 for what did not work for neither #1 nor #2
However, another reboot and it might seem to work differently??