Check available episode #1510
Check available episode #1510
Conversation
|
@gborri can you explain this please? Didn't get it. Why do we want an available status? when it's available SR will snatch it and set as SNATCHED |
|
@fernandog for me it's useful and i think for other. The point is that when you add a show know how many episode is available on provider is an information, at least for me, in order to choose which show to start watching. I'm used to start watching a season when all the episode of the season is available. with this function you don't need to look for it on provider and is available on sickrage. |
|
@fernandog i forgot to make it configurable, i will try. |
|
@fernandog done. Make available check as an option |
|
@gborri is there any DB change? |
|
@fernandog only for my db version. SickRage native db will not be touched |
|
Looking at the code. I think we should change AVAILABLE_CHECK to ep_availability_check, as the other term is to generic and isn't self explanatory. |
|
We are migrating TPB? class MigrateSickBeardDB(AlterTVShowsFieldTypes) |
|
@fernandog it's not a matter or automation. the point is to know what have been available on torrent provider. For italian language the show has been released lot time after the original release. So there no reason to login on torrent provider to know if it's available or not and doing this everyday/everyweek etc. The point is to let sickrage discover the available torrent file on provider. I have on sickrage 50 Show and looking on provider if episode exit is a waste of time. The FR is enabled only if someone want it, otherwise nothing has been changed. I don't understand why you don't want it to be merged. I think that could be useful for lot of people. |
|
@abeloin the code is correct, available status is subjected to quality as snatch and downloaded. |
|
@abeloin the migration is need to change my db to be equal to the one of sickrage. Is needed to me and to the few people that have downloaded my repo. |
|
@abeloin for the change of name is fine, i will do it. |
|
@abeloin @fernandog do you think this PR could be merged? |
|
not now. Too mamy issues. We need to make master stable again |
|
@gborri I also wanted to talk with you about the implementation. Looking at this, I was thinking that maybe we could push it a little bit further and offer the choice of the release to download(in case of multiple one). This would require a db for it and a reworking of the statuses and maybe use notification icon when episode are available. Also a management page would be nice. I'm a little bit busy until the 30th, but after that I think we should talk about it as it could be a good idea |
…ilable_episode Conflicts: sickbeard/__init__.py sickbeard/webserve.py
|
This effectively starts bothering providers and indexers with API calls for all eps of a series which are set to WANTED or SKIPPED. Now WANTED I see no problem in: Since we want them, we should do our best to find the eps. SKIPPED essentially means to me "Weeeel, I might be interested in them somewhere in the future. Or not. Don't know". Should we bother providers with querying them for that kind of stuff? SR must start running into API limits for users with huge DB's then. |
|
@WebSpider i think that if you are worried about bothering indexer probably we need to not let show update happens daily. The check four availability is made with same frequency of backloggin (less frequent). I think is a useful feature in order to know which show (episode actually) is available. SR start to check for availability on the day of air and stops when found(every 30 days at most) accordingly to backlogging frequency. |
|
@gborri we are overhauling the way the indexer-updates work in the show-updater-changes branch, to lower the load on indexers. Once this work is done, I will look at this PR again. |
|
@miigotu is there any reason why have you closed this PR? |
|
|
@miigotu i can rebase with the development branch (i need some help with the new mako template). |
|
@gborri we simply do not want this feature because it makes no sense to us. It's ok for us to say no sometimes. |
|
@miigotu the real point is that if i need to continuosly merge my repo with sickrage one i will have less time to contribute to the project. Then i have started to port my feature to SickRage because someone said to me that all the feature present on my repo would be ported on sickrage (someone said echelon was interested on it). This function is optional and can activated only if someone is interested otherwise the behaviour is the same as today. Now i'm facing the situation in which the admin (i don't know the reason) don't want to merge this one but all of you has accepted all other feature and i'm in the situation to continuosly need to merge my repo with the sickrage wasting time. Please take in consideration that also the little time the people is investing in this project is precious. Let me know. |
|
@gborri thank you for putting your time in SR, it is much appreciated. For this reason exactly, it is best practice to have feature-branches. Put one feature on a branch, so it can be merged into other repositories as needed. I'd suggest you put this feature in a separate branch, and merge this in your branch, while we may merge this later, if at all. That way, there's maximum flexibility, with minimum overhead. |
|
It takes literally seconds to merge changes from one repo to another, without PR. |
|
@miigotu it's not true.you need to manage conflict. in the last case you have changed the template definition and before merging the change i have to understand the new way...... i't simple only if there is no conflict. |
|
Either way you slice it, this PR is not getting added here. When your code is buggy you don't fix it, and most of it has very limited use cases. Believe me I have spent more time trying to fix one bug your code introduced than it took you to merge back to your branch a hundred times. |
|
@miigotu which is the bug you have spent time on? is not true that i don't manage bug i have introduced. |
|
@WebSpider i have some doubt that the work that i have done on this project "is much appreciated": has been taken the code i have done that like to admin group and discarded the one that the admin group don't like. Has been said that the feature of my repo were interested and i have merged it into sickrage (with not so easy effort) and now the admin group said that are not interested anymore on it (some of them were also removed). if this was the scenario when i started i would never started. I think that a comunity project will success if the priority and the feature needed are defined by the comunity itself otherwise if are only the admins that can decide which is the evolution of the project i think it will fail as soon as arise an alternative. When i started i though that was a comunity on which contribute to, but from what I have seen today it think that it's a closed group that grab idea from the comunity defining priority on their interest. |
|
@gborri looking at your contributions that made it to the project, I would disagree when you say it is not appreciated. It is true that not all code will be merged into mainline, for various reasons, few of them mentioned above. This is a community project, and will continue to be. Not only do we have over 150 suggestions from users that would like to see features added (and unfortunately insufficient resources to make them all true), we also have various pieces of code that have been submitted without request that have been merged, and several pieces of code that have been rejected, including pieces of code of myself, and other regular committers. There are reasons not to except code, since all code also has to be maintained. If we see there would be future issues with maintaining code, or if estimations are that this code would introduce a feature for an estimated small amount of users, it may be rejected. In such cases, it is more productive to make sure people you know who would like this feature 👍 it, instead of having big discussions about it, or code around the objections that were raised by other committers. |
If my management style does not suit you then it is ok if you don't contribute, but it is obvious that my approach works or we would not have doubled our user base since I started nor would SR be even remotely as stable as it now is becoming. In programming it is not about what you can do, it is about what you SHOULD do. We all can code 1000 features based on fleeting ideas that no one will use and add it to the code, but should we? Absolutely not. We add things that are highly requested and will be used by the majority of users. And if we add something that turns out is rarely used or doesn't work as well as we hoped, we remove it. Programming is a practice of catering to the majority of your user base and potential users, not the 1%. |
|
@miigotu @WebSpider if you really want to follow your style of management why not using a feature for voting feature and issue? like this one http://feathub.com/? |
|
@gborri If it was a much wanted feature, there would be an assload of users on this thread screaming in outrage begging for it. There are not. |
|
Also, with some 200 fr's out there, feathub may not be a bad idea. |
This function check for episode on torrent/nzb and set status on available if found.
Tested only with torrent.
For color code of new episode no preference, if you want to change it its ok.