engine state transition WAITING_LEVEL to IDLE and vice versa infinite loop #769
Comments
|
that's weird. could you reproduce and repost logs with timestamps or PM me this live stream URL ? you can find my email in git history. |
|
Ok, it is a bit complicated since the stream is a "concatenation" from different sources. To be more clear, imagine a TV broadcast transmission. I publish in the same stream from different sources switching among them. During this switch there is always several seconds in which the chuncklist does not change among subsequent requests because I stop the first source and the I start the second source so as I do not overlap the transmission. So, between the two sources can occur a sort of hole. I guess this hole is the reason why sometimes the player stuck between that two states. Anyway I can PM you a live stream performing switches on realtime so as you can test it. Let me know when you are available to test it. |
|
just ensure that it will be setup tomorrow morning around 9AM UTC+1 and i will have a quick look |
|
Hello @mangui, sorry for the late, but it taken me some time to set up the test environment. I sent you a PM with the url of the streaming to test. Let me know when you are on it so as I can start per form switches in order to reproduce the issue. |
|
@mangui I need to stop the live stream. |
|
I was not able to reproduce the toggling between however I fixed a parsing issue (NaN reported) I am trying to understand why |
in case this quality level is already being loaded, playlist-loader will keep the ongoing request running related to #769
|
@simonemazzoni plz recheck against hls.js/master or latest demo page |
|
@mangui I experienced also the [NaN,Nan] parsing issue from time to time. Thanks for fixing it. About the original issue, I made few tests and it looks likes the issue is still present. I can perform more tests and give you the logs. |
|
for timestamps, plz tick the related option in 'developer tools option" in chrome |
|
Good, I'll do more tests tomorrow in the morning. I'll let you know as soon as I got some results. |
|
Hello @mangui, Sometimes on my stream, the player fires a and the player remain stuck. I don't know exactly what I'll attach a log of the console with timestamps. |
|
Hello @simonemazzoni |
|
Hello @mangui, I never get the two states looping issue, but I get again the sourceBuffer error. Here the new log with timestamps. |
|
Hello @simonemazzoni I checked your logs and I can see that the first sourceBuffer error happens on a TS fragment which does not seem to contain any audio see I am suspecting something wrong in https://github.com/dailymotion/hls.js/blob/master/src/remux/mp4-remuxer.js#L601-L635 |
|
Hello @mangui, Anyway I can confirm that sometimes the stream starts sending fragments without audio data. This happen because of my algorithm to address lip synchronization between audio and video source. |
|
Hello @mangui, I got two times in a row these errors: This time no "SourceBufferError" was fired, but the result is the same since the loading and the playback got stuck. I'll attach the two relatives logs with timestamps. playback_abort_corruption.txt |
|
Performed same test right now, and "sourceBuffer" error came back. |
|
I realized right now that you asked me to post also chrome://media-internals log. Here the console log of another test + media-internals log. sourceBuffer_error_noautorecover2_media-internals_log.txt FYI: I noticed that the player is more likely to get stuck if it has none or small buffer upfront to play. If I, for example, pause the playback for a while and wait the player to load before play again, the error is less likely to happen. I guess it is a consequence of the fact that the player got stuck when there are "discontinuities" in the stream (thing that happen every time I switch the source of the stream). |
|
there seems to be an issue while appending empty audio moof chrome media internals investigating why ... |
|
as chrome debug message is cryptic, I would need an access to the stream to debug |
|
Hello @mangui , |
|
hello @mangui , I'll wait your response. |
|
Hello, please PM me the link, i can check now |
|
@mangui sent you an email right now. |
fix sourcebuffer append error on empty audio moof: when audio PID is removed from PMT, track.id was reset to -1, leading to invalid track_id being set in tfhd box track.id needs to be persisted. related to #769
|
I was having an issue with similar errors today. Unfortunately I can not supply a sample/test. |
|
Hello @mangui, making more endurance tests this morning. Here the console output with timestamps. These are the errors I found in console. Notice that the fragment loading continues after this error, but the playback is broken and can't be resumed. Only way is to restart the player. |
|
in order to investigate, best is to disable auto recover, |
|
Ok, I'll make another test and post here console and media internals logs. FYI: same error after a while but this time, since I have "auto-recover" option enabled, it recovered itself. |
|
@mangui append_with_media_error_media-internals2.txt Let me know if you find something. |
|
@simonemazzoni regarding your latest media errors, it is about drifting audio timestamps.
76ms timestamp gap after 43mn is not that bad after all :) |
|
Hello @mangui, I understand. Just to be sure, what error event should I listen to intercept this error and call recoverMediaError()? |
|
you should listen to HTMLMediaElement error |
|
Ok, basically it fires a generic error, so my logic should be just fine as it is. I'll check future releases in case you decide to solve this error. Thanks a lot. Also it isn't related to this issue but, why don't you update the chrome/firefox extension with new hls.js version? I updated it in my local machine, but should be nice to update also the official extension. It is very useful to perform on-the-go tests. |
|
chrome extension is updated by @gramk |
|
this extension now also supports Firefox (as Firefox now supports WebExtensions) |
|
As far as I can see, it uses "hls.0.5.49.min.js" which is an old version. |
|
@simonemazzoni I usually update the extension after some playback testing of my own, lots of people are using the extension day to day. But I am thinking of adding a switch so people can just pick the version they want. |
|
@gramk good to know! |
|
@simonemazzoni Just updated the extension: there is now a settings to switch between the two last version and a checkbox to enable debug mode. I hope that helps! |
|
@gramk Great! |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Environment
Steps to reproduce
When I play a playlist.m3u8 file generated by my Wowza Streaming Engine server.
Sometimes the engine tries to switch level, but the it start looping between the two states IDLE and WAITING.
These two log messages are printed out forever.
If I manually change the quality/level the engine flush the buffer and restart the loading and all works again, but I have to do it manually. Previous versions do not have this problem.
Expected behavior
I expect the playback self switch the level and tries to recover automatically or something similar.
Actual behavior
The playback is stucked.
Console output
The text was updated successfully, but these errors were encountered: