It seems that rather than 404ing or some otherwise appropriate response to requesting the .m3u8 for a stream name that doesn’t exist, the HLS packetizer returns empty or invalid playlists.
For example, requesting “http://example.com/myapp/invalid/playlist.m3u8” where “invalid” is not a currently streaming stream name, it still returns a “chunklist.m3u8” with some default bandwidth specified. Requesting this chunklist will then return no .ts files.
Also, when using a name group, it returns an empty playlist for invalid stream names (e.g. “http://example.com/myapp/ngrp:invalid_all/playlist.m3u8”), containing only
#EXTM3U
#EXT-X-VERSION:3
This same thing also happens for an actual legitimate stream name for some amount of time right when streaming has begun. This is problematic because a player would get this empty playlist and then never play anything because it has no chunklists to open. If the playlist outright 404’d during this period, the player is better able to handle it.
Is there any way to make the behavior more sane? I would expect typically a 404 response when requesting the playlist for an invalid stream name.
What version of Wowza are you using? I think this has changed in a recent patch.
Richard
Actually, sorry, for a live stream this is expected. For vod you will get 404 when the file does not exist.
Richard
OK. Is there a rationale behind this behavior or is it simply the result of the way Wowza’s internals work? It seems to me to be unintuitive and could be a source of bugs. Invalid URLs should result in error codes, in my opinion.
Agree with John here, we’re currently having the same issue with Flowplayer where it will sit with a blank screen “playing” a stream that doesn’t actually exist (valid URL, Manifest.f4m returns valid XML, but the .stream file does not exist so no stream elements). Since there is no error being thrown, we cannot fallback to a nicer error slate to show the user, our player just looks broken. OSMF doesn’t seem to have the same issue, but we cannot change our player at this stage of development.
This seems to be consistent among 3.5.2, 3.6.2, and 3.6.3 instances I’ve tried. I am not running that 3.6.3 patch 1 you linked to, but will give it a shot on a test server when I get a chance.
OK. Is there a rationale behind this behavior or is it simply the result of the way Wowza’s internals work? It seems to me to be unintuitive and could be a source of bugs. Invalid URLs should result in error codes, in my opinion.
This is something affecting seriously to our setup. Failover is usually triggered by either non response from server or 40x/50x error code. An empty playlist prevents the failover to happen.
Can we expect a solution?
When using a name group Wowza Streaming Engine 4 still returns an empty playlist for invalid stream names (e.g. " http://example.com/myapp/ngrp:invalid_all/playlist.m3u8"), containing only
#EXTM3U
#EXT-X-VERSION:3
Any new solution for this problem?
we’re running into the same problem with ngrp and CDN fail-over configuration.
Is there a config change we can make to return a 404 if there isn’t a live stream available?
got the following answer from Wowza:
In the HTTPStreamer section of the Application.xml, or via the Manager add the following property Name: cupertinoAllowNotFoundOnEmptyMediaList Value: true Type :Boolean This should return a 404 if the ngrp/amlst/smil file is empty
Works fine in our setup.
Is param “cupertinoAllowNotFoundOnEmptyMediaList” work with custom AMLST module
in live stream app?
And what wowza version will work with this param?