passing Query String in the Repeater URL

Wowza Streaming Engine
1

Hi,

We’re currently using the resolveStreamAlias() method of the StreamNameAlias module on our Live Repeater Edges to dynamically return a fully-formed Live Repeater Origin URL for a stream. We’d also like to pass along query params but they don’t seem to get to the Live Repeater Origin. Is there anything we’re missing? Running Wowza 3.6.3 patch 2.

Thanks.

2

You can set querystring in the Application.xml /Repeater /QueryString

However, a Wowza edge does not make a new connection to the origin for each client, so you cannot pass a querystring for each edge playback session to the origin and still have the scaling benefit of Live Stream Repeater.

Richard

3

You can accomplish the second option by adding the querystring to the Application.xml /Repeater /QueryString

Or using the IApplicationInstance.setRepeaterQueryString() method

Richard

4

In Live Stream Repeater there is not a request to the origin from edge for each client. If you change the QueryString programatically I think it might generate a new request, but not sure. If every client somehow generated a new request to the origin you would not get the benefit of the Live Stream Repeater.

Richard

5

I’m not sure that I understand, but the Application.xml /DVR /WindowDuration value should do that.

Also, in case you are not using it, this method of caching DVR chunks on edge servers might be useful for you

Richard

6

Thanks Richard. Here’s our issue. We have a wowza ingest server that our customers push DVR feeds to. The ingest server in turn uses the PushPublish module to push the feeds to a wowza live repeater origin. While doing so, we pass along a custom DVR window size as a query string. On the live repeater, we set the DVR window size by implementing IDvrStreamManagerActionNotify and IDvrStoreListener as suggested by Scott here:

https://www.wowza.com/forums/showthread.php?25056-Setting-the-dvrInfo-windowDuration-value-in-the-Manifest-file&p=114027#post114027

This works great. However, we just noticed that if an edge server requests a DVR feed from an origin before the ingest feed is available, the dvrStreamStoreCreate() method gets called and the DVR window duration gets set to the default duration. So we need to either:

  1. Prevent an edge request from triggering dvrStreamStoreCreate()

or

  1. Pass along the custom DVR window duration as a query string when an edge hits the origin

I would much prefer #1 but I couldn’t figure out a way to do so, which is why I went with #2. Unfortunately, #2 doesn’t work. So we’re stuck right now. Any help would be much appreciated.

Thanks!

7

Wouldn’t that set the query string to the same value for all edge requests from a particular application? The value, which is the DVR window duration in our case, would be unique per feed.

8

Sure, that makes sense. But this wouldn’t be every client passing a different query string. All requests for a particular feed from an edge to the origin will include the same query string.

Going back to #1, is there a reason why a dvr store in initiated when an edge makes a request from the origin for a stream that does not exist? Seems like that would lead to a whole lot of dvr stores being generated for bogus requests. Any way we can check to see if the stream being requested actually exists on the origin?

9

So if we switch the archive strategy from ‘append’ to ‘version’, an edge request for a stream that doesn’t exist does not result in a DVR store being created, which is good. However, if an older version of the DVR store directory is present in the live origin, the edge begins playback of the contents of that version as an on-demand asset. I guess we can deal with that by nuking the old versions periodically. Is there a way to automate the deletion of old versions?

10

Thanks Richard. We’re already using the media cache addon. We’re set for now, thanks.