Medusa: Allow option to download early episodes (before air date)

Created on 28 Jan 2018  Â·  52Comments  Â·  Source: pymedusa/Medusa

Currently, if an episode is available before the air date that Medusa thinks it should have, Medusa will not download, and does not even log the fact that it is declining to download the episode. The only evidence in the log is that the episode gets added to the cache, but there is no message saying why the episode is not downloaded.

Medusa very much needs to have an option to download episodes early. A global option would be okay with me. Alternatively, make it an option specific to each provider. All of the providers I use are trustworthy and almost never get fake episodes. But I know some users probably have usenet or public tracker providers where fake episodes could be a problem, so in that case they would probably want to disable "early episode download" for certain providers.

And Medusa really needs to explicitly log why it is declining to download an episode ("not downloading because it is before episode air date")

Feature request

All 52 comments

We could allow it only using the cache filled by rss. And define an offset per provider.

I don't understand the restriction "allow it only using the cache filled by rss". How would this affect which early episodes are downloaded?

I have noticed that Medusa fails to download two types of early episodes:

(1) Episodes that are available up to a week early. The most common type is when the episode is available on-demand in the morning before the evening air date, but sometimes it can be a day or two early, and once in a while, almost a week early.

(2) The first one or two episodes of a new show are sometimes available weeks or months early, as a preview. Maybe an explicit check could be added to download early episodes when a new show is added to Medusa (I mean that when the user adds a new show that has not officially aired its first episode, Medusa could check to see if any early episodes are available).

I'm not a big fan or allowing to search for episodes before air date, the downsides outweigh the _possibily_ of an episode "airing" before it's announced air date.

The solution I see is add the checkboxes for unaired episodes, so that if an user is inclined to set an episode as wanted (so that it will be searched for), he can do so.

image

No, having to identify an early episode manually completely eliminates the whole benefit of having Medusa download episodes automatically.

Also, it is a lot more than a "possibility" of early episodes. It happens quite regularly. Several shows I watch are available early every week. And the "downsides" are almost non-existent for the providers that I use, since they almost never get fake episodes.

For people with reliable providers, it makes no sense to force them to wait until the air date to download early episodes. By all means make the default not to download early episodes, but for people who want to enable that option, it should be available.

With over 400 shows i it can be very time consuming going through cleaning
fakes out. i use good providers as well but they still get fakes through
from time to time. I use both Nzb and torrents. once people realize the
program is set to download early episodes it will be filled with fakes
again. i am not against having check boxes if they want to enable early
release but would prefer it not to search as default.

On Mon, Jan 29, 2018 at 12:34 PM, jtwill notifications@github.com wrote:

No, having to identify an early episode manually completely eliminates the
whole benefit of having Medusa download episodes automatically.

Also, it is a lot more than a "possibility" of early episodes. It happens
quite regularly. Several shows I watch are available early every week. And
the "downsides" are almost non-existent for the providers that I use, since
they almost never get fake episodes.

For people with reliable providers, it makes no sense to force them to
wait until the air date to download early episodes. By all means make the
default not to download early episodes, but for people who want to enable
that option, it should be available.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pymedusa/Medusa/issues/3679#issuecomment-361323152,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGtVv7usBcfYOydyZ0iqfNK7-xZTg_1vks5tPgEygaJpZM4RvwXO
.

There is no one arguing that the default setting should be to download early episodes. Everyone agrees that by default, Medusa should not download early episodes.

This feature request is for the OPTION to enable download of early episodes.

And ripper1967, you are not using trustworthy providers if there is a chance they will be "filled with fakes". Certainly any usenet indexer cannot meet the definition of trustworthy in this context. But there are a number of private trackers which almost never get fake episodes.

There's a few benefits here - I'd like to specifically prevent downloads that were early. Saturday Night Live scene numbers have been mixed up all season this year so it always downloads the versions from 7 days prior. Would be nice to have a per-show option 1. "never early (using tracker add date)" 2. default and then 3. "always find early".

I don't understand the "never early" option you suggest. How is that different from what Medusa currently does?

I don't know but currently on Sunday morning it will find the prior week
episodes from snl due to scene mis numbering. I guess it doesn't validate
against the created-on date shown when manually searching.
On Fri, Feb 2, 2018 at 9:20 PM jtwill notifications@github.com wrote:

I don't understand the "never early" option you suggest. How is that
different from what Medusa currently does?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pymedusa/Medusa/issues/3679#issuecomment-362711002,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASBwWKCb9SXm2kFRBEgHk__AXf5hz0Rks5tQ3wlgaJpZM4RvwXO
.

I wanted to add a note to this issue: currently there are 3 separate shows I am following that get real episodes available 12 to 24 hours early every week, and of course Medusa does not download them, or even log that it is not downloading them, because they are before what Medusa thinks is the official air date.

The original Sickbeard used to download early episodes. I really miss that ability from Sickbeard.

@jtwill can you let us know which shows?

Is it important? I don't want to post it on a public forum.

It would help.
If you are so privacy concerned about the show titles, you can email one of the team members. Some of us have public email addresses on our GitHub profiles.

@duramato How do we currently handle shows that're posted on multiple cable networks or multiple countries?

I have a feeling some of those shows are released early on other networks and that's possibly why the release day/time isn't correct.

I don't think there is a repository where you can get the time that shows are posted to on-demand. Especially since sometimes they are posted to on-demand before intended (although I don't think that is the case with these 3 shows).

Better just to allow early download. Why not just change the database query to have no restriction on the beginning search date/time, and then conditionally apply the beginning air time filter later, if the user has not enabled the "download early" option. That would also allow Medusa to log cases where the beginning air time filter does decide not to download a show early.

Another example is Chicago Med: it is shown in the US on Tuesday at 10PM and in Canada on Monday(day before) at 10PM

NBC: https://www.nbc.com/chicago-med
Global: https://www.globaltv.com/chicagomed/

Bumping this thread to again ask for the feature to OPTIONALLY allow early download of episodes, since one of the shows I watch that is available early every week just started again.

Remember, I am not asking for a change in the default behavior. Leave that as is. Just add the option to check a box to allow early download of episodes. For people who use good private trackers to get their episodes, it is quite uncommon for fake early episodes to show up.

I'd be happy with a global checkbox, or alternatively a checkbox individually for each provider (but that would be more difficult to code, I think).

+1 ...
I'd suggest a new global plus per-show setting of "pre-air-date" delta-time (in hours) for starting searches for a show , defaults to 0.

Maybe I can figure a way to temorarily define it in one of the show's ignore/preferred "words" for now...

Il add a new option per show, to set the offset. And a checkbox per provider to allow using the offset.

Ill only use it for daily.

Do i cover all of your use cases?

Thanks, I think you cover it, yes, but... :

And a checkbox per provider to allow using the offset.

Why not just simplify it, and apply if for all proividers? I don't think this resolution is needed, save youself some work too... :)

Il add a new option per show

I think flexibility is important (and per-show IS the most flexible, so is needed), but ease-of-use is important too. If a user wants to just make it 24 hours earlier for all shows ( so to be on the "safe side"...) - the shortes/easiest way for him will be with a global setting, no need to do it for each and every show ...

So, I think both are needed, where the local overides the global, of-casue, and you might want to show the active one (if NOT 0) also on the shows' page, somewere near "Originally Airs:" line , so to make sure the user is aware.

Thanks, this will be very helpful to many users!

Well this should really be an exception. And its pretty show specific. Like you might have one or two shows which really requires a solution like this.

Then we still have the massupdate feature.

And last, some providers are more reliable then others, so you might want to exempt certain providers from this.

Possibly, but from the use-cases I had, it is more like show-creator oriented, like this example from HBO, or Starz, that provide early-view-ability via their on-demand service, probably as an insentive to subscribe to it...

http://www.imagebam.com/image/69093a1057334434

Sure, fine-graning per privder is fine, just nice-to-have IMHO...

The problem that I have with doing it on a per-show basis is that I have a LOT of shows, and I do not want to try to keep track of which shows are available early and which are not. That is a hassle that I want my computer to take care of for me.

I know which of my providers are reliable (i.e., almost never have fake episodes), so I think the best solution would be to have a checkbox per provider to allow early episodes. That way Medusa will automatically download early episodes of any show that is available early, while avoiding downloading fake early episodes from unreliable providers. And it requires very little work on my part. All I have to do is identify the reliable providers.

So my vote is to keep it simple and just make a checkbox for each provider on whether to download early episodes.

All of the other complications (per show, amount of time early) could always be added later, after the core functionality of a checkbox per provider is in place.

@jtwill
You need to define the time to start checking, otherwise all your shows will need to be searched for all the time every daily search. I guess this misses the whole point of Medusa doing only the required searches on time.
This is a very simple feature, no need to develop in steps... And yes, I also like not to configure this for each and every show (this is why I suggested a more global option, like you )...

@jtwill why not just start searching episodes a week early? And enable / disable per provider.

Well the reason we dont do that, is that we try to be as efficient as possible with how much we hit on our providers sites, as also how much we hit our own db. Especially with larger libraries as your self, this becomes more and more important.

So this feature is for those few exceptional shows. Its not meant as a 'it just works' feature. It will need some awareness of the user as an opt-in setting.

Has Medusa diverged so much from the way SickRage used to work? It would just capture all the new episodes that were posted to each provider every X minutes and add them to the database. Then the "daily search" would just search EVERYTHING from the database, and only retrieve the records for episodes that were not early. So it did not create any extra load to accept the early episodes.

I would be surprised to learn that Medusa does it any differently. Why would it?

The daily search only runs / collects results if there are actually episodes that are wanted. It would be pretty inefficient to collect results even if we don't want any of them. This is how it works and always has worked. Having this option on provider basis doesn't make much sense at all, as it is not a provider specific concern. The question here is about flexibility. Having it as global option would make it more flexible, but since the we are talking about a very minor % here, it wouldn't make much sense either. There are really just 2 options here IMO, what @p0psicles suggested and what @duramato initially suggested.

It is not true that is how it "always has worked". I have been a user since the original SickBeard, and SickBeard DID download early episodes. SickRage did not, but it was relatively easy to modify the code by modifying a few database queries where it limits the date of the query to only after the current date. Since I switched to Medusa, I have not had a chance to look at the Medusa code. But I am surprised that you would say it is inefficient to simply capture new episodes from providers to the local database, and then search the database for all episodes, early or not. It seemed to work fine with SickRage after I modified a few lines to let it include early episodes. I used it that way for over a year with no problems.

It would be great to enable it for RSS as a daily search.
Would not stress the providers and would catch early episodes.

The daily search only runs / collects results if there are actually episodes that are wanted
...
There are really just 2 options here IMO, what @p0psicles suggested and what @duramato initially suggested.

What @duramato suggested does look nice on GUI, but implies inconveniently re-doing it for every season, plus, it also means searching for unneeded episodes all the time, since there is no delta-time, and only the next episode to air is relevant. Delta-time per-show (as @p0psicles and me suggested) seems more reasonable.

Thanks

If the users who can check out a branch other then develop or master. I'd appreciate if you could start testing this branch feature/add-daily-search-start-search-offset
The more users we have testing this, the faster we can get it into develop/master.
The provider setting, i'll do at a later stage.

@p0psicles
I'm trying your branch. It is not easy to test, since status is not change-able to "un-aired" (for testing... ).

I found one show I can test - Vikings, air date is in two days 13-Dec, and there is already an SD release available (I'll post the details below, so you can use it for your testing, maybe backup your DB, so you can revert back to re-test).

Show details:

Show: Vikings
Quality: SD
Originally Airs: Wednesday 9:00 PM on History

episodes list:
13 A New God 12/13/2018, 04:00 AM Unaired
...

Manual search files list (blue...):
Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] EXTREME Torrentz2 SDTV 648 78 372.00 MB Torrent 40 minutes ago 12/7/2018 04:43 PM 12/10/2018 06:33 PM

Test 1: setting to +48 hours (delayed, so forced search should do nothing )
Results: Search thread is Crashing -

Log:
2018-12-10 18:22:10 ERROR DAILYSEARCHER :: [54da0c7] Exception generated: bad operand type for abs(): 'NoneType'
Traceback (most recent call last):
File "D:\Program Files\Medusa\Medusa\medusa\scheduler.py", line 93, in run
self.action.run(self.force)
File "D:\Program Files\Medusa\Medusa\medusa\search\daily.py", line 72, in run
additional_search_offset = int(ceil(abs(min_offset_show[0]['min_offset']) / 24.0))
TypeError: bad operand type for abs(): 'NoneType'

Test 2: setting to -48 hours (this should download the episode)
Result: downloaded as designed
Second force check - resulted in nothing (no wanted episodes)
Side effects:
Episodes list still shows as "Un-aired" (not changing to snatched!), though, it seems like internally it is marked correctly since it is not being re-snatched...

After snatch:
13 A New God 12/13/2018, 04:00 AM Unaired

Log:
2018-12-10 19:15:20 INFO SHOWQUEUE-REFRESH :: [54da0c7] 260449: Performing refresh on Vikings
2018-12-10 19:12:40 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] No needed episodes found
2018-12-10 19:12:40 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Using daily search providers
2018-12-10 19:12:40 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 19:12:37 INFO DAILYSEARCHER :: [54da0c7] Updating network timezones failed, this can happen from time to time. URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt
2018-12-10 19:12:36 INFO Thread_0 :: [54da0c7] Daily search forced
2018-12-10 19:07:00 INFO SNATCHQUEUE-SNATCH-260449 :: [54da0c7] Downloading Vikings.S05E12.WEBRip.x264-ION10 with 398 seeders and 723 leechers and size 436.40 MB from Rarbg, through a SearchType.DAILY_SEARCH search
2018-12-10 19:07:00 INFO SNATCHQUEUE-SNATCH-260449 :: [54da0c7] Beginning to snatch release: Vikings.S05E12.WEBRip.x264-ION10
2018-12-10 19:06:57 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Downloading Vikings.S05E12.WEBRip.x264-ION10 with 398 seeders and 723 leechers and size 436.40 MB from Rarbg
2018-12-10 19:06:55 INFO SEARCHQUEUE-DAILY-SEARCH :: [Rarbg] :: [54da0c7] Picked Vikings.S05E12.WEBRip.x264-ION10 as the best result.
2018-12-10 19:06:55 INFO SEARCHQUEUE-DAILY-SEARCH :: [Rarbg] :: [54da0c7] Quality of Vikings.S05E12.WEBRip.x264-ION10 is SDTV
2018-12-10 19:06:55 INFO SEARCHQUEUE-DAILY-SEARCH :: [Rarbg] :: [54da0c7] Quality of Vikings.S05E12.WEB.h264-TBS[rartv] is SDTV
2018-12-10 19:05:26 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Using daily search providers
2018-12-10 19:05:26 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 19:05:23 INFO Thread_4 :: [54da0c7] Daily search forced

General comments:

  1. We need minimal indication of the settings, so to be aware -I suggest both in the shows' page near maybe near air-date, like air-date - offset: -48h; and maybe also also in the air-date column below (or add a new offset column?)
  2. Maybe improve the label text in the settings - instead of (1) (-1) something like X / -X hours ...
    FYI

Rafi

tnx. You added the show I guess. Think I'm not setting the default value of 0.

No, I have just used my data directory with all DBs in your branch. This was an existing show, and I was lucky to see that it has a future episode available...

Did you see something like this while starting up for the first time after the update?
Adding new airdate_offset field in the tv_shows table

Is it possible you check you main.db with an sqlite editor? And check if the airdate_offset field as any empty values?

Yes. Log:

2018-12-10 18:03:09 INFO CHECKVERSION :: [54da0c7] Checking for updates using SOURCE
2018-12-10 18:03:07 INFO MAIN :: [54da0c7] Building internal name cache for all shows
2018-12-10 18:03:07 INFO MAIN :: [54da0c7] Finished processing 2977 scene exceptions.
2018-12-10 18:03:07 INFO MAIN :: [54da0c7] Updating exception_cache and exception_season_cache
2018-12-10 18:03:07 INFO TORNADO :: [54da0c7] Starting Medusa on http://0.0.0.0:8081/
2018-12-10 18:03:07 INFO MAIN :: [54da0c7] Forcing web server to port 8081
2018-12-10 18:03:07 INFO MAIN :: [54da0c7] Starting Medusa [master] using u'D:\Program Files\Medusa\Data\config.ini'
2018-12-10 18:03:01 INFO MAIN :: [54da0c7] [MAIN-DB] Updated minor version to: 44.13
2018-12-10 18:03:01 INFO MAIN :: [54da0c7] Adding new airdate_offset field in the tv_shows table
2018-12-10 18:03:01 INFO MAIN :: [54da0c7] Proceeding with upgrade
2018-12-10 18:03:01 INFO MAIN :: [54da0c7] Backing up database before upgrade
2018-12-10 18:02:59 INFO MAIN :: [54da0c7] Broken providers found: [u'torrent9', u'newpct']
2018-12-10 17:59:14 INFO EVENT-QUEUE :: [54da0c7] Shutting down Tornado
2018-12-10 17:59:14 INFO EVENT-QUEUE :: [54da0c7] Saving config file to disk

I added some logging now. Still dont know why you got the exception.

Moved the log to before the crashed-line, instead of after (offsets are all re-set to 0):

2018-12-10 22:40:28 ERROR DAILYSEARCHER :: [54da0c7] Exception generated: bad operand type for abs(): 'NoneType'
Traceback (most recent call last):
File "D:\Program Files\Medusa\Medusa\medusa\scheduler.py", line 93, in run
self.action.run(self.force)
File "D:\Program Files\Medusa\Medusa\medusa\search\daily.py", line 74, in run
additional_search_offset = int(ceil(abs(min_offset_show[0]['min_offset']) / 24.0))
TypeError: bad operand type for abs(): 'NoneType'
2018-12-10 22:40:28 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': None}] as we found show(s) with an airdate offset configured.
2018-12-10 22:40:28 DEBUG DAILYSEARCHER :: [54da0c7] Finished updating network timezones
2018-12-10 22:40:28 DEBUG DAILYSEARCHER :: [54da0c7] User-Agent: Medusa/0.2.13 (Windows; 10; bbf50100-fcbb-11e8-9498-001b213c7449)
2018-12-10 22:40:28 DEBUG DAILYSEARCHER :: [54da0c7] GET URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt [Status: 200]

One offset is -24:

18-12-10 23:00:27 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from The Blacklist
2018-12-10 23:00:27 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from The Big Bang Theory
2018-12-10 23:00:27 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Suits
2018-12-10 23:00:27 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Homeland
2018-12-10 23:00:27 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] Vikings: Applying an airdate offset for the episode: Vikings - S05E13 - A New God of -24 hours
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': -24}] as we found show(s) with an airdate offset configured.
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] Finished updating network timezones
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] User-Agent: Medusa/0.2.13 (Windows; 10; 5785270f-fcbe-11e8-8c39-001b213c7449)
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] GET URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt [Status: 200]
2018-12-10 23:00:24 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-10 23:00:23 INFO Thread_7 :: [54da0c7] Daily search forced

Offset: +24

2018-12-10 23:05:36 ERROR DAILYSEARCHER :: [54da0c7] Exception generated: bad operand type for abs(): 'NoneType'
Traceback (most recent call last):
File "D:\Program Files\Medusa\Medusa\medusa\scheduler.py", line 93, in run
self.action.run(self.force)
File "D:\Program Files\Medusa\Medusa\medusa\search\daily.py", line 74, in run
additional_search_offset = int(ceil(abs(min_offset_show[0]['min_offset']) / 24.0))
TypeError: bad operand type for abs(): 'NoneType'
2018-12-10 23:05:36 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': None}] as we found show(s) with an airdate offset configured.
2018-12-10 23:05:36 INFO DAILYSEARCHER :: [54da0c7] Updating network timezones failed, this can happen from time to time. URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt
2018-12-10 23:05:36 DEBUG DAILYSEARCHER :: [54da0c7] Error requesting url https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt Error: ('Connection aborted.', error(10054, 'An existing connection was forcibly closed by the remote host'))
2018-12-10 23:05:36 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-10 23:05:35 INFO Thread_4 :: [54da0c7] Daily search forced

Aah i didnt check properly when there arent any offsets. Tnx for testing.
But back at it tomorrow.

Fixed the bug here for you (daily.py) - need to always check for minimum: 0, positive or negative... Maybe - you can review/attend to the other UI related comments?

    main_db_con = DBConnection()
    min_offset_show = main_db_con.select(
        'SELECT MIN(airdate_offset) AS min_offset '
        'FROM tv_shows '
    #    'WHERE paused = 0 AND airdate_offset < 0 '
        'WHERE paused = 0 '
    )
    additional_search_offset = 0
    if len(min_offset_show):
        log.debug('Using an airdate offset of {min_offset_show} as we found show(s) with an airdate offset configured.',
                  {'min_offset_show': min_offset_show})
        additional_search_offset = int(ceil(abs(min_offset_show[0]['min_offset']) / 24.0))
    #   log.debug('Using an airdate offset of {min_offset_show} as we found show(s) with an airdate offset configured.',
    #             {'min_offset_show': min_offset_show})

offset 24 of one show -> using 0 - the rest of the shows:

2018-12-10 23:18:52 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] Vikings: Applying an airdate offset for the episode: Vikings - S05E13 - A New God of 24 hours
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': 0}] as we found show(s) with an airdate offset configured.
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] Finished updating network timezones
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] User-Agent: Medusa/0.2.13 (Windows; 10; 12d02a40-fcc1-11e8-bb6f-001b213c7449)
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] GET URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt [Status: 200]
2018-12-10 23:18:51 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-10 23:18:50 INFO Thread_1 :: [54da0c7] Daily search forced

Offset 0 offset for all shows :

2018-12-10 23:23:30 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Suits
2018-12-10 23:23:30 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Homeland
2018-12-10 23:23:30 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 23:23:27 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': 0}] as we found show(s) with an airdate offset configured.
2018-12-10 23:23:27 INFO DAILYSEARCHER :: [54da0c7] Updating network timezones failed, this can happen from time to time. URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt
2018-12-10 23:23:27 DEBUG DAILYSEARCHER :: [54da0c7] Error requesting url https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt Error: ('Connection aborted.', error(10054, 'An existing connection was forcibly closed by the remote host'))
2018-12-10 23:23:27 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-10 23:23:26 INFO Thread_4 :: [54da0c7] Daily search forced

oneshow -24, rest 0:

2018-12-10 23:25:35 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from The Big Bang Theory
2018-12-10 23:25:35 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Suits
2018-12-10 23:25:35 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Homeland
2018-12-10 23:25:35 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] Vikings: Applying an airdate offset for the episode: Vikings - S05E13 - A New God of -24 hours
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of [{'min_offset': -24}] as we found show(s) with an airdate offset configured.
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] Finished updating network timezones
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] User-Agent: Medusa/0.2.13 (Windows; 10; 12d02a40-fcc1-11e8-bb6f-001b213c7449)
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] GET URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt [Status: 200]
2018-12-10 23:25:34 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-10 23:25:33 INFO Thread_2 :: [54da0c7] Daily search forced

@rafi-d i pushed a fix. Can you try again?

I was just wondering (looking at your implementation/adjustment) -
Is the "cur_date" filter you use to get the relevant shows has only days resolution of includes hour (to compare to the exact published date+hour)? I see that your math here rounds to -days, is that your intention, and will it not round to 0 days if the user enters less then 12 hours? If so, it might be more reasonable to enter the shift in days, and not in hours in the first place....

Another thing - since we've allowed delayed (positive) offset too, maybe there is a way to also avoid searching for shows that were defined so ? This is relevant if a user wants to wait intentionally with searching-downloading a show (and safe resources), like when you want a specific release (like AMZN) that you know is usually being published 1-2 days later. Or. if this is not handle anyway, maybe we should not allow positive numbers at all?

Yes, the airdate is in whole days. Thats why i need to translate that. But it wil always round up to a whole day. So -24 translates to a one day offset. Where -25 translated to 2 days.

I think it will currently already skip shows with a positive offset. But thats honestly i still need to test myself.

Btw the round up to whole days is just for the db query to get the episodes. The check after is done in hours.

Seems to be OK now, no crashes on +-48 ... Couldn't check if it auto-skips searches on "+offset" of available releases, tho .

Status/GUI still needs enhancing fixing IMHO.

Thanks!

----------------- log ----

+48 nothing needed

2018-12-11 16:22:06 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from The Big Bang Theory
2018-12-11 16:22:05 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Suits
2018-12-11 16:22:05 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Homeland
2018-12-11 16:22:05 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-11 16:22:05 DEBUG DAILYSEARCHER :: [54da0c7] Vikings: Applying an airdate offset for the episode: Vikings - S05E13 - A New God of 48 hours
2018-12-11 16:22:04 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-11 16:22:03 INFO DAILYSEARCHER :: [54da0c7] Updating network timezones failed, this can happen from time to time. URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt
2018-12-11 16:22:03 DEBUG DAILYSEARCHER :: [54da0c7] Error requesting url https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt Error: ('Connection aborted.', error(10054, 'An existing connection was forcibly closed by the remote host'))
2018-12-11 16:22:03 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-11 16:22:03 INFO Thread_0 :: [54da0c7] Daily search forced

-48 - snatch

2018-12-11 19:10:10 DEBUG SNATCHQUEUE-SNATCH-260449 :: [54da0c7] Calling uTorrent Client
2018-12-11 19:10:10 INFO SNATCHQUEUE-SNATCH-260449 :: [54da0c7] Downloading Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] with 648 seeders and 78 leechers and size 372.00 MB from Torrentz2, through a SearchType.DAILY_SEARCH search
2018-12-11 19:10:10 INFO SNATCHQUEUE-SNATCH-260449 :: [54da0c7] Beginning to snatch release: Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.]
2018-12-11 19:10:10 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Downloading Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] with 648 seeders and 78 leechers and size 372.00 MB from Torrentz2
2018-12-11 19:10:10 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] No results to sort.
2018-12-11 19:10:10 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Combining single and multi-episode results
2018-12-11 19:10:10 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Zooqle] :: [54da0c7] Transaction with 11 queries executed
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [LimeTorrents] :: [54da0c7] Transaction with 11 queries executed
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [ThePirateBay] :: [54da0c7] Transaction with 11 queries executed
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Rarbg] :: [54da0c7] Transaction with 11 queries executed
2018-12-11 19:10:09 INFO SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Picked Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] as the best result.
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Computed result scores:
Score Release
100.00 Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.]
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Sorting the following results: [u'Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.]']
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Found wanted results.
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] 260449: 'Vikings' S05E13 status is: 'Wanted'. Accepting result with quality 'SDTV'. Reason: Current status is 'WANTED'. Accepting result with quality 'SDTV'
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] 260449: Allowed, Preferred = [ SDTV, SD DVD ] [ None ] Found = [ SDTV ]
2018-12-11 19:10:09 INFO SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Quality of Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] is SDTV
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] 260449: Using cached results from Torrentz2 for series u'Vikings' episode S05E13
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] 260449: 'Vikings' S05E13 status is: 'Wanted'. Accepting result with quality 'SDTV'. Reason: Current status is 'WANTED'. Accepting result with quality 'SDTV'
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] 260449: Allowed, Preferred = [ SDTV, SD DVD ] [ None ] Found = [ SDTV ]
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Parsed Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] into title: Vikings, season: 5, episode: [13], language: fr, source: HDTV, video_codec: Xvid, release_group: EXTREME, type: episode, parsing_time: 0.115999937057, total_time: 0.115999937057, absolute_episode: [], quality: SDTV
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [Torrentz2] :: [54da0c7] Matched release Vikings.S05E13.FRENCH.HDTV.XviD-EXTREME.[.www.T9.pe.] to a series in your database: Vikings
2018-12-11 19:10:09 DEBUG FINDPROPERS :: [ThePirateBay] :: [54da0c7] Searching only confirmed torrents
2018-12-11 19:10:09 DEBUG FINDPROPERS :: [ThePirateBay] :: [54da0c7] Search string: Escape at Dannemora S01E04 PROPER|REPACK|REAL|RERIP
2018-12-11 19:10:09 DEBUG FINDPROPERS :: [ThePirateBay] :: [54da0c7] Search mode: Episode
2018-12-11 19:10:09 INFO FINDPROPERS :: [ThePirateBay] :: [54da0c7] Searching for any new PROPER releases from ThePirateBay
2018-12-11 19:10:09 DEBUG FINDPROPERS :: [Rarbg] :: [54da0c7] No results found Code: 20

2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Searching for Vikings S05E13. Reason: Status is WANTED. Searching episode
2018-12-11 19:10:09 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Vikings

2018-12-11 19:10:08 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Suits
2018-12-11 19:10:08 DEBUG SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Seeing if we need anything from Homeland
2018-12-11 19:10:08 INFO SEARCHQUEUE-DAILY-SEARCH :: [54da0c7] Beginning daily search for new episodes
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] Transaction with 1 queries executed
2018-12-11 19:10:07 INFO DAILYSEARCHER :: [54da0c7] Setting status (Wanted) for show airing today: Vikings - S05E13 - A New God
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] Vikings: Applying an airdate offset for the episode: Vikings - S05E13 - A New God of -48 hours
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] 260449: Formatting pattern: %SN - S%0SE13 - %EN -> Vikings - S05E13 - A New God
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] Using an airdate offset of -48 as we found show(s) with an airdate offset configured.
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] Finished updating network timezones
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] User-Agent: Medusa/0.2.13 (Windows; 10; 6d0c1e5e-fd4d-11e8-a809-001b213c7449)
2018-12-11 19:10:07 DEBUG DAILYSEARCHER :: [54da0c7] GET URL: https://cdn.pymedusa.com/sb_network_timezones/network_timezones.txt [Status: 200]
2018-12-11 19:10:06 DEBUG DAILYSEARCHER :: [54da0c7] Started updating network timezones
2018-12-11 19:10:06 INFO Thread_3 :: [54da0c7] Daily search forced

In develop

In develop

Thanks.
Any ETA for 0.2.15?

Happy new year!

It's tied to python 3 support. That has also been merged. So if you want to help speedup release, you can help testing develop with python 3.
Eta somewhere in January

I'll see what I can do. Sounds like bad news (for this feature).... ;) It'll probably take time to stabilize after this upgrade/migration.

Well it's good news that we soon run on py3. We're the first fork with py3 support. But we already have tested py3 allot already. Just need to cover all different configurations.

Docker users can pull the develop tag and test in container too if you keep the develop Dockerfile separate and change the python version in it

Was this page helpful?
0 / 5 - 0 ratings

Related issues

elpedriyo picture elpedriyo  Â·  4Comments

LoRNiKoN picture LoRNiKoN  Â·  4Comments

Rouzax picture Rouzax  Â·  3Comments

wimpyrbx picture wimpyrbx  Â·  5Comments

skarekrow picture skarekrow  Â·  4Comments