(2012-03-30, 03:58)tpunder Wrote: One thing to note, your api key for the various nzb sites is written to the .strm files. If you ever change that key, the files will break. Unless you save the nzb locally? Not sure how that part works of Pneumatic works.

(2012-03-30, 07:32)Popeye Wrote:

(2012-03-30, 03:58)tpunder Wrote: One thing to note, your api key for the various nzb sites is written to the .strm files. If you ever change that key, the files will break. Unless you save the nzb locally? Not sure how that part works of Pneumatic works.

Great work!! I will look into it later this weekend.
Regarding the strm files and nzb. I have an idea about a nzb cache and/or the option to store a nzb together with the strm. The problem with storing it together with the strm is that once the strm get imported to the lib, I have no way of finding the path back to the nzb...

(2012-04-01, 23:21)Popeye Wrote: I have just had the time to look through your code. Your code combined with the blackhole code could solve the issue with invalid strm links when I do the nzb backup folder lookup in pneumatic. Something you consider to implement? Do you plan to contribute the code later?
Keep up the good work!

(2012-04-02, 01:18)tpunder Wrote: Do you need me to make some changes for the invalid links? I'm definitely planning on putting in a pull request to the Sickbeard project on github to get it integrated to the main line. I'm waiting a bit to let it run on my system for awhile just to be sure it's good.

One other request, is there a way to mark an episode as watched once it completes? I've been having to do it manually which isn't the end of the world, just a bit annoying.

1. a local link and download the nzb to the local link destination
   
2. a site link and download to a common backup
   
3. just a site link.
   

(2012-03-30, 03:58)tpunder Wrote: I think this is good to go. Here's a link to the specific branch on github. Strm file support for Sickbeard

(2012-04-02, 11:08)ursli Wrote: Working perfectly here, this gave me the initiative to finally go ahead and switch to the python source for sickbeard. So far I: deleted some old shows and rescraped, manual searched and used the backlog for new shows, all without a single misfire until now. I see you forked Couchpotato on git too so I went ahead and switched from the windows binary to source there too just in case.

One (maybe silly) question, how does the update process work in sickbeard? When I use the inbuilt update does it update files from your branch or does it still use the master branch?

(2012-04-02, 12:03)ursli Wrote: Sorry for the double post but I ran into some problems with pneumatic/xbmc, I don't seem to be able to start strm files from my library any more. If I try starting a strm file it sends the request to sab then xbmc hangs.

XBMC Version and Debug log:

XBMC (11.0 Git:20120324-e4dacfa), Platform: Windows 7, 64-bit

http://pastebin.com/X0S03YEQ

If I try and playback the same nzb file with the newznab plugin it works perfectly fine, am I having some problem with jsonrpc?

(2012-04-02, 17:14)Popeye Wrote: Works here. Latest pneumatic?

(2012-04-02, 17:42)ursli Wrote:

(2012-04-02, 17:14)Popeye Wrote: Works here. Latest pneumatic?

Yes (0.2.3), sorry should've added more infos in that post.

What I've tried so far: Going back to xbmc RC2 and going back to older pneumatic versions, no change. I'm pretty sure I had it working at some point but I can't remember what changed to break it. From what I can see the debug log isn't really helpful either. Is there anything I'm missing? Going to try a clean install of pneumatic and xbmc later tonight I guess, unless anybody comes up with a magic solution I can't see right now.

- streaming set to 1 in sab - check
- newznab streaming working - check
- sab downloading when using strm files - check

It looks like instead of creating stream-able input it just downloads and processes in sab, I don't know why exactly though since the newznab streaming works.

(2012-04-02, 08:59)Popeye Wrote: No, no changes for the links. I guess a feature could be to either have;

1. a local link and download the nzb to the local link destination
   
2. a site link and download to a common backup
   
3. just a site link.
   

I posted earlier to badwornthing on how to make a local link.

(2012-04-02, 21:15)tpunder Wrote:

(2012-04-02, 08:59)Popeye Wrote: No, no changes for the links. I guess a feature could be to either have;

1. a local link and download the nzb to the local link destination
   
2. a site link and download to a common backup
   
3. just a site link.
   

I posted earlier to badwornthing on how to make a local link.

I'm probably being a bit braindead here, but let me restate those 3 to be sure I understand.

1. In the .strm, a link to a local .nzb store in some specified directory (not necessarily with the .strm file itself).
2. In the .strm a link to nzbs.org (or whatever) site and save the .nzb to some directory (not necessarily with the .strm file itself)
3. The way I have it now.

My concern is that I don't want to go messing around with the SB post processing to get it to move the .nzb to the tv show directory. Dumping all of the .nzbs to a common directory would be relatively simple.

I particularly like #1 as it removes the concern of your API key changing on the sites and breaking all of your .strm files.

(2012-04-02, 21:33)Popeye Wrote: You got it.
With the nzb backup option developed in pneumatic I will first look in the dir(dirs) for a backed up nzb, then fetch it if I cant find it. Thus, the api key can change without any issues. Having the local link, It's kind of redundant? to go look into a backup folder or?

Personally I dont like the xbmc library since the scrapers miss stuff (just use the folder name #!%) and removes vital meta data usually found in the name. So I want to browse nzb just like a any other media...

(2012-04-02, 21:53)tpunder Wrote: Ahhh, ok, I didn't realize that the plugin would send a local nzb to sab if that "local link" was set even if the url was pointed at one of the nzb sites. I'm guessing the "nzbname" part of the url is how it figures out which one to use. So #1 is actually rather pointless. #2 seems to be the ideal. I can get that added without much trouble. Should be able to knock that out this week.