Encoding issues with european letters and empty track dict returns from api

[orilg]

hello,

I've encountered few issues and those changed fixed them for me.

1. Fixing encoding issues with European letters I had (example 'search french', 'play 2')
2. Dealing with tracks that had no 'url' which meant the mix is not that good, so went to next mix (example 'search welcome' 'play 5')

I had the LC_* locales you wrote in one of the encoding issues so I assume it's not only my raspberrypi that gives me issues with it. try it yourself and if you have a better solution let me know. Thanks, great job!

[dbrgn]

Hi

Thanks for the contribution!

1. Fixing encoding issues with European letters I had (example 'search french', 'play 2')

What problem did you observe? Did Orochi crash? I couldn't really reproduce the issue.

Orochi should work in an UTF8 terminal. On the other hand it's not nice that it crashes if the terminal uses a different encoding. Simply encoding a subset of the print statements isn't a long-term solution though, there might be more places where we're missing the encoding.

A better solution would be to define our own wrapper function for print() (untested):

def uprint(text, *args, **kwargs):
    """
    A wrapper around print() that accepts unicode objects
    and prints utf8 encoded bytes.
    """
    print(text.encode('utf8'), *args, **kwargs)

(We could think about naming it "put" or "out" instead of "uprint" to save characters, but on the other hand "uprint" will be more clear/explicit to python devs.)

The function could live in orochi/utils.py. Then replace all print statements in the codebase with uprint, while at the same time making sure that they all receive unicode objects as input, not encoded byte strings.

@orilg would you like to implement something like that in a separate PR?

1. Dealing with tracks that had no 'url' which meant the mix is not that good, so went to next mix (example 'search welcome' 'play 5')

Looks like the track response from the API is simply an empty dict ({}). Do you know what that means? In which case does the API return such a result? And if that happens, shouldn't we simply skip the track instead of skipping the entire mix?

[orilg]

Hi, Thanks for the quick attention.

1. I'll be happy to add that all uprint in a different PR. you weren't able to reproduce? maybe it's a raspberrypi with Debian issue? also ran it in tmux. so you can see french letters just fine? for me it just errors and quits.
2. I tried skipping a track but usually it meant the mix itself is weird and the next song caused self.status['at_end'] to be True. and again the effect is error and quit. I just checked on their web interface and they have the same problem. this mix http://8tracks.com/keldibekova-a/and-welcome-to-my-life has 11 tracks and when you get to the 4th track is ends. I can make a separate pull request just with that change if you want.

[dbrgn]

I'll be happy to add that all uprint in a different PR.

Yes, that would be very much appreciated :)

you weren't able to reproduce? maybe it's a raspberrypi with Debian issue? also ran it in tmux. so you can see french letters just fine? for me it just errors and quits.

On my system everything just works fine. Probably a problem with encoding detection. That should be solved by the uprint fix.

I tried skipping a track but usually it meant the mix itself is weird and the next song caused self.status['at_end'] to be True. and again the effect is error and quit. I just checked on their web interface and they have the same problem. this mix http://8tracks.com/keldibekova-a/and-welcome-to-my-life has 11 tracks and when you get to the 4th track is ends. I can make a separate pull request just with that change if you want.

Ah, I see. Yes, a separate pull request would be great.