Difference between revisions of "Checking for Updates"

From A-SMIL.org
Jump to: navigation, search
(Clarified that GET is not issued when HEAD indicates there is no update)
m (Added pointer to prefectch article)
 
(2 intermediate revisions by the same user not shown)
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 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 28: Line 32:
 
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).  
 
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.
 
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 36: Line 40:
 
== Related ==
 
== Related ==
  
 +
* [[Fixed Playlist, Dynamic Content]]
 
* [[SMIL_Connectivity|SMIL connectivity]]
 
* [[SMIL_Connectivity|SMIL connectivity]]
 
* [[MediaRSS|Media RSS Bridge]]: connecting a media RSS content feed to SMIL
 
* [[MediaRSS|Media RSS Bridge]]: connecting a media RSS content feed to SMIL

Latest revision as of 04:57, 17 December 2010

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.

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

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

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:" response 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.

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

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