HLS.js / Wowza / Cloudfront Browser do not download media after Encoder restart - amazon-cloudfront

Question

my workflow is: 
Using ffmpeg I send an RTMP stream to WOWZA App1.
App1 sends the stream to an internal 2nd app(App2).
App2 transcodes and packetize to hls and is the origin for Cloudfront distribution.
Cloudfront serves the streams to users. 
The player on users is based on HLS.js.
To prepare for differents scenarios I forced App2 to restart during a test transmission, in this case App1 is still receiving stream from ffmpeg and trying to send it to App2, after app2 is ready this link is established again and App1 continues sending the stream to App2, but there is no video on client side.
Before restart, chunklist.m3u8 lists many chunks until the 17th: media-u3510ez40_17.ts
Then, while App2 is restarting chunklist.m3u8 do not exist and cloudfront send 404 error. 
And then, when App2 is back, chunklist.m3u8 lists a new list of chunks starting at 1 with a new id: media-u1ofkjj9w_1.ts
The problem is that there is no video and network traffic shows that the browser do not downloads the new listed chunks.
The chunklist.m3u8 keep adding new chunks but the browser do not download any of this... until appears the 18th Chunks... and the video restart.
I try many times and the problem is the same, before restart the last chunk has a number N, and after restart there is no video until reach de N+1 Chunk, but the Ids are different.
I don't know if this issue is on Wowza, Cloudfront or the HLS.js player :/
chunklist.m3u8 Before Restart:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:9
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXTINF:8.333,
media-u3510ez40_1.ts
#EXTINF:8.333,
media-u3510ez40_2.ts
#EXTINF:8.334,
.
.
.
media-u3510ez40_16.ts
#EXTINF:8.333,
media-u3510ez40_17.ts
chunklist.m3u8 After Restart:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:17
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXTINF:16.396,
media-u1ofkjj9w_1.ts
#EXTINF:8.333,
media-u1ofkjj9w_2.ts
.
.
.
media-u1ofkjj9w_16.ts
#EXTINF:8.333,
media-u1ofkjj9w_17.ts
#EXTINF:8.333,
media-u1ofkjj9w_18.ts

Answer 1

You need to set cupertinoCalculateChunkIDBasedOnTimecode property to true in Add Custom Property section of the Wowza Streaming Engine application. Refer this: https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming
Also, note that it will help in the case of encoders that send synchronized timecodes to Wowza. For encoder that doesn't send synchronized timecodes, I suggest to implement an absolute timecode irrespective of encoder send it or not. This will help the application to recover from the N+1 chunk number after the restart.
The below page will help you to configure it properly.
http://thewowza.guru/how-to-set-stream-timecodes-to-absolute-time/
About the session-id change part, When using Wowza as origin for Cloudfront distribution, you need to enable httpOriginMode and disable httpRandomizeMediaName to make it work properly. Below Wowza doc will help you set up it properly, https://www.wowza.com/docs/how-to-configure-a-wowza-server-as-an-http-caching-origin