40k

Yesterday we passed 40,000 downloads (this is the last download count update I promise :)

It still amazes me that so many people want and use these scripts. We now have 52 scripts, most containing dynamic content. When I first got cable as a child we had about the same amount of channels. Of course now we have 100's if not 1000's of channels available to us and hopefully those cable channels will put their content on line so we can borrow it.

30,000 Downloads, thanksgiving and ads

First I'd like to wish everyone a Happy Thanksgiving!

Second I'd like to point out that just 3 days ago we passed the 20k download mark. 10k downloads in 3 days is very impressive.

The last thing has to do with the Ads on the site. I'm not really making any amount of money on the ads, the revenue might pay for the hosting costs. If there is any cash left over I will try to send some giftcards out to the other Script Developers. Hopefully I'll receive a check before Christmas but it doesn't look good. We have far too many Firefox users coming to the site ;)

0.7.0.1

Had to push a quick bug fix, if you downloaded 0.7.0.0 earlier today please update to 0.7.0.1 to have the AutoRun scripts work.

Get it Here.

Thanks

Setting the Date of a VideoResource()

New in 0.7.0.0 is the ability to set the the date of a VideoResource. In retrospect this is something I should have included from day one but unfortunately I didn't see the potential. I want to thank hottamale from the site for requesting this and reminding me that it actually exists.

So in order to make this available and preserve backwards compatibility I had to come up with a work around and so I decided to add a special XML tag to the description to handle it (I'm claiming the <special> tag)

local dateXML = '<special date="1.0"><year>2009</year><month>11</month><day>11</day></special>';

VideoResource("test", "video.mp4", "This is before the special tag"..dateXML.."and this is after", "", 100000);

The plugin will extrapolate the Date information and remove the data from the description before it ever gets to the user's screen. Just keep in mind that the format is very strict and will attempt to catch and throw an error if malformed but if not properly set you could end up with ugly tags being sent to the user.

New Release

I decided to push the release of version 0.7.0.0 up a couple days, get it right now!

The update log:

0.7.0.0
Developers may now force a video type to PlayOn by including the tag <special force="wmv"> (for Windows Media Video) and <special force="flv"> (for Flash Video) in the video's url.
If autorun.lua is present in the Scripts directory, default loading is bypassed and autorun.lua is executed
Extended Lua with LoadScript();
Extended Lua with GetURLXxR();
Fixed a bug with SetScriptOption();
Added GetScriptOptionX(); and SetScriptOptionX(); which allows access to other scripts options (or create custom sections)
VideoResource(); now excepts a date, accessed by some xml data in the description var.
Extended Lua with GetVideoPerformanceLevel();

20,000 Downloads

We just destroyed 20k total downloads. I had no idea the Plugin, Scripts and site would effect so many people. Amazing stuff.

LoadScript() and PlayOn contacted me

LoadScript
In my last post I recommended using the new LoadScript() function to load a script from our autorun scripts. I'd like to rescind that, I completely forgot about 'exec:'.

From our VirtualFolder() or VideoResource() calls we already have the ability to execute scripts within the Scripts\ directory. Something like:

VirtualFolder("Run Script", "exec:NBC.lua");

will work great in our autorun scripts.

I was going to remove LoadScript() altogether but I decided to leave it in, currently we could do something like:

local file = GetCurrentPath().."\\Scripts\\NBC.lua";
local contents = OpenFile(file);
RunScript(contents);

LoadScript() will make this easier

local file = GetCurrentPath().."\\Scripts\\NBC.lua";
LoadScript(file);

However, there is one caveat, LoadScript() and RunScript() will report itself to the plugin as though it is the executing script and not the executed script. What this means is that GetScriptOptions() and SetScriptOptions() will not work as expected. To have those functions behave properly they need to be ran with 'exec:' from within a VirtualFolder() or VideoResource() call.

edit: ignore the crossed off stuff, LoadScript() will properly identify itself as the correct script.

PlayOn Interaction
I just want to thanks the other script developers for making the plugin as awesome as it is. In fact it's impact is such that PlayOn has contacted me and asked me to make some specific changes which is cool :)

More autorun

I just finished a autorun script that gets a list of scripts and their categories from PlayOnScripts.com and organizes the scripts on my server based on those categories. Pretty cool stuff.

On a side note I forgot to mention in the last post that nil LoadScript(string file) has been added so our autorun scripts can have the plugin load the script.

autorun.lua

I've been thinking lately about how to manage the growing number of scripts within the Scripts Plugin. I thought I could allow the developers to tag their scripts with categories or maybe use the categories from PlayOnScripts.com, but they both seemed cumbersome to implement. So I decided to allow the user to decide how to organize their scripts using....wait for it....it's coming....a Script.

Version 0.7.0.0 of the Scripts Plugin will check for the existence of autorun.lua and, if it exists, will execute the Script, bypassing the normal start up routine of loading the script's names from the Scripts\ folder. It opens the door for some interesting ways to organize our Scripts.

I haven't had a chance to write my own organizer yet but I do have some ideas brewing.

Forcing Video Type

In the next version of the Scripts Plugin, v0.7.0.0, I've added the ability to force the Scripts Plugin to send videos to PlayOn based on what you submit and not what the Scripts Plugin thinks it is.

How it works now
Originally the Scripts Plugin checked for a file extension, if it was WMV then the video was set to Windows Media, everything else would be Flash. This proved flawed as server side parameters break this set up. As an example http://www.url.com/video.wmv?hashcode=ff7fa02b would be interpreted as a Flash video when it is a WMV. So instead of checking file extensions I changed it to simply check for the existence of .wmv and if it exists then it will set it as Windows Media. Still flawed however when you consider a url like this: http://www.url.com/video.wmv.flv the plugin assumes it is a WMV file which is incorrect.

Solution
Enter the <special> tag. So far the tag only excepts one parameter "force". By appending a url we send, to ResolveXML() or to the plugin directly from a VideoResource(), with the new tag we can explicitly tell the plugin the type, regardless of file extension. Using the example above we could do: http://www.url.com/video.wmv.flv<special force="flv"> The Scripts Plugin will now tell PlayOn that the video is a flash video regardless of any other factors. We could even tell PlayOn that the video with a .flv extension is to be decoded as Windows Media: http://www.url.com/video.wmv.flv<special force="wmv">

Version 0.7.0.0 will be released a short time after Thanksgiving.

Coming Soon

This will be where we can make announcements in the future