We are doing tests with the nDVR playlist request delegate following this doc:
https://www.wowza.com/docs/how-to-use-wowza-ndvr-playlist-request-api
We have created one delegate and deployed it to our WSE server, and it works correctly in the sense that it does create manifests based on the specified start/end parameters as stated in the doc.
However, one problem that we noticed so far is:
the delegate is only invoked the first time a playlist request for a stream comes before that stream is created (by created, I mean the IModuleOnStream.onStreamCreate callback is called for that stream after its previous onStreamDestroy callback). All following requests are not forwarded to the delegate even if they are with different start/end values than the first one.
To illustrate the problem, suppose we have a stream with name “stream_1” in a live app “app_1”:
- start WSE and the app, and wait for nDVR to record some data.
- request “…/app_1/stream_1/manifest.mpd?DVR&start=1676023500”. <= it returns the correct manifest.
- request “…/app_1/stream_1/manifest.mpd?DVR&start=1676023800”. <= it returns a manifest with the same start as the previous request.
- wait for around 25s. <= until onStreamDestroy is called for “stream_1”.
- try #3 again. <= this time it returns the manifest with the correct start.
From the log, we confirmed that at #2 and #5 our delegate did get invoked, but not at #3.
It seems there is some caching mechanism on the returned DvrPlaylistRequest from the delegate in WSE to not forward every single client playlist request to the delegate, which I think makes sense. If that’s the case, it should take into account of the arguments in the request when deciding if the request has already been cached.
Could you please confirm if this is an issue of WSE or there is some setting that we might have missed?
