VLC stopped working (with youtube-dl.py)

[joeschmoe40]

I have a script (running on Mac OSX) that uses youtube-dl with the "-j" option to generate the "real" URL for YouTube vids. It then passes that "real" URL on to VLC for viewing.

It has worked flawlessly for quite some time. However, as of a few days ago, it has stopped working for all YouTube vids. It works OK for other sites, but not for YouTube. No doubt, something has changed at YouTube (as they are always changing things) and youtube-dl hasn't kept up. I am running the latest version of youtube-dl (my script ensures this by frequently running it with the "-U" option). Currently, I am running:

$ youtube-dl.py -U
youtube-dl is up-to-date (2014.03.12)
$

Interestingly, I can "wget" the vid (which my script also [optionally] does), but VLC always complains that it can't open the URL. And also note that if I do "wget" it, then the resulting file plays fine in VLC. But I can't access it directly via VLC anymore. And again, this problem does not manifest with other sites videos - only on YouTube.

I have not updated or changed my VLC. But, I realize that this may be thought of as "not a youtube-dl problem" and be considered a "VLC problem". Still, since VLC has no technical support (trust me on this), and the support here is very good, I thought someone here might be able to help.

[jaimeMF]

Does the final video url start with https://?

[phihag]

Also, can you name an example URL and post how you run vlc?

[Crypto90]

I also have problems with https:// in the final url.
Is it possible to parse http:// again?

[joeschmoe40]

1. Yes, it begins with "https:".
2. I tried few things to "fix" the URL, but to no avail.  The first thing I tried was removing the "s" (changing it to just http:).  The second thing was changing every occurrence of %2C to ,  Neither helped.
3. One thing I forgot to mention in the original post was that in order to make it work with "wget", I had to add "--no-check-certificate" to the "wget" command line; else I get a bunch of certificate error garbage.  And, yes, I am 99% sure this all happened at the same time.  Prior to this problem arising, I did not have to have the option on the "wget" command line.
4. I'm pretty sure any YouTube URL will cause the problem; I've tried a lot of them since this problem arose.  Here's one to try:

CHICAGO - Colour My World (with lyrics)

CHICAGO - Colour My World (with lyrics)
View on www.youtube.com Preview by Yahoo
 
5) Here's the VLC command line:

    /Applications/VLC.app/Contents/MacOS/VLC --macosx-autoplay --quiet "$json_url"

On Monday, March 17, 2014 8:42 AM, Philipp Hagemeister notifications@github.com wrote:

Also, can you name an example URL and post how you run vlc?
—
Reply to this email directly or view it on GitHub.

[joeschmoe40]

Oops. I take that back about any YouTube causing it.

I just tried an old one and it worked. So, it may just be newer ones.
Everything by Chicago seems to cause it, as well as a few others I tried.

[phihag]

What exactly is "$json_url"? On Linux, this works fine for me:

vlc $(youtube-dl -g 'CHICAGO - Colour My World (with lyrics)')

[jaimeMF]

I think the https urls doesn't work with VLC on OSX, with our test video (http://www.youtube.com/watch?v=BaW_jenozKc) I see this errors on VLC:

main debug: net: connecting to r9---sn-h5q7enle.googlevideo.com port 443
main debug: connection succeeded (socket = 11)
main debug: looking for tls client module: 1 candidate
gnutls debug: GnuTLS v2.12.23 initialized
gnutls debug: browsing x509 credentials in /Users/{user}/Library/Application Support/org.videolan.vlc/ssl/certs...
gnutls warning: cannot access x509 in /Users/{user}/Library/Application Support/org.videolan.vlc/ssl/certs: No such file or directory
gnutls debug: browsing x509 credentials in /Users/{user}/Library/Application Support/org.videolan.vlc/ssl/private...
gnutls warning: cannot access x509 in /Users/{user}/Library/Application Support/org.videolan.vlc/ssl/private: No such file or directory
gnutls debug: loading x509 credentials from /Users/{user}/Library/Preferences/org.videolan.vlc/ssl/certs/ca-certificates.crt...
gnutls warning: cannot access x509 in /Users/{user}/Library/Preferences/org.videolan.vlc/ssl/certs/ca-certificates.crt: No such file or directory
main debug: using tls client module "gnutls"
main debug: TIMER module_need() : 240.279 ms - Total 240.279 ms / 1 intvls (Avg 240.279 ms)
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Success.
gnutls error: TLS session: access denied
gnutls error: Certificate could not be verified
gnutls error: Certificate's signer was not found
main error: TLS client session handshake error
gnutls debug: GnuTLS deinitialized
access_http error: cannot establish HTTP/TLS session

I think this should be reported to the VLC project, we can't do anything (other that allowing to get http urls #2364).

[Crypto90]

Please allow http urls or add a flag to disable to get https final links.
Referring to: #2364 (comment)

[Crypto90]

Just tested his patch, works fine.

[joeschmoe40]

What exactly is "$json_url"? On Linux, this works fine for me:

json_url is what I've been calling "the real URL" - the very long one that you get back from using the "-j" option.

I don't doubt that there are other ways to get to the goal - but the way my script is structured, what I do is take the "webpage_url" - shoot that to youtube-dl.py with "-j", get back the "real" URL, and use that (the "real" URL) thereafter.

As JaimeMF says, this may ultimately be a problem with VLC, specifically, VLC on OSX. Still, it would be nice if it could be fixed.

Also note the bit about needing --no-check-certificate in "wget". I think that is somehow related to this…

[joeschmoe40]

Also note (I tried your command line):

$ /Applications/VLC.app/Contents/MacOS/VLC $(youtube-dl.py -g 'CHICAGO - Colour My World (with lyrics)')
VLC media player 2.0.7 Twoflower (revision 2.0.7-3-g51f7bb4)
[0x100207760] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0x105a5a570] gnutls tls client error: TLS session: access denied
[0x105a5a570] gnutls tls client error: Certificate could not be verified
[0x105a5a570] gnutls tls client error: Certificate's signer was not found
[0x105a5a570] main tls client error: TLS client session handshake error
[0x10870e4a0] access_http access error: cannot establish HTTP/TLS session
[0x108703d00] main input error: open of `https://r9---sn-hp576nel.googlevideo.com/videoplayback?mv=m&upn=hH3GYU181i0&source=youtube&ms=au&requiressl=yes&ip=162.200.218.153&itag=18&ipbits=0&sparams=id%2Cip%2Cipbits%2Citag%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&id=ca539f8bb746254a&key=yt5&expire=1395090007&fexp=906373%2C911403%2C900228%2C916611%2C937417%2C913434%2C936910%2C936913%2C934022&mt=1395065511&sver=3&ratebypass=yes&signature=F785C1054948BF2E3D773CDD45709B26D4C94F53.1040D6EA66687224AA2C83F7D66B82BE1624248D' failed
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
[0x10027ea80] main playlist: stopping playback
$

[jaimeMF]

I can download the https url without any problem with curl, wget and Firefox, so it seems that the problem is with VLC (although I don't know why it fails in your case with wget). You can now use --prefer-insecure to get http urls, so I'm closing this issue.

[joeschmoe40]

Thanks. It looks like --prefer-insecure solves all my problems.

I assume that is a newly added option.

[jaimeMF]

Yes, it was added recently. I would use it only if it's the only solution, youtube-dl won't fetch the info over https, making it less secure.