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