philippe_44 wrote: 
> An explanation can be caching because when I cache various data, they
> have different time-to-live so one day later, some hate being re-read
> from the source rather than from the cache.

Here on the US West Coast I also have a lot of videos returning the "no
stream/DASH found"

Looking at the html response of these files, I see that they are no
longer formated the same way. In previous version, double quotes were
espcated with a backslash, and actual backslashes are double escaped.
See the difference here (you can see the double escape around the codec
info):

Previous response formatting:

Code:
--------------------
    \"adaptiveFormats\":[{\"itag\":136,\"mimeType\":\"video\/mp4; 
codecs=\\\"avc1.4d401f\\\"\",\"bitrate\":129907,\"width\":1280,\"height\":720,\"initRange\":{\"start\":\"0\",\"end\":\"713\"},\"indexRange\":{\"start\":\"714\",\"end\":\"1693\"},\"lastModified\":\"1514560900374562\",\"contentLength\":\"5026945\",\"quality\":\"hd720\",\"fps\":25,\"qualityLabel\":\"720p\"
--------------------


New response formatting (no more backslashes except the codec that has
double quotes escaped within the json string):

Code:
--------------------
    adaptiveFormats":[{"itag":136,"mimeType":"video/mp4; 
codecs=\"avc1.4d401f\"","bitrate":129907,"width":1280,"height":720,"initRange":{"start":"0","end":"713"},"indexRange":{"start":"714","end":"1693"},"lastModified":"1514560900374562","contentLength":"5026945","quality":"hd720","fps":25,"qualityLabel":"720p"
--------------------


The problem with the new format is that on line 369 of
ProtocolHandler.pm, there is some code to clean up the backslashes

Code:
--------------------
                 # remove all backslashes except double-backslashes that must 
be replaced by single ones
  $content =~ s/\\{2}/\\/g;
  $content =~ s/\\([^\\])/$1/g;
--------------------


The problem is that with the new formatting, that code ends up removing
the single backslash in front of the codec quotes; but these are needed
to escape the double quote inside the JSON string. By removing it, it
makes the JSON invalid and it fails to load on line 397


Code:
--------------------
    $streams = eval { decode_json($streams) };
--------------------
 fails

To test, one can just comment the 2 regular expression lines and then it
works (at least past the decode_json part).

The second problem is that the player url we get via jsUrl in no longer
within ytplayer.config; so that code on line 729 no longer reaches it;
but jsUrl is still available other places, so I have added one line to
the code block that just grab the first jsUrl it finds if the previous
way fails


Code:
--------------------
    
  # get the player's url
  my ($player_url) = ($content =~ /"assets":.+?"js":\s*("[^"]+")/);
  ($player_url) = ($content =~ /ytplayer\.config\s*=.*"jsUrl":\s*("[^"]+")/) 
unless $player_url;
  ($player_url) = ($content =~ /"jsUrl":\s*("[^"]+")/) unless $player_url;
  
--------------------


With these 2 changes (commenting the regular expressions removing
backslashes and adding the lone jsUrl) then it works again.

Of course removing the backslash code will most likely cause old
response formats to fail.  So now we have to figure out how to handle
files with double backslashes differently than files without.


------------------------------------------------------------------------
dawansv's Profile: http://forums.slimdevices.com/member.php?userid=22248
View this thread: http://forums.slimdevices.com/showthread.php?t=105840

_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to