SABnzbd Forums

Alright, too bad, some people really don't like that option (or don't know about it?), so I always suggest it.

Newzbin is pretty good to avoid dupes - It's too bad Media Rover doesn't do queue checking, SAB Smart Downloader did, but it was a bit buggy.

-Markus

For those that want some shows in HD and some in standard XviD what you could do is have one Newzbin search per series/show. Just set the attributes to whatever you desire (HD or SD).
It'd take a little longer to set up than using one big *new shows* feed but it'd guarentee you got what you wanted.

Just putting it out there for anyone that hadn't thought of it.

jayman wrote: I'm pretty sure it doesn't check the queue

rollingeyeball wrote: I suppose it really needs queue checking then.

Queue checking works fine in Media Rover for me :
Not sure why you guys think it's not in there?

it's not checking the download que, the que that is talking about is that current running of media rover.  I talked to Kierse about it and he may have it check the nzb backup folder in an upcoming release. 

rollingeyeball wrote: For those that want some shows in HD and some in standard XviD what you could do is have one Newzbin search per series/show. Just set the attributes to whatever you desire (HD or SD).
It'd take a little longer to set up than using one big *new shows* feed but it'd guarentee you got what you wanted.

Just putting it out there for anyone that hadn't thought of it.

thanks.  that does help.  there is a limit on the number of rss feeds I think.  You can't do more than 11-12 in my testing.

I talked to Kierse about it and he may have it check the nzb backup folder in an upcoming release. 

He's released it actually, I'm having some troubles with it. getting some errors. I'd like to hear if it works for you?

there is a limit on the number of rss feeds I think.  You can't do more than 11-12 in my testing.

I didn't know that. Bummer. Good bit of info to know though, thanks.

jayman wrote: it's not checking the download que, the que that is talking about is that current running of media rover.  I talked to Kierse about it and he may have it check the nzb backup folder in an upcoming release. 

Well in that case I'm confused at how it manages to not re-queue shows in my download queue IYSWIM. If I run Media Rover several times with the same feed I never get duplicate downloads in my queue, so I assumed the "download queue" I pasted above was exactly that...

SAb already kills duplicate nzbs. Check your warning log, it's probably that.

Nope, nothing in my warning log. The Media Rover script never attempts to add a show to the queue if it's already there. It checks the disk first, if it doesn't exist already on the disk it then skips it if it's in my download queue already. If I delete that item from the queue it gets re-added next time I run the script.

rollingeyeball wrote:

I talked to Kierse about it and he may have it check the nzb backup folder in an upcoming release. 

He's released it actually, I'm having some troubles with it. getting some errors. I'd like to hear if it works for you?

there is a limit on the number of rss feeds I think.  You can't do more than 11-12 in my testing.

I didn't know that. Bummer. Good bit of info to know though, thanks.

how do you know and do you have to redownload and configure everything or can you just swap some files?

how do you know and do you have to redownload and configure everything or can you just swap some files?

Email from Kierse:

First off, I just pushed some changes to Media Rover that solve the multiple tv folder issue you ran into.  Once you update your code, you should be able to declare multiple folders for tv_root (comma separated).  Media Rover will search all folders and the sorting script will put them in the appropriate place as expected.

Second, Media Rover is now capable of scanning the SABnzbd backup directory to see if a given nzb has already been seen before (this only seems to be an issue when an nzb fails at some point and Media Rover keeps trying to download it).

The first new version had a small minor bug, but the fixed that straight away.

I wasn't sure either, but yeah just swap out the files.

I got the new version here
http://github.com/kierse/mediarover/tre ... mediarover

I love that Kierse is so responsive. I love this app.
Love all round, hehe

Hi Everyone!

Sorry for my long absence, I was out of town for a week or so and just plain forgot to check the tread when I got back.  For some reason I'm not being emailed about any of the thread updates (even though I selected to be notified).  Oh well, I'll try and check back every day or so from now on.

Here we go:

Bugs

I've read through all the new postings and have made note of all the issues people are experiencing.  I've created an issue ticket for each one in the project issue tracker and will address them as soon as I can.  The issue tracker can be found at http://github.com/kierse/mediarover/issues

Queue Checking

There seems to be some confusion regarding how Media Rover schedules new nzbs for download; specifically the topic of queue checking.  This confusion is largely my fault as I've never actually explained how Media Rover schedules new downloads.  Also, I believe I misinterpreted what Jayman was asking me in his email and thought I was answering something else.  Lets see if I can clear things up a bit:

Before scheduling a download, MR does the following:
1. check if a given episode is from a watched TV series
2. checks if the episodes season is being ignored
3. looks for episode on disk (depending on users preferences, this could be a single episode file or part of a multi-part episode file (ie s01e01-s01e02)
4. checks for episode in SABnzbd queue (see below for more detail on this step)
5. checks if episode is already in list of new downloads to schedule
6. checks the SABnzbd backup dir to see if nzb has already been seen * new *
7. finally, it does some checking based on the users preferences pertaining to multi-part episodes

If a given episode makes it all the way through all those checks, it is added to a list of downloads.  Once MR is finished processing all source feeds, each nzb in the list is sent to SABnzbd for download.

Checking the SABnzbd queue
When consuming a source feed, Media Rover does a lot of string parsing.  It basically breaks up the nzb name and extracts the parts necessary to make a successful match.  Here's an example using the Newzbin nzb naming convention:

Some Awesome Show - s01e10 - What A Great Episode.nzb

Media Rover is able to extract the following:

series name = "Some Awesome Show"
season number = 01
episode number = 10
episode title = "What A Great Episode"

Note: the same process happens when Media Rover builds a list of episodes in the SABnzbd queue and when determining whats available on disk.

Continuing with the example above, MR would then use the data it extracted to see if the new episode is in the queue or on disk.  Because the whole process is dependent on some string parsing, it can be unreliable at times.  That's what makes Newzbin so awesome: it has a community standard of sorts when it comes to naming episodes.  This makes it much easier to get reliable results when processing feeds.

Anyway, doing this kind of data based check vs only doing a nzb check has a couple benefits:

1. If more than one nzb is encountered, only the first will be downloaded (hopefully)
2. nzbs for the same content from different sources won't get downloaded. 

The reason I added the nzb backup check was because I have encountered a few situations where Media Rover attempts to download a broken nzb over and over again.  SABnzbd obviously ignores these duplicates but MR keeps on trying.  The added bonus of this feature is that if an nzb makes it past the data based check when it shouldn't, the backup check will catch it.

Hopefully that clears things up a bit.  If not, please let me know

Project Management

Now that there are a few people using MR, I think the time has come to make some changes to how I've been running things.  First of all, I'm going to start publishing a changelog somewhere.  I'm not yet sure where I'll put this but it'll probably be added to http://mediarover.tv.  Second, I broke Media Rover yesterday when I pushed some code that wasn't quite ready for public use.  Even though I solved the problem fairly quickly, it did make me realize that I'm not the only one put out when I break things.  Going forward, I plan on rolling some actual releases that users can download and use with confidence.  I'll continue to push code updates that anyone can download but I won't be as concerned about breaking things between releases.  Third, I'm interested in formalizing a process to get input and feedback from users.  Do any of you out there have any suggestions?  Something like https://uservoice.com would be interesting.

Future

As rollingeyeball pointed out, I'm currently working on a UI for Media Rover that will hopefully simplify the process of configuration.  Once that's done, my plan was to tackle the Standard def vs HD topic that a few people have asked for.

---

That's all for now.  As I've told a few people, please send me your questions/comments/concerns.  I'm all ears!

Kierse

Hello,  I'm just trying to get this installed for the first time, I've downloaded the most recent version, July 15th download you just put up yesterday.  When I try and run it after writing the config files.  I have been backwards and forwards through the wiki and forum and I can't seem to figure out where the problem is.  Can you help me out a bit?  TV root is set to f:\ Here's the error I'm getting:

D:\mediarover>mediarover.py
2009-07-16 10:30 INFO - --- STARTING --- - __init__.py:91
2009-07-16 10:30 ERROR - TV root rootectory () does not exist! - error.py:45
2009-07-16 10:30 ERROR - TV root rootectory () does not exist! - __init__.py:98
Traceback (most recent call last):
  File "D:\mediarover\mediarover\__init__.py", line 96, in main
    _process(config, options, args)
  File "D:\mediarover\mediarover\__init__.py", line 133, in _process
    raise FilesystemError("TV root rootectory (%s) does not exist!", root)
FilesystemError: TV root rootectory () does not exist!
Traceback (most recent call last):
  File "D:\mediarover\mediarover.py", line 19, in
    mediarover.main()
  File "D:\mediarover\mediarover\__init__.py", line 96, in main
    _process(config, options, args)
  File "D:\mediarover\mediarover\__init__.py", line 133, in _process
    raise FilesystemError("TV root rootectory (%s) does not exist!", root)
mediarover.error.FilesystemError: TV root rootectory () does not exist!



Thanks for your help let me know if you need further info!

Hmm, it looks like Media Rover doesn't like whatever you've got set for tv_root.  Can you post that line from your config file (exactly as it appears in the file)?

I was just checking if MR perhaps doesn't like such short paths
I was getting some errors and thought ahhh, but then i undid my changes to the .conf and the errors still came  ::)
It seems I've been getting errors in the logfile since about when I upgraded.

2009-07-17 03:20 INFO - processing 'newzbin_allnewtv' items - __init__.py:313
2009-07-17 03:20 ERROR - list index out of range - __init__.py:98
Traceback (most recent call last):
 File "F:\Python\Scripts\Mediarover\mediarover\__init__.py", line 96, in main
   _process(config, options, args)
 File "F:\Python\Scripts\Mediarover\mediarover\__init__.py", line 324, in _process
   episode = item.download()
 File "F:\Python\Scripts\Mediarover\mediarover\sources\newzbin\item.py", line 33, in download
   self.__parseItem()
 File "F:\Python\Scripts\Mediarover\mediarover\sources\newzbin\item.py", line 70, in __parseItem
   if self._report_category() == "TV":
 File "F:\Python\Scripts\Mediarover\mediarover\sources\newzbin\item.py", line 94, in _report_category
   self.__reportCategory = self.__item.getElementsByTagName("report:category")[0].childNodes[0].data
IndexError: list index out of range

EDIT: .. Nevermind. My bad. I changed my Newzbin password so the feed was dud, hehe

Also, for the record setting E:\ and F:\ as tvroot work fine for me.
As does setting multiple tvroots now, which Kierse might explain in the changelog