YouTube Plugin

[whurlston]

That file would only help the client UI read the output of the parser.aspx. It would not actually help the parser.aspx do it's job. Strangely, that video works fine for me. can you navigate to http://<server>:8866/public/youtube/parser.aspx?v=W1tzURKYFNs then zip and post the source code (or email it to me)?

[mvallevand]

It didn't work from the URL either so I thought to restart the recording service and it works now. I don't know why I didn't think about that before.

For those new to the YouTube plugin the best news bloopers of 2013 has some funny moments.

Happy New Year

Martin

[whurlston]

It didn't work from the URL either so I thought to restart the recording service and it works now. I don't know why I didn't think about that before.

Awesome.

For those new to the YouTube plugin the best news bloopers of 2013 has some funny moments.

Happy New Year

Martin

I will try to check it out tonight.

[liteswap]

Some of the encryption algorithms have changed and the youtube-dl project have moved to an auto decrypt routine instead of updating the decryption routines that I was pulling from them. I've known about the issue for a while but never had time to look into it until now.

Attached is a patch that should fix the problem.

Instructions for patch:

1. Replace the "Plugins\YouTube\youtube.*" files with the matching files in the zip (.dll and .pdb). (Exit NextPVR first.)
   
2. Place "parser.aspx" from the zip in your "web\public\youtube" folder. All other files in this folder can be removed because they are no longer used by this patch. It doesn't hurt anything to leave them though.
   

This patch no longer relies on the youtube-dl project. It now finds and uses the javascript decryption routines directly from youtube.


Separate error. Are you able to copy and post the error text (wrap in a code tag or upload it as an attachment)?

Thanks! 'Filename too long' error is attached.

In addition, I can't see any difference in behaviour with the new dll, I'm afraid...

[whurlston]

The error is being thrown by AutoRefresh. Specifically the function AutoRefresh.AutoRefresh.GetFromOverride(String path). I will need to look at the code in AutoRefresh to determine exactly what file/path that function is checking (whether it is an override file or the video file) . Ian sent me the code in the past, I just need to dig it out. If you disable AutoRefresh, do you get the error?

[whurlston]

I found that videos were taking much longer to buffer with the latest patch and with some debugging, I found that the two calls to the YouTube servers in parser.aspx were taking about 10 seconds each to return. I modified StreamerPost with some tweaks (that I use in CookieAwareWebClient) but they had no effect. I can only conclude that it is an issue with the cs files needing to be compiled at runtime in the webserver and not an issue with NEWA itself.

This patch moves the parser and automatic signature decryption code to the plugin dll. Now, the calls to the youtube server return in about 0.8 seconds instead of 18-20. This deprecates the web/public/youtube files completely (not the direction I wanted to go but the performance was just too slow for me).

The patch also fixes a couple of bugs that could cause NextPVR to crash if it tried to retrieve a nonexistent feed list.

[UncleJohnsBand]

I can only conclude that it is an issue with the cs files needing to be compiled at runtime in the webserver and not an issue with NEWA itself.

Correct..... but the compile is one-time then the compiled version is pulled from temp asp.net folder until a change is detected.... so it would not cause a consistent issue.....

[whurlston]

That's what I thought but for some reason, it still consistently took ~20 seconds for the call to parser.aspx to return for me.

I'll be releasing the code soon anyway (after some cleanup) so I'll leave it with the parser code in the dll for now.

Here's a patch to fix a stupid error on my part. PC clients with NMTModeAlwaysOn=false would play the lowest quality preferred stream. Running in NMTMode (PC clients with flag set to true or NMT clients) and WebClients were not affected by this.

[mvallevand]

That's what I thought but for some reason, it still consistently took ~20 seconds for the call to parser.aspx to return for me.

It is only consistently slow for me the first time and my server could be asleep, since it hadn't been touched since 2013

Code:

2014-01-01 01:09:49.025    [DEBUG][1]    YouTube: Parsed pconfig in 16255.9296875ms
2014-01-01 01:10:01.224    [DEBUG][1]    YouTube: Parsed pconfig in 381.021789550781ms
2014-01-01 01:10:10.860    [DEBUG][1]    YouTube: Parsed pconfig in 437.024993896484ms

Martin

[liteswap]

The error is being thrown by AutoRefresh. Specifically the function AutoRefresh.AutoRefresh.GetFromOverride(String path). I will need to look at the code in AutoRefresh to determine exactly what file/path that function is checking (whether it is an override file or the video file) . Ian sent me the code in the past, I just need to dig it out. If you disable AutoRefresh, do you get the error?

Thanks again for that. I had disabled but not deleted AutoRefresh - and doing so removes the error dialogue box. I've also installed the two latest patches.

Now I get a blank screen instead - no matter what the video is. It's as if there isn't a codec for the stream, but I can't see a specific error in the logs. Your eyes are almost certainly better than mine at spotting it...