Fix for inetref check on TTVDB and no longer bail if some art is not available

[TravellingGuy]

Now it properly finds tv shows based on the inetref. Using "not in" is tricky with "and" and "or", plus the typo, it never worked properly. :-)

[joncl]

Nice catch! Yes, on line 933 'or' should definitely be 'and' because 'or' would make it generic even though one was actually not! Although luckily I still got images because I went on to test each separately (without the typo). Probably need some further logic cleanup there.

Regarding lines 409-429, it seems it still bails when an image couldn't be found?

Also, you see my long elif line at 1085. I was thinking I need maybe a state pattern to make things more elegant with the various argument switches? This is my first swing with Python as you can probably tell ;) Anyway, thanks for taking a look!

[TravellingGuy]

I was having problems with two shows, Boundless (http://thetvdb.com/?tab=series&id=273427&lid=7) and Dr. Oakley: Yukon Vet (http://thetvdb.com/?tab=series&id=289688&lid=7). Boundless is missing posters, Dr. Oakley is missing fanart.

Before my change, all of the artwork had to exist or it would fail to download any of it, and the script would fail (can't remember the error now). With my change, it now successfully downloads the available art and logs a message if it's not available. The script successfully runs without errors for me now, but I'm just starting out with it, playing around. :-) It could be that lines 431-432 are not needed anymore either, I think.

There's very likely bugs too (it works for my two tests, though), so feel free to test and adjust as well. I'm not a developer, just hacking around.

P.S. What got me on the error on line 933 was I was originally getting incorrect art for Boundless and Dr. Oakley, completely random art (like anime art!) It was weird. Haha.

[TravellingGuy]

Here's a patch to allow the use of a hardlink or a symlink to the destination_dir. I'll never watch recorded shows in MythTV (only in Kodi), so for me, once I get the recorded shows into Kodi, they can be deleted from MythTV. A hardlink will allow the video to stay around even after it's deleted from MythTV without using any extra disk space. (I changed symlinks_dir to destination_dir as I can imagine a scenario where "move" and "copy" could be options as well, for example SMB network shares where links don't work.)

[TravellingGuy]

Oh, I should point out I have not tested (or even looked at) the --clean functionality, so no idea if anything could break when using --clean with hardlinks. :-)

[joncl]

Hey TG, sorry for the delayed reply, and thanks for your pull request! I
think this is for the scenario where you want to use MythTV only as a
backend PVR, and not the frontend, correct? I've not done this before, but
I think I've seen a MythTV option that only writes the video file, and
disables storing video metadata to the database. Although I can't seem to
find that option now. Anyway, I'm a little confused because if you delete a
recording in MythTV, doesn't it also delete the video file? So the hardlink
(or symlink) would be disabled anyway? Or I guess the hardlink get deleted
as well?

I'm leaning toward sticking with just symlinks for now because I plan to
build a feature where you could delete a recording in Kodi, and have it
also delete the associated symlink. If it was a hardlink, then the original
MythTV video file would also get deleted, but I think you'd want to delete
it out of MythTV first using maybe an API call. I haven't looked into this
yet, but I'm thinking it might be best to hold on giving the option for
hardlinks because of that.

Also, I see now that the previous edit you did on downloading posters,
banners, and fanarts was the way to go.

On Sat, Jan 24, 2015 at 4:41 PM, TravellingGuy [email protected]
wrote:

Oh, I should point out I have not tested (or even looked at) the --clean
functionality, so no idea if anything could break when using --clean with
hardlinks. :-)

—
Reply to this email directly or view it on GitHub
#2 (comment).

[TravellingGuy]

Hey joncl.

A file is essentially a pointer to the data contained in the file. A hard link is essentially another file that points to the same data. So when you make a hard link, you essentially create a second pointer to the same data. You can then delete the first "file", but the data (and the second pointer to it...i.e. the hard link) is still there so you can continue to access the file.

Anyway, I'm fine with keeping symlink the default (I actually meant to commit that as the default, but forgot), as most people do use symlinks. However, hard links do have advantages and can be useful for some.