Reduced HLS Latency causes transcoded playlist issues - nginx

Question

Software Info:
* ubuntu 16.04
* Nginx 1.15.1
So recently I was reading around for low latency for HLS stream on nginx and found a solution here: Reduce HLS latency from +30 seconds
this will reduce the latency to ~7 seconds but then I also wants to transcode the stream and the latency for that doesn't really matter (all I want is the source to be low latency but if transcoded version can then it would be extra) but when I do so, the source has no issue but the transcode version gives issues which essentially the browser script will tries to play an early version of the fragment which already been deleted so it causes 404 errors. So how do I solve it so that I can achieve the ~7 seconds latency for the source and have the transcode version working at the same time?
My current configuration:
FFMPEG Transcode
-c:v copy -preset:v ultrafast -b:v 6000K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_source
-c:v libx264 -preset ultrafast -s 852x480 -tune fastdecode -b:v 1000K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_medium
-c:v libx264 -preset ultrafast -s 1280x720 -tune fastdecode -b:v 3500K -c:a copy -tune zerolatency -f flv rtmp://localhost/stream/$name_high
-c:v libx264 -preset ultrafast -s 426x240 -b:v 400K -c:a copy -tune fastdecode -tune zerolatency -f flv rtmp://localhost/stream/$name_low
HLS:
hls_fragment 1s;
hls_playlist_length 4s;
hls_variant _source BANDWIDTH=600000;
hls_variant _high BANDWIDTH=350000;
hls_variant _medium BANDWIDTH=100000;
hls_variant _low BANDWIDTH=40000;

Answer 1

I'm able to get it to work when I set both fragment and playlist length the same amount of time.
hls_fragment 2s;
hls_playlist_length 2s;
above is the lowest you can achieve while having to transcode which is about ~5-6 seconds latency while transcode is about ~13 seconds.
It still not recommended as it can causes some issues