SABnzbd Forums

How do I get Media Rover to name it like this:

Showname - S01E01 - EpisodeTitle

Instead of:

Showname - s01e01 - EpisodeTitle

I wanna capitalize the S and E.

Lockzi, here you go.
From mediarover.conf

rollingeyeball wrote: Lockzi, here you go.

Code: Select all

		#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#
		# NOTE: Replacing a template variable with its uppercase equivalent 
		# (ie. $(series)s vs $(SERIES)s) will cause Media Rover to output 
		# uppercase data (where relevant).  For example:
		#
		#  $(season_episode_1)s => s01e03
		#  $(SEASON_EPISODE_1)s => S01E03
		#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#

From mediarover.conf

Silly me, thanks!

I'm really starting to enjoy Media Rover and how it fills in the episode that I've missed through the years as soon as they come up on Usenet.
An alternative functionality would be if it would be able to do it's own searches on Newzbin for all the episodes that are missed. It really is a pain to use TV Rename's missing episode function when you have slightly over 2tb series because it lists all the specials and so on as well.

For me the functionality of Media Rover hasn't gotten to the "Donate 30$ regard" yet, but you sure are working your way up to there!
I can say though that a lot of people seem to be owing you a lot of thanks! Like previously noticed, look at how big this thread has gotten!

Cheers,
Lockzi

Lockzi wrote: An alternative functionality would be if it would be able to do it's own searches on Newzbin for all the episodes that are missed.

One of the things I would like to explore with the new UI (if I ever get the first version done that is) is doing just that: searching for older episodes.  Ideally, I envision searching for existing episodes would be part of the process when adding new series folders via the MR UI.  Someday 

Kierse

One of the things I would like to explore with the new UI (if I ever get the first version done that is) is doing just that: searching for older episodes.  Ideally, I envision searching for existing episodes would be part of the process when adding new series folders via the MR UI.  Someday  Wink

Kierse

Just throwing this out there for sometime in the future, perhaps.

It'd be cool if there was a catchup option. Catchup would only get older episodes and in order.
For example if there are 7 seasons of a series but you only have seasons 1, 2, 3 and half of season 4. When MR goes looking for new episodes, if you choose this feature it will auto ignore any episodes in seasons 5,6 and 7. Maybe even any episodes not specifically the one you want.  It could be configurable.

Ran into another failed episode retrieval, using latest mediarover

Log states:

2009-10-21 07:00 INFO - --- STARTING --- - __init__.py:93
2009-10-21 07:00 INFO - begin processing tv directory: \\media1\video\serier - __init__.py:142
2009-10-21 07:00 INFO - watching 24 tv show(s) - __init__.py:192
2009-10-21 07:00 INFO - begin processing sources - __init__.py:195
2009-10-21 07:00 INFO - found feed 'x264 shows' - __init__.py:211
2009-10-21 07:00 INFO - watching 1 source(s) - __init__.py:242
2009-10-21 07:00 INFO - processing 'x264 shows' items - __init__.py:305
2009-10-21 07:00 ERROR - unsupported item title format - error.py:45
2009-10-21 07:00 INFO - skipping '****.S07.E05.720p.HDTV.x264', unknown format - __init__.py:318
2009-10-21 07:00 INFO - finished processing source items - __init__.py:433

**** = modified for forum policy

looking at rs feed from mytvnzb.foechoer.be, feed entry looks like:
-----------------------------------------------
****.S07.E05.720p.HDTV.x264
21. oktober 2009, 06:32:32
*.*.*.*. 7x05
-----------------------------------------------

Using:
mediarover on sabnzbd 4.11
Python 2.5 (2.5.6)
windows 2003
2 gb ram
2 TB disk

This caused by sloppy naming on www.tvnzb.com or?

NB! whan manually accessing the rss feed i'm able to d/l the file...

Looks like it, S07.E05 should surely be S07E05

How are people dealing with passworded episodes?  My automated process fails.

Can you specify no passworded reports in newzbin RSS?

How are people dealing with passworded episodes?  My automated process fails.

Can you specify no passworded reports in newzbin RSS?

I haven't had a single issue yet.

I believe (and this is totally without proof) that there will be a tag option in advanced searches soon though.
I mean, the tag system is being implemented.  Surely there will be a tag option in searches.
'passworded' is a confirmed tag. Hopefully there will be an 'exclude tag' option in searches.

I just wrote alot and said nothing. Damn.

I have a south of canada non mother episode that is repeatedly picking up a passworded report

Just wondered if there is a way to exclude them, so it's Newzbin that are working on the exclude tag search?

Goriem wrote: Ran into another failed episode retrieval, using latest mediarover

...

2009-10-21 07:00 INFO - skipping '****.S07.E05.720p.HDTV.x264', unknown format - __init__.py:318

I agree with daniel_owen_uk, MR has a series of regular expressions that it uses to scrape data from an nzb title.  Currently, the tvnzb plugin won't accept titles with a '.' between the series and episode numbers.  Keep an eye on it for me; if this isn't a naming error and is somewhat common, I'll update the tvnzb plugin to handle this case.

Kierse

daniel_owen_uk wrote: I have a south of canada non mother episode that is repeatedly picking up a passworded report

Just wondered if there is a way to exclude them, so it's Newzbin that are working on the exclude tag search?

I've run into a couple of passworded nzb's too and I've been meaning to look into them.  Does newzbin have a standard method for dealing with passworded downloads (eg. is "(Passworded)" always appended?  I suppose I could add some logic to ignore these type of nzb's the only problem will be that if there isn't some sort of a convention then MR will likely miss the odd one.  On the other hand, if there is a convention, it should be trivial to filter them out with custom search

Kierse

Why do you index things with passwords?

Because things with passwords are posted to usenet, and Newzbin indexes usenet. Once a member (or ten) has downloaded the post and made a site comment letting us know, we modify the report, appending (Passworded) to the title. Usually none of the information made available to the Editor at the time the report is made will alert them to the fact the archive is passworded. The only way to know for sure is for someone to download it. Editors will still report known passworded archives even if the password eludes them at the time of report, this is to encourage a premium member to discover the password and provide it in a comment.

Why don't you remove reports with passwords from the index?

   For several reasons:

       * Someone might discover the password and provide it in a comment, immediately rendering the passworded status irrelevant.

       * If we removed the passworded report, when a member came back to the site to make a comment that an archive that has just completed download is in fact passworded, they wouldn't be able to find the correct report to make a comment (because it'll now be de-indexed). This vastly increases the chance that they will find a clean report and make the same claim on it. Before long, this situation cascades into the index being completely empty. It's just the nature of Newzbin that there is a time lag between making a report and the first comment identifying an archive password. Between those two events, countless people may have already seen the report and taken a NZB - many from automated RSS/ATOM feeds. Each one of them could in their own time come back to the site and cause a good report to be de-indexed, which means a single passworded report has the capability of removing countless reports from the index if we were to respond in that manner.

       * Essentially, Newzbin is an index of what was posted to usenet. Knowing that a bunch of raw files contains an archive that is passworded has some value... more value than not knowing this, which would be the case if we removed the report. Letting the report stand provides editors and members with useful information. Conversely, removing it makes everyone more ignorant.

Found here
http://docs.newzbin.com/index.php/Support:FAQ_General


So basically, yes appending (Passworded) is standard, but at the time media Rover kicks in it's highly unlikely to have been marked already.
=/

SAB should include automated rar password cracking! lol

kierse wrote:

pilGrim wrote: - I am getting an error that says I need to declare at least one root_tv directory.  My setting is: tv_root = M:\TV Shows   Do I need to format this differently?

Your declared tv_root directory has a space in the name, try wrapping it in double quotes like so:  tv_root = "M:\TV Shows".  I'm guessing the space is throwing off the config parser.

Hi Kierse,

Can't wait to test out the download name matching my folder name, but.... Still having issues with above issue.  I did put the path in quotes as suggested and still get the error.  I would just change to M:\TV but that has many issues downstream with XBMC and other programs.  Any other suggestions?

TIA

Thanks rollingeyeball, I wasn't aware that there was an official policy.  Now that we've established how passworded downloads are handled, how should we proceed?  Do people want to leave that up to the user to filter out in Newzbin or would they prefer the option to have Media Rover do it?  Adding a flag to filter them out in the newzbin section of the config file would be fairly trivial.

Kierse

pilGrim wrote: Still having issues with above issue.  I did put the path in quotes as suggested and still get the error.  I would just change to M:\TV but that has many issues downstream with XBMC and other programs.  Any other suggestions?

Hmmm, and you're positive that 'M:\TV Shows' exists on disk as spelled in the config file?  Can you post the error (including a few lines before) and your config file somewhere.  I don't have anything else to suggest at this point without additional info.

Kierse