Difference between revisions of "Checking for Updates"

From A-SMIL.org
Jump to: navigation, search
m
(Added section to recommend using static SMIL as best practice)
Line 14: Line 14:
 
The playlist will reload itself every 60 seconds (or any specified interval).  
 
The playlist will reload itself every 60 seconds (or any specified interval).  
  
However, each time the playlist is reloaded, playback restarts from the beginning of the SMIL document. To avoid restarting the playlist when the playlist is not changed, have your SMIL generating script support the HTTP "Last-Modified:" header (which is usually omitted in dynamic scripts). If the last modified time has not changed, SMIL player will not reload the file and therefore will not restart playback.
+
== Best Practice: Using Static SMIL File ==
  
== How do I Generate Last-Modified: Header ==
+
You may be tempted to use a server-side script to dynamically feed your playlist to the players. However, the simplest and most scalable way to host the SMIL playlist is to store it as a static file on the server. Updates are applied to the file when user chooses to update the schedule. When you perform the update, make sure the change is "atomic" so that players will not download a partial SMIL while it is being updated. Create the new SMIL file separately, and renaming it to the name of the old SMIL version is one way to do this.
  
The easiest way is to serve your playlist as a local file that is updated by a background daemon at regular intervals. Most web servers would automatically tag on the Last-Modified: header using the timestamp on the file.
+
If you are using a server-side script as the "master entry point" for all your players, it is recommended that you use an HTTP "Location:" header to redirect your player to its corresponding SMIL file once you have determined the player's identity (see [[Player ID]]).
 +
 
 +
== Using a Dynamic Server-side Script ==
 +
 
 +
If you must use a dynamic server-side script to generate your SMIL file, make sure you supply an HTTP "Last-Modified:" header so the player does not abruptly restart its playback each time it checks for an update. If the last modified time has not changed, SMIL player will not reload the file and therefore will not restart playback.
  
 
It is a good practice to support the header. Media feeds that are designed to serve a large user base typically support the Last-Modified: header, such as:
 
It is a good practice to support the header. Media feeds that are designed to serve a large user base typically support the Last-Modified: header, such as:
Line 27: Line 31:
 
---response begin---
 
---response begin---
 
HTTP/1.1 200 OK
 
HTTP/1.1 200 OK
Date: Wed, 18 Nov 2009 11:16:09 GMT
+
...
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
+
Expires: Mon, 26 Jul 1997 05:00:00 GMT
+
 
Last-Modified: Wed, 18 Nov 2009 11:16:01 GMT
 
Last-Modified: Wed, 18 Nov 2009 11:16:01 GMT
Cache-Control: no-store, no-cache, must-revalidate
+
...
Cache-Control: post-check=0, pre-check=0
+
Pragma: no-cache
+
Connection: close
+
Content-Type: application/atom+xml; charset=utf-8
+
  
 
---response end---
 
---response end---

Revision as of 04:30, 9 July 2010

It is often necessary to check for an update in the playlist while the current playlist is playing. To do that, simply use the "Refresh" meta tag as shown below.

<smil>
  <head>
    <meta http-equiv="Refresh" content="60"/>
  </head>
  <body>
    ...
  </body>
</smil>

The playlist will reload itself every 60 seconds (or any specified interval).

Best Practice: Using Static SMIL File

You may be tempted to use a server-side script to dynamically feed your playlist to the players. However, the simplest and most scalable way to host the SMIL playlist is to store it as a static file on the server. Updates are applied to the file when user chooses to update the schedule. When you perform the update, make sure the change is "atomic" so that players will not download a partial SMIL while it is being updated. Create the new SMIL file separately, and renaming it to the name of the old SMIL version is one way to do this.

If you are using a server-side script as the "master entry point" for all your players, it is recommended that you use an HTTP "Location:" header to redirect your player to its corresponding SMIL file once you have determined the player's identity (see Player ID).

Using a Dynamic Server-side Script

If you must use a dynamic server-side script to generate your SMIL file, make sure you supply an HTTP "Last-Modified:" header so the player does not abruptly restart its playback each time it checks for an update. If the last modified time has not changed, SMIL player will not reload the file and therefore will not restart playback.

It is a good practice to support the header. Media feeds that are designed to serve a large user base typically support the Last-Modified: header, such as:

http://api.flickr.com/services/feeds/photos_public.gne

---response begin---
HTTP/1.1 200 OK
...
Last-Modified: Wed, 18 Nov 2009 11:16:01 GMT
...

---response end---

Last-Modified: info is used by proxies to maintain their cache. Suppose 10,000 players access your playlist once every 10 minutes, it would not be wise to serve them via a live script (which would pull on YOUR SOURCE 1,000 times per minute, wasting lots of bandwidth and processor cycles).

Related