Fetching Content

A repeating pull mechanism is implemented easily.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<smil>
	<head>
	    <meta http-equiv="Refresh" content="900"/>
	</head>
	<body>
	</body>
</smil>
Playlist will refresh every 15 minutes (900 s)

This is for the playlist only. There is another mechanism to check continuously for new media content. This is discussed in the section of this tutorial.

How Refresh Request is sent

Digital signage media player in a network regularly points to an http-address which has the index. To do this as efficiently as possible, there are two types of requests:

  • HEAD-Requests
  • GET-Requests
On each refresh cycle, the player sends HEAD request first.

The HEAD-Request

The HEAD request only asks for the HTTP header with an empty body to save bandwidth and server resources. The server should send an HTTP "Etag," “Last-Modified:” and a “Content-Length:” in his header. Due to this information, the player can decide to send a GET-Request to get a new SMIL index or not.

Garlic player will send the following HEAD-Request if he asks for a file he did not fetch before.

HEAD /index.smil HTTP/1.1
	Host: content-url.com

If the file is already fetched, garlic-player will add If-None-Match and If-Modified-Since as fallback.

HEAD /index.smil HTTP/1.1
   Host: example.com
   If-None-Match: "a1b2c3d4e5f6"
   If-Modified-Since: Wed, 15 Nov 2023 12:30:45 GMT

Reaction on Server Response

When the server sends back a 304 Not modified response after HEAD request, garlic player will not send a GET request. This will happen only on a 200 OK.

In this way we ensure the client/server communication is as efficient as possible.

Have in mind that the priority is to check etag (If-None-Match), as If-Modified-Since is not accurate enough.