consider that you use the openelec system.d to mount a samba/nfs share before kodi.service startup ( mount is done in system not in kodi) this way kodi sees the mount as local folder and its possible to for pulsar to use a workdir outside the local filesys (NAS) this is neet on systems like cubox where you have limited storage. in pulsar you set the storage path to the localy mounted folder and then ticks of "keep files after use" if you at a later time want to see the same movie again by downloading the torrent file you have a localy stored copy and pulsar does a "Checking" of this file before continueing on it or use it. this can take some time and if the network is slow (wifi) or the file is big >4gb the pulsar times out this check and is aborting.
Pulsar uses libtorrent, reading up on the manual for the library it supports "fast resume support" iam not shure this is implemented in the pulsar app to use this information, if this is implemented it will effectivly cut down on the "checking" time in the cases the storage state and piece_picker state is saved correctly (when you use stop or abort, if crash this is not saved correctly and needs a full check)
This is something that should be looked into as its a annoying problem.
consider that you use the openelec system.d to mount a samba/nfs share before kodi.service startup ( mount is done in system not in kodi) this way kodi sees the mount as local folder and its possible to for pulsar to use a workdir outside the local filesys (NAS) this is neet on systems like cubox where you have limited storage. in pulsar you set the storage path to the localy mounted folder and then ticks of "keep files after use" if you at a later time want to see the same movie again by downloading the torrent file you have a localy stored copy and pulsar does a "Checking" of this file before continueing on it or use it. this can take some time and if the network is slow (wifi) or the file is big >4gb the pulsar times out this check and is aborting.
Pulsar uses libtorrent, reading up on the manual for the library it supports "fast resume support" iam not shure this is implemented in the pulsar app to use this information, if this is implemented it will effectivly cut down on the "checking" time in the cases the storage state and piece_picker state is saved correctly (when you use stop or abort, if crash this is not saved correctly and needs a full check) This is something that should be looked into as its a annoying problem.