refactor the code about nzbtomedia HOT 16 CLOSED

You should look into the driver pattern. Either that or strategy. Both patterns are focused on exposing a unified interface for an operation that requires different internal logic.

I love class-based design. So I'd be happy to help.

from nzbtomedia.

I like driver pattern, sounds good @clinton-hall ? I've been thinking abit how a proper (re)structure would look like, and my first thoughts is how we handle "incoming" variables, also if we should offload some codes into different lib/modules(?)

from nzbtomedia.

I've seen a few different approaches in python.

One approach I favor is to take config variables (i.e., file-based variables) and arguments (i.e., command line arguments) and combine them into a single data structure. This structure in python is generally either a dictionary or a class. I like using blank classes because it makes for clean and easy to read code.

Here's an example that converts a ConfigParser parsed file and converts it to a class:
https://github.com/berkona/qtimer/blob/master/qtimer/config.py

That example is somewhat more involved than you would need, because it must masquerade as an Alembic config object as well as the approach I described.

Another approach is to create an environment for something to run in. This approach is more seamless, but also more complicated. You can checkout the Alembic project for an actual example.

As a side note, I personally love the way alembic is organized as a program. It is written by the same person that writes the SQLAlchemy library for python, which is one the best examples of an enterprise-level python sql library. It uses the idea of 'commands' and 'scripts' run in 'environment' bubbles.

from nzbtomedia.

I made a wiki page for us to plan out the changes for this and make a roadmap. See https://github.com/clinton-hall/nzbToMedia/wiki/roadmap

from nzbtomedia.

well as I'm in not position to debate this (still in early python learning stage), I'll trust you to decide best implentation

But I agreed on the roadmap. nzbToMedia in my opinion will grow big as there is "no automation" for the torrent side of PTP file shareing (unlike usenet), and makeing it "idiot" proof from the start will help everyone in the long run

by "no automation" I mean, yeah there are scripts but they're mostly made to fit one persons need and not a community as a whole

from nzbtomedia.

I've been reviewing the category_search function in TorrentToMedia.py
So what does root = 1 and root = 2 actually mean? These seem to be magic numbers to some degree.

from nzbtomedia.

yeah... this was a weird section of code...

essentially, root = 1 means we are in a "common" directory and since we only want to copy/link the files that belong to this download we will try and match the files against torrent name.

root = 2 means we are in a common directory, and can't even determine a torrent name (unique name) so we have to try and determine which files to copy/link by date created/modified.... this really is a "Hail-Mary" attempt to process files... I don't know if that section of the code will really do much ;)

from nzbtomedia.

and please don't ask me to explain the logic behind this section of the code.... I was staring at it for hours trying to cover every possibility of directory structure...

not saying it is the best way... but essentially it steps up one directory at a time looking for a category.
when it finds a category it assigns the category (if category doesn't exist) and checks to see if this is the primary directory passed... if so it then looks for torrent name in daughter directory to see if there is a unique directory we can process. otherwise assigns root = 1 (if we have torrent name, or root 2 otherwise)
If the category was not the primary directory passed, it assumes the last (daughter directory) is the unique (torrent name) directory and assigns this torrent name if torrent name doesn't exist.

If no category is found in directory, but we do find torrent name, we again assume this to be a unique directory, so we can proceed only if the category is known.

I think that kind of makes some sense... there were probably 100 other ways of doing this section ;)

from nzbtomedia.

Might I suggest more cleaner/descriptive variable names? would help alot when trying to read the code ;)

from nzbtomedia.

by all means....

You have to remember, I am not a software engineer... I am a Physicist and I work with MatLab :)

I look at really scary code all day and am always satisfied with something that is "working" code.

As it is, I somehow seem to be able to interpret other people's code, but always struggle with "cleaning" it. If I could keep track of variables a...z I would... but usually I used contracted names that vaguely represent something.

the funny thing is... when I wrote it, I thought root was really obvious... but then the meaning of the variable has changed and we now have 2 root conditions ;)

from nzbtomedia.

Moving this to 7.0 since we want to get a working release out.

from nzbtomedia.

opinions? dev...refactor0.7

from nzbtomedia.

Looks logical.
Haven't had a chance to look at it too closely or test... But makes sense.

from nzbtomedia.

OK... despite the fact that I did a mv (not git mv) without realising it and as a result almost LOST a whole stack of files!... I have now moved several files (including the autoProcess*.py files into an autoProcess folder.
This means less files are "visible" when first coming to this site or downloading etc.

In order to allow us to call these files the same way, I have added the autoProcess folder into the sys path at the start of each script... seems to be an easy solution.

this cleans up the code a lot.

I have also made an nzbToMedia.py and changed nzbGet output allow this same file to be called for all categories and then call the appropriate autoProcess file. While I still intend (for now) to keep the individual scripts as well for those who preferre to trigger a different script for each category, I intend to ONLY compile the one nzbToMedia.exe as well as the TorrentToMedia.exe for windows.

anyway I believe this is getting a lot neater now. Let me know what you think.

from nzbtomedia.

ok... had to add the absolute path for autoProcess folder as this didn't work when called from another directory (as it would be called from the downloader)

All appears to be pretty solid now... tested linking and extracting... all good (and surprizingly fast for linking and extracting)... even transcoding is not too slow depending on what you are transcoding to.

all testing done in windows... havn't tested transcoding in linux yet.

from nzbtomedia.

Might look at adding all libs in /lib folder
like utorrent, linktastic and extractor

Might have to add a few more paths to sys path. And would need to remove and read linktastic via braid

from nzbtomedia.