Checking for Updates - Revision history

SMIL T.A.: Added pointer to prefectch article

2010-12-17T04:57:29Z

Added pointer to prefectch article

SMIL T.A.: Added link to related content

2010-11-03T07:17:16Z

Added link to related content

SMIL T.A. at 16:04, 9 July 2010

2010-07-09T16:04:50Z

SMIL T.A.: Clarified that GET is not issued when HEAD indicates there is no update

2010-07-09T16:03:15Z

Clarified that GET is not issued when HEAD indicates there is no update

SMIL T.A.: Noted about making sure HEAD and GET are returning identical information

2010-07-09T08:08:34Z

Noted about making sure HEAD and GET are returning identical information

SMIL T.A.: Added use of HEAD and GET response headers

2010-07-09T08:05:22Z

Added use of HEAD and GET response headers

SMIL T.A.: Added section to recommend using static SMIL as best practice

2010-07-09T04:30:56Z

Added section to recommend using static SMIL as best practice

SMIL T.A. at 11:34, 18 November 2009

2009-11-18T11:34:46Z

SMIL T.A.: Added how to tag on Last-Modified header

2009-11-18T11:31:12Z

Added how to tag on Last-Modified header

SMIL T.A. at 10:19, 18 November 2009

2009-11-18T10:19:23Z

← Older revision		Revision as of 04:57, 17 December 2010
Line 1:		Line 1:
−	This document focuses on the best practice for updating screen when the SMIL is updated (playlist changes). For a special (simplified) application where the SMIL stays the same but media files get updated, see [[Fixed Playlist, Dynamic Content]].	+	''This document focuses on the best practice for updating screen when the SMIL is updated (playlist changes). For a special (simplified) application where the SMIL stays the same but media files get updated, see [[Fixed Playlist, Dynamic Content]].''
		+
		+	''This page only covers the SMIL file but not the contained media files. For preferred content update strategy using SMIL's <prefetch> tag, please see [[Prefetch]].''

	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.		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.

@@ Line 1: / Line 1: @@
 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.
@@ Line 36: / Line 38: @@
 == Related ==
 * [[SMIL_Connectivity|SMIL connectivity]]
 * [[MediaRSS|Media RSS Bridge]]: connecting a media RSS content feed to SMIL

@@ Line 28: / Line 28: @@
 During each Refresh cycle, the server receives two requests from the player: a HEAD followed by a GET request. The HEAD request only asks for the HTTP header with an empty body (and therefore doesn't need to have the SMIL actually generated).
-The player looks at the HEAD response (mainly for Last-Modified: and Content-Length:), and decides whether it needs to do a GET for the updated SMIL file and restart playback. ''If the player decides from the HEAD response that SMIL is not updated, then it does not send the GET and therefore you would not to actually generate the SMIL file.
+The player looks at the HEAD response (mainly for Last-Modified: and Content-Length:), and decides whether it needs to do a GET for the updated SMIL file and restart playback. ''If the player decides from the HEAD response that SMIL is not updated, then it does not send the GET and therefore you would not need to actually generate the SMIL file.''
 ''
 Note that with the HEAD response you need to have all response headers IDENTICAL to the GET response, especially "Content-Length:". This can be tricky since the HEAD and GET requests happen at different times. When there is an update, your HEAD request handler will need to generate the SMIL file and cache it for the later GET request so the returned value from both requests are identical.

@@ Line 26: / Line 26: @@
 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.
-During each Refresh cycle, the server receives two requests from the player: a HEAD followed by a GET request. The HEAD request only needs the HTTP header with an empty body (and therefore doesn't need to have the SMIL actually generated).
+During each Refresh cycle, the server receives two requests from the player: a HEAD followed by a GET request. The HEAD request only asks for the HTTP header with an empty body (and therefore doesn't need to have the SMIL actually generated).
-−
-The player looks at the HEAD response (mainly for Last-Modified: and Content-Length:), and decides whether it needs to do a GET for the updated SMIL file and restart playback.
 Note that with the HEAD response you need to have all response headers IDENTICAL to the GET response, especially "Content-Length:". This can be tricky since the HEAD and GET requests happen at different times. When there is an update, your HEAD request handler will need to generate the SMIL file and cache it for the later GET request so the returned value from both requests are identical.

@@ Line 30: / Line 30: @@
 The player looks at the HEAD response (mainly for Last-Modified: and Content-Length:), and decides whether it needs to do a GET for the updated SMIL file and restart playback.
-Note that with the HEAD response you need to have all response headers IDENTICAL to the GET response, especially "Content-Length:". In order for you to return that number back to the player, you may need to cache that information (length of the SMIL file) after you have generated the SMIL file the first time. You must make sure the Content-Length returned in HEAD response is EXACTLY the same as GET, otherwise the player will think the GET does not match HEAD and keep asking until they are identical.
+Note that with the HEAD response you need to have all response headers IDENTICAL to the GET response, especially "Content-Length:". This can be tricky since the HEAD and GET requests happen at different times. When there is an update, your HEAD request handler will need to generate the SMIL file and cache it for the later GET request so the returned value from both requests are identical.
 == Related ==

@@ Line 12: / Line 12: @@
 </source>
-The playlist will reload itself every 60 seconds (or any specified interval).
+The playlist will check back every 60 seconds (or any specified interval), and reload itself if it is changed (determined by issuing an HTTP HEAD request and comparing the Last-Modifed response header against the previously version in-use).
-== Best Practice: Using Static SMIL File ==
+== Best Practice: Using a 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.
+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.
-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]]).
+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.
 == 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.
+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.
-−
-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
-<PRE>
+During each Refresh cycle, the server receives two requests from the player: a HEAD followed by a GET request. The HEAD request only needs the HTTP header with an empty body (and therefore doesn't need to have the SMIL actually generated).
----response begin---
-HTTP/1.1 200 OK
-...
-Last-Modified: Wed, 18 Nov 2009 11:16:01 GMT
-...
----response end---
+The player looks at the HEAD response (mainly for Last-Modified: and Content-Length:), and decides whether it needs to do a GET for the updated SMIL file and restart playback.
-</PRE>
-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).
+Note that with the HEAD response you need to have all response headers IDENTICAL to the GET response, especially "Content-Length:". In order for you to return that number back to the player, you may need to cache that information (length of the SMIL file) after you have generated the SMIL file the first time. You must make sure the Content-Length returned in HEAD response is EXACTLY the same as GET, otherwise the player will think the GET does not match HEAD and keep asking until they are identical.
 == Related ==

@@ Line 14: / Line 14: @@
 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]]).
 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---
 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
-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---

← Older revision		Revision as of 11:31, 18 November 2009
Line 15:		Line 15:

	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.		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.
		+
		+	== How do I Generate Last-Modified: Header ==
		+
		+	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.
		+
		+	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
		+
		+	<PRE>
		+	---response begin---
		+	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
		+	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---
		+	</PRE>
		+
		+	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 processor cycles).

	== Related ==		== Related ==