No segments found

bitten

Hi,
I use the current version on Mac OS Big-Sur.
Since one or two updates ago I have an issue when adding files to download, either from external nzb sources or from MegaSearch.
I use Newshosting as the server.
When I add several downloads together, every 2-4th download gets the error:
No segments found to download
The prefetching etc. worked., the actual download fails.
But after clicking on the retry Icon the files download normal.
File type or size do not matter.
I tried raising the Socket Timeout setting to 60 secs and have disabled Concurrent Downloading, but that did not help.
Other clients (like the one from newshosting) do not have that problem.
I have enabled logging (first option), but I can not find the file.
It is neither in my temp Download or the final Download folder or in the system logs.
Any ideas?

Andre

That message can have various causes.
To name a few:

1) That a disk does not have enough space or is no longer accessible.
2) It is a corrupt archive-in-archive.
3) You have put the extension in auto delete.
4) The files are no longer complete (partly deleted) at your newsserver.
5) A ‘settings’ database file has become corrupted.

There are many more like that.

To rule out a few things, you might first start by setting Usenapp to the factory defaults. If you make a backup of these files, you can restore them later if necessary.

The tutorial to accomplish this can be found at:
https://www.usenapp.com/forum/d/324-reset-usenapp-to-default-settings

bitten

It look like the problem is related to moving the finished download to another folder.
Both folders are on different SSD USB Drives connected directly to a USB port on the iMac.
When I disable that option, all Downloads work again.
Does Usenapp wait for the the copy process before starting the next Download?
I have concurrent jobs disabled.
It could be some timing issue when Usenapp tries to access the prefetch data.
Is there any way to log that?

Andre

It is best to download to an internal SSD and then have Usenapp move the files to an external drive. This prevents the USB channel from running out of capacity and causing this kind of problem.

I don’t think disabling concurrent jobs has any effect on moving the files, but I should check that.