Page 8 of 13

Re: Youtube3

PostPosted: Fri Dec 25, 2015 1:09 am
by mad_ady
Yeah, let's hope it lasts for a while...

Re: Youtube3

PostPosted: Sun Dec 27, 2015 11:32 pm
by mlash83848
Where can I get this plugin? I can't find it anywhere. Thanks

Re: Youtube3

PostPosted: Mon Dec 28, 2015 11:30 pm
by mad_ady
Currently the svn server hosting all plugins is down. Hopefully it will be fixed soon. Check for progress here:

Re: Youtube3

PostPosted: Tue Dec 29, 2015 1:16 pm
by cybermcm

Was there ever a solution to this problem. I'm facing it as well with other videos. The videos stop always at the same timestamp, e.g. video is 35 minutes long, video stops at 11, than 22, than 33 minutes. Another video stops after 20, 40 minutes...
Is there anything (logfile,...) I can do on my end to help you with this? Unfortunately I can't offer any programming skills :-(

Re: Youtube3

PostPosted: Tue Jan 05, 2016 12:34 am
by mad_ady
I don't think I have a solution for it, sorry. Most likely the server closes the connection and the WDTV is lost and needs to start over...

Re: Youtube3

PostPosted: Tue Jan 05, 2016 3:53 am
by cybermcm
@mad_ady: thanks for your reply. It turned out that it happens only with a few videos which my kids are currently watching, so no big issue.

Re: Youtube3

PostPosted: Tue Jan 05, 2016 4:41 am
by mad_ady
Are they long videos with low bitrate? E.g. Music with static image? That would explain why the connection is closed due to inactivity.

Re: Youtube3

PostPosted: Tue Jan 05, 2016 11:41 am
by cybermcm
mad_ady wrote:Are they long videos with low bitrate? E.g. Music with static image?

Yes, all videos are long videos (>30 min), but not music, comic videos, a few of them in 720p. But there is only slow movement within these videos, so maybe inactivity is the cause

Re: Youtube3

PostPosted: Tue Jan 05, 2016 12:39 pm
by willsguise
As I wrote in my earlier post of 06/12/2015:" Indeed I have experienced it watching all Avrotros Klassiek's most recent videos. "

This is a video of a classical orchestral concert in which there is plenty of activity (e.g. the players in the string section vigorously bowing their instruments) and it is in HD, so I do not think that low bitrate can be the answer. I have also had the problem with some long videos of trains and trams and although trams move quite slowly there is no lack of activity generally.

Re: Youtube3

PostPosted: Sat Jan 09, 2016 8:06 am
by mad_ady
Sorry, I haven't been able to answer due to family issues (kids are sick again) :(

If you want we can try to explore this further, but I think implementing a solution will not be that easy.

Here's what I need from you as logs when you reproduce the issue:
1. Enable debugging in the youtube3-proxy script:
Code: Select all
sed -i 's/$logLevel = L_WARNING;/$logLevel = L_ALL;/' /tmp/umsp-plugins/youtube3/youtube3-proxy.php

Logging output goes to /tmp/umsp-log.txt (it gets created when needed).
2. Install and use tcpdump to capture traffic while you're streaming (command assumes you're using eth0):
Code: Select all
tcpdump -n -i eth0 -s 1600 -w /tmp/youtube.pcap not port 22 or not port 23

Once the issue is reproduced, copy over (via scp or ftp) the /tmp/youtube.pcap file to your PC or it will be lost on reboot. On second thought, you should probably capture to a path on your USB disk instead, since /tmp has at most 90MB free, and a capture of your video file will be larger than that and you risk corrupting your /conf partition.
3. Start video playback in debug mode via telnet/ssh:
Code: Select all
killall MediaLogic
MediaLogic AV MSGL_DBG

So, once you perform steps 1-3 (actually you just start step 2, you can hit CTRL+C to finish the capture once the issue has been reproduced), you can play a video to reproduce the problem. Once the problem is reproduced, copy and send to me the packet capture, the contents of /tmp/umsp-log.txt and the output you get from MediaLogic so that I can have a look.

Note, you should play only one video to reproduce the issue, otherwise I might get confused in the logs. If the issue doesn't reproduce on first try, best restart and do the steps again.

Now, all this work will at best show us what's wrong. If the problem is what I think it is, let me tell you why I can't fix it easily...

You see, the proxy works like this:
1. MediaLogic receives a video URL pointing to the proxy with youtube's video ID as parameter
2. The proxy does the necessary work to figure out the URL behind the real youtube video for your desired quality level
3. The proxy requests the video, sends back to MediaLogic the tweaked HTTP headers it receives from Youtube and...
4. The proxy uses fpassthru ( to flush out the contents of the socket to stdout (meaning it "prints" as fast as it can all the data it gets from youtube (e.g. the video contents)).

The problem lies in step 4. If youtube sends a bunch of data, but because MediaLogic's buffer is full it is instructed (via TCP window messages) to slow down or stop transmission. If transmission is stopped for a while (30s? 1 minute?), firewalls along the way or youtube's servers can decide that the connection needs to be closed because it's taking up resources and could be a type of denial of service attack (something like slowloris). So, the server closes the connection and MediaLogic remains with whatever it had in the buffer (max 2MB). When the buffer runs out playback freezes.

The elegant solution to this problem is for MediaLogic to identify this problem (broken socket) and reopen the connection (re-execute the proxy) to resume from where it left off. This might be felt like a longer buffering period, but playback would resume automatically). But, as far as I know MediaLogic doesn't care and stops completely.

Now, the not-so-elegant-but-just-might-work solution could be to add this logic to the proxy. Step 4 would need to change in a loop where the php code reads a chunk (4K?) of data from youtube and prints it back to MediaLogic. If the socket breaks the proxy code could discover it and reconnect and resume transparently (however it needs to keep track of what the Content-Length is and calculate how much data has been transmitted). The problem here is - what happens when the user stops playback (from MediaLogic)? The proxy script will probably not get the message (unless its explicitly killed) and will keep downloading the data from youtube. Also, this will use more resources in the WDTV potentially making playback a bit slower (longer buffering times), but it's not impossible.

Note, even if it might work I'm not going to implement this change due to lack of time and interest. But if some brave soul wants to take it on, and it works, I'll commit the change :)