For Streaming: Direct Download to Folder or Delayed Post-Processing

[RonnieG]

The one problem I have with sabnzbd is if I start a download, I can also begin streaming directly out of the RAR file with a program like mplayer.  Unfortunately, as soon as sabnzbd is done downloading, regardless of if it is set to process or not, it moves the files out of the Temporary Download Folder to it's destination folder, and the stream crashes due to the file move.

I would love an option to have the Sorting functions run from the NZB filename, and have the RAR files downloaded directly into the download or sort based folder, instead of to a Temporary folder.  This would allow streaming to occur with no moved files.

Barring that, a delay in processing that keeps files in the Temp folder for a configurable amount of time would also do the trick, though not as cleanly. In this thread: https://forums.sabnzbd.org/index.php?topic=2436.0 it was mentioned there would be future support for Delayed Processing, but I didn't see it on the "Already Requested Features" page.



Thanks.

[RonnieG]

That would be it.   Though by that definition, it seems like things would get left in the temporary directory forever.  Delayed PP would probably function better.  If I can free up some time on my mobile projects, perhaps I will jump in and help tackle that Blueprint.

[shypike]

The job will end up in the history, without post processing having been done.
Just like a failed job would be (in 0.6.0).
Afterwards the user can decide to delete to "retry" post-processing.

[Usenet]

What is the status on this?
I'we done a few xbmc addons and I really want to get this function to XBMC.
Is there any way to force a "fail" in 6.0, if this is the case a job could be forced failed and the streaming from the temp folder could continue without any problems.
An additional function to get streaming working is sorting of rars unless this is also already handled (could of course be handled in an external script).

[shypike]

It's an "experimental" feature of release 0.6.0 Beta2.
You can enable the "hidden" feature "allow_streaming" (in the sabnzbd.ini file).
This will make every job land as a "failed" unprocessed job in the History.
The files will remain in "incomplete".
After watching you can decide to delete or post-process.

[Usenet]

Aha, cool. Just to understand, it's all or nothing and not possible to set per nzb?

[shypike]

That's why it's "experimental".
I added the basic code, but decided that doing the whole thing
as too much work for the 0.6.0.
It is already late because we never stopped piling on more features.

[Usenet]

No problems, can have a streaming installation for addon development. Great work!

[Usenet]

Worked great! Just one issue with XBMC, she expects all rars to be present even thought they are 0byte to start streaming. Can this be handled by SAB or should I do it in my addon?
E.g. parse nzb, create tempdir with 0 byte rars, monitor SAB's incomplete and copy files once their size doesnt change.....
If managed by SAB streaming NBZ's will work without any addons etc...

[shypike]

XBMC, she expects all rars to be present even thought they are 0byte to start streaming.

So you're asking to compensate for a bug in XBMC?

[Usenet]

XBMC, she expects all rars to be present even thought they are 0byte to start streaming.

So you're asking to compensate for a bug in XBMC?

well thats one way to see it....sorry  -  I'll file a bug report on XBMC then

Great work and I'll hope you can get this into the final 6.0 with the option to set streaming per nzb.

[shypike]

More seriously, there are a number of issues with this.

First, getting actual files from the NZB files (the subject lines in fact)
works only part of the time. About 90% of subject lines are OK but there are
still a lot of posters that screw up.
The reality is that SABnzbd only knows the filename for sure when the
first article is actually read. Which is too late for your purpose.

Second, the new retry feature checks whether files exist to decide on
whether to download missing files.
Creating 0-byte files would defeat this.
That can be fixed of course, but to change it just for the sake of
an issue (at least in my eyes) in XBMC is going too far.

[Usenet]

Thanks for important input. The api today doesn't give information about what files are in the queue right? To get streaming to work the rars have to be sorted and since we only know the names once the download has started it would have been nice to have SAB to do it or an external app..

[shypike]

I must check the API for this (the docs are still incomplete).
The problem of not knowing the filenames still remains.
It's not that SABnzbd first reads the first article of each file to get the filename.
Filenames present in the API are guesswork upto the reception of the first article.
I hope you understand that we're not eager to do serious
maintenance on the downloader internals because XBMC expects 0-byte files
(BTW: great program, I have been using it for years).

For 0.6.0, nothing of this kind will be implemented.
We want to converse asap to a Final release.

[Usenet]

I'm thankful for the queue fail function, can this be kept for 6.0?
The rest of the problem I can manage and the 0 byte problem is for XBMC..