Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unescaped quotation marks when stream title/description passed to player #256

Closed
Poorchop opened this issue Jun 2, 2016 · 8 comments
Closed

Comments

@Poorchop
Copy link

Poorchop commented Jun 2, 2016

Description

A stream with quotation marks in the title won't launch so long as the stream title is passed to Livestreamer to then be passed to the video player.

Expected / Actual behavior

Stream title gets passed to player (mpv) without issues.

Reproduction steps

  1. Add the {status} parameter in your video player settings.
  2. Find a stream with quotes in the title/description.
  3. Try launching the stream.

Environment details (operating system, etc.)

Windows 8.1 x64
mpv

Comments, logs, screenshots, etc.

Traceback (most recent call last):
  File "<string>", line 6, in <module>
  File "__main__.py", line 128, in <module>
  File "__main__livestreamer__.py", line 9, in <module>
  File "livestreamer_cli\main.py", line 886, in main
  File "livestreamer_cli\main.py", line 491, in handle_url
  File "livestreamer_cli\main.py", line 369, in handle_stream
  File "livestreamer_cli\main.py", line 203, in output_stream_passthrough
  File "livestreamer_cli\output.py", line 21, in open
  File "livestreamer_cli\output.py", line 121, in _open
  File "livestreamer_cli\output.py", line 131, in _open_call
  File "livestreamer_cli\output.py", line 116, in _create_arguments
  File "shlex.py", line 279, in split
  File "shlex.py", line 269, in next
  File "shlex.py", line 96, in get_token
  File "shlex.py", line 172, in read_token
ValueError: No closing quotation

Offending part of title:

["Blah blah blah" - Somebody]

I'm not sure if the brackets have anything to do with it but I didn't test a stream without brackets and quotes only.

@bastimeyer
Copy link
Member

Are you running the application from the master branch? The variables-substitution has been reworked (9eac3b4) and all characters should be escaped correctly (it escaped too many chars before and didn't care about variables outside of parameter strings).

When using variables inside parameter strings, only the wrapping quotation marks are now being escaped.
If you're using variables outside of parameter strings, every character will now be escaped (not only spaces). Escaping every character may not work on Windows in certain situations, but it's better to let Livestreamer throw an error than having messed up player parameters or potentially executing stuff.

The tests [1, 2] are working correctly (could be expanded/improved a bit, though).

You could also run this from the dev-tools console and test it for yourself:

var container = Ember.Application.NAMESPACES_BY_ID.App.__container__;
var stream = container.lookup( "service:store" ).peekAll( "twitchStream" ).get( "firstObject" );
stream.set( "channel.status", "\"foo\"" );
container.lookup( "service:livestreamer" ).startStream( stream );

This should work when using mpv as the player and --title "{status}" or --title {status} as player arguments.

@Poorchop
Copy link
Author

Poorchop commented Jun 2, 2016

I was using the stable release but I just tried the latest git from master and everything works fine. I even used brackets like "[\"foo\"]" and there weren't any issues. Your unit tests pass and you were already escaping quotation marks before you rewrote the regex so I don't understand why I was having issues. I forgot that I already had a recent build that I should've used to test the stream last night when I was having the issue. I'll remember to do that next time.

@Poorchop Poorchop closed this as completed Jun 2, 2016
@Poorchop
Copy link
Author

Poorchop commented Jun 2, 2016

I found out that VODs show the original title so I decided to try it out and I figured out the issue: one single quote within a pair of double quotes.

E.g. "It \"doesn\'t\" work."

According to the traceback, there's no closing quotation, so adding another single quote actually works: "It \"didn\'t\'\" work before, but it works now."

I'm not quite following how the quote substitution works or if I'm even looking at the right thing but I hope that this is enough info.

@Poorchop Poorchop reopened this Jun 2, 2016
@bastimeyer
Copy link
Member

bastimeyer commented Jun 2, 2016

Thanks! 👍
You are right, it is failing, but only on Windows, which comes a bit unexpected 😡...

This seems to be related to a python dependency of Livestreamer on Windows. Clearly a bug in the parameter parser there.
I've just tested escaping both quotation marks, but this surprisingly didn't fix the issue. Let me see...

You can try this from the CLI: (don't be confused about the extra layer of \-chars)
livestreamer -a "--title \"abc \\\"foo\\\'s bar\\\" xyz\" {filename}" twitch.tv/CHANNEL best

I will see how I can fix this tomorrow.

@Poorchop
Copy link
Author

Poorchop commented Jun 2, 2016

Don't the stream URL and quality have to be passed as the first two args? It doesn't work for me otherwise, but when I try livestreamer twitch.tv/example best -a "--title \"abc \\\"foo\\\'s bar\\\" xyz\" {filename}" --player=mpv I get livestreamer.exe: error: unrecognized arguments: bar\" xyz\ {filename}.

@bastimeyer
Copy link
Member

bastimeyer commented Jun 2, 2016

Don't the stream URL and quality have to be passed as the first two args

Doesn't matter. But usually parameters come first.
$ livestreamer [OPTIONS] [URL] [STREAM]

In addition to my post above:
In node the parameter list needs to be an array, which makes it a bit clearer (omitting the string quotes):

-p
/path/to/mpv
-a
--title "abc \"foo's bar\" xyz" {filename}
twitch.tv/CHANNEL
best
-p
/path/to/mpv
-a
--title "abc \"foo\'s bar\" xyz" {filename}
twitch.tv/CHANNEL
best

If I can't find a working solution for this tomorrow, I will open a bug report at the livestreamer repo...
And as I said, this only fails on Windows...

@Poorchop
Copy link
Author

Poorchop commented Jun 2, 2016

Strange bug but I guess this really is an upstream issue. In that case, I'm not sure if there's anything you could really do other than eating the offending character(s) altogether when the platform is Windows.

@bastimeyer
Copy link
Member

This seems to be fixed by Streamlink...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants