-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HLS - Stream isn't playing when first TS segments fail #354
Comments
@shaharmor plz share a debug/debug2 logs so that i can check |
Also havingAlso having this issue. Here's my debug: proxy url is api/stream-chunks/http%3A%2F%2Fvideo-edge-512170.jfk01.hls.ttvnw.net%2Fhls123%2Fgsl_16167258656_299361921%2Faudio_only%2Fpy-index-live.m3u8%3Ftoken%3Did%3D343522186349410454%2Cbid%3D16167258656%2Cexp%3D1441460522%2Cnode%3Dvideo-edge-512170-1.jfk01.hls.justin.tv%2Cnname%3Dvideo-edge-512170.jfk01%2Cfmt%3Daudio_only%26sig%3D66be019710f5076ac917861b0ad1eb80ac6b2c6b DEBUG:updateFragments: unknown PTS info for this level DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:4064/16031405 |
mmm, with
errors are raised at first I/O error, as explained in the doc |
Yes, I don't want my stream to retry if it fails to retrieve a segment; I would prefer if it tried the next one immediately. Is there any way to do this? I'll try it with the default options and see how it goes. |
could you share a debug log from start ? |
VM5448:1 INFO:HLSSettings.logDebug2 = true VM5456:1 DEBUG:updateFragments: unknown PTS info for this level VM5574:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5093/20271472 VM5795:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6621:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6678:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6740:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6780:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6797:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6815:1 DEBUG:updateFragments: found PTS info from previous playlist,seqnum/PTS:5096/20283383 VM6834:1 DEBUG:updateFragments: unknown PTS info for this level VM6851:1 DEBUG:updateFragments: unknown PTS info for this level VM6869:1 DEBUG:updateFragments: unknown PTS info for this level VM6887:1 DEBUG:updateFragments: unknown PTS info for this level VM6905:1 DEBUG:updateFragments: unknown PTS info for this level VM6923:1 DEBUG:updateFragments: unknown PTS info for this level VM6941:1 DEBUG:updateFragments: unknown PTS info for this level VM6959:1 DEBUG:updateFragments: unknown PTS info for this level VM6977:1 DEBUG:updateFragments: unknown PTS info for this level VM6995:1 DEBUG:updateFragments: unknown PTS info for this level VM7013:1 DEBUG:updateFragments: unknown PTS info for this level |
I am suspecting TS demuxing stalled (hence Fragment Loading) because of corrupted TS fragment received :
most probably flashls is ending up here, |
Is there anything I can do to handle/avoid this error? I was working towards returning a 40* status code from my endpoint (hoping flashls would see this and know to request a new segment instead of trying to read a bad segment), but according to the original poster this still triggers the behavior. |
I think the root cause of the error is when a fragment load returns with CONTENT_LENGTH_MISMATCH. I'll be tackling the issue on my end but is there any way you can handle this like an null fragment (i.e. it just skips to the next) |
I am also seeing a frequent ERR_CONTENT_LENGTH_MISMATCH in a significant portion of my streams which proceed to fail. @johnBartos did you find a root cause for when you were seeing it? |
Yes, the issue was that I wasn't sending the agreed upon amount of data to flashls. I was doing this because I had set a timeout on requests made to my chunk endpoint - sometimes, the endpoint would trip the timeout and chop the stream short. I solved this by writing my stream chunk to a buffer first and only sending the data in the case that the request succeeds before the timeout, ensuring the chunk is whole. If you're using Node, this will probably be helpful: https://github.com/johnBartos/RadioFreeTwitch/blob/master/server/api/chunk-proxy/chunk-proxy.controller.js |
Hi,
If the first few segments fail (Due to 404 for example), once the next TS's do get fetched, the player doesn't start playing them.
If it happens in the middle of a stream, there is another issue that once the TS's are fetched again, the player doesn't request any more TS's, however it does request m3u8 files.
The text was updated successfully, but these errors were encountered: