@K-LIf Emotion supports SSL, then you won't get the problem. Or if (for some reason) SSL is not enforced in your area, then you won't get the problem.

You might put some blame on LiveForIt-MPlayer for not supporting SSL, but since SMTube is acting as the 'glue' between YouTube & MPlayer, I'd suggest that SMTube is the one that ought to be fixed. Especially since YT.rexx, which performs a similar function to SMTube, has already been updated to deal with the same problem.

Edited by ChrisH on 2017/4/10 8:46:18

_________________
Author of the PortablE programming language.I love using Amiga OS4.1 It is pitch black. You are likely to be eaten by a grue...

@K-LI'm not sure how you come to conclusion that SSL is not the problem; I'm pretty sure it is, but it only affects some versions of MPlayer (hence why YT.rexx has an optional special "SSL" mode).

Quote:

just check you installation (why no try with Emotion Demo from OS4Depot ? You'll be fixed).

FWIW, I already tried:

A *clean* installation of SMTube still behaves exactly the same way. OTOH, telling it to use some old/slow version of MPlayer is a work-around to the problem, but I'd like to stand some chance of watching 720p videos.

Emotion Demo does not appear to support streaming videos at all. I assume this is a limitation of the demo.

_________________
Author of the PortablE programming language.I love using Amiga OS4.1 It is pitch black. You are likely to be eaten by a grue...

I'm not sure what you mean by this. If you use YT.rexx's SSL option, then it uses curl to fetch the video and pipes it into mplayer.

If you notice 1.4 not showing all links, some links not working (unrelated to forced SSL) or it crashing intermittently, 1.5 will fix this. I altered some code to make it work within AREXX's 65K string limit.

I've been distracted by other things lately. I'd like to get the shared-from-mobile links working before releasing it. Anyone who hasn't already got the work in progress version can send me a message.

> That sounds like SSL stripping to me, since it means MPlayer doesn't need to handle SSL itself :).

Well, in the sense that mplayer is being fed non-encrypted data via the use of stdin/stdout, then sure :)

> And even the *option* is called "SSL" so I thought I couldn't be more clear!

The "nossl" mode requests videos as if it were embedded media, which used to return standard HTTP links. The "ssl" mode requests videos through the HTTPS site, which always returns SSL links.

YT.rexx (1.4) doesn't recognize forced SSL links, and so it won't use that experimental stdin/stdout stuff unless it knows it's SSL, hence the requirement to either set that as a config setting or on the command line. I'll make it automatically recognize SSL links for 1.5.