Carlos E. R. wrote:
On 2014-04-14 15:03, Linda Walsh wrote:
Carlos E. R. wrote:
That's my problem... I can not do *anything* while Firefox is downloading from youtube!
Have you tried wondershaper?
It does a fair job of prioritizing your network usage so things like DNS have priority over FF.
Maybe I should have a look at it... that would allow the PC doing the download to keep working, but not the rest of the gadgets in the house.
That's one reason why my linux box *is* my router. What does your router do that your linux box can't?
No way to differentiate youtube traffic. Except... perhaps let the download start, find the IP used, and then create the rule. Possible... cumbersome...
Usually you'd use a predefined block of IP's to manage. Either that or have squid mark the TOS based on youtube being present.
You could route FF through squid so squid can set the TOS bits on all web traffic, to further the actions of wondershaper.
There is a trick via setting the SGID of a binary to mark packages. But it would be the upload that I could control that way, not the download. :-?
---- Coming back -- is trickier. Used to be you could only drop to accept because to differentiate, you have to accept first, but I think it is the IFB (there have been a couple of competing TLA's) that can play the part of an intermediate input buffer that queuing policy can be applied to on input.
+++················ wget "http://r4---sn-h5q7enls.googlevideo.com/videoplayback...
Cannot write to ‘videoplayback?sver=...mv=m&ratebypass=yes’ (File name too long). ················++-
Have you tried specifying the file it should save to? i.e. the "-O" switch?
I did not identify "-O" as the appropriate switch... O:-)
--- Does that mean it might work, or that it does? .. I.e. when I had a 'too long' google filename, it worked.
This command is easier, it understand "youtube" directly:
youtube-dl --write-sub --sub-lang 'en,es' -r 50K \ -f 135 http://www.youtube.com/watch?v=...
---- youtube does it's own handshakes within it's protocol, it knows if the communication is lagging (blocked), or if the user has pressed pause, or such... send status back to you tube about every 2-3 seconds of video so they can bookmark your place, among other things..(watched the protocol exchange of a friend watching YT, They might know it down to the second so they can estimate buffering needed and congestion... (at least when you are watching it directly, when you pre-download, I don't think it applies the same algorithms). Another thing to try is to 'strangle' FF. nice & ionice it down and limit it to 1 cpu. Then you could indirectly slow it down by running something else w/high cpu prio on the same cpu. Part of the problem in scheduling --- is the network scheduler only can get scheduled (usually) about once/millisecond), and then if you use a 1000Hz clock. I found out w/the policing method, my D/l BW was getting choked with almost any settings -- so I only controlled uploading when I was doing that. But that was before the IFB...(imq?)..... Yeah -- I saw the delay pools in squid -- they might also help, but have never used them.
I should try perhaps "trickle" in combination with "youtube-dl".
--- Definitely try it... if it works, problem solved! (until needs grow... ;-))... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org