Fix for title encoding & URLs

[Delver26]

Hi, I was able to fix my issues with utf8 encoded characters in the titles of videos, by basically performing a crude replace of the characters with an ascii version. I don't know python at all, so it's a very hacky way to get around it, there's probably a much better way to handle encoding, but it works so far for me.

I've also fixed the issue where the API would sometimes return an empty URL or something like that. This is checked for in parts of the code, but isn't when constructing the filename, and, filename += "." + url.split(".")[-1] causes an error. Again, I've put in a very hacky solution to just bypass that line if the URL is empty.

These changes should solve (poorly!) both of the issues currently open.

[simonk83]

Just a heads up, using dump_video_shows still gives:

Traceback (most recent call last):
  File "giant_bomb_cli.py", line 353, in <module>
    main()
  File "giant_bomb_cli.py", line 322, in main
    dump_video_shows(api_key)
  File "giant_bomb_cli.py", line 136, in dump_video_shows
    video_show["title"], video_show["deck"]))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 3: ordinal not in range(128)

[Delver26]

Thanks, it looks like the encoding needs to be fixed on dump_video_shows too. I've never used that function, so never thought to fix the output on it! Added new commit there now that seems to fix it

[simonk83]

Nailed it, thanks :)

[simonk83]

One other slight issue that I also came across when I was messing with this, if a file fails to download (like the latest This is the Run (Episode 14) has a blank video file at the moment), it still adds the ID to the download archive json file, so it won't download it again later when the file is fixed.

I've fixed this by changing the following (but again, I'm winging this so there WILL be a better way):

if args.downloadArchive: download_archive["Downloaded"].append(video_id)

to

if args.downloadArchive and url is not None: download_archive["Downloaded"].append(video_id)

[Delver26]

Ah cool, thanks. It looks like they changed how they process videos now, so streams show up on the site instantly after the stream ends, but the downloadable version isn't ready for a while, even though the API has the video details. I'll add your change into the pull request, it seems to fix the issue!