Open cgrozev opened 6 years ago
Did you find the cause of this? I am observing something similar.
Unfortunately not yet.....Now debugging line by line, both server and player side..
see if you have any ID3 tags in the file and remove it for a test.
karl
On Icecast docs, I read that fallback to file can cause issues: https://icecast.org/docs/icecast-2.4.1/config-file.html#mountsettings So, on my network changed the fallback to be a stream and it seems more stable since.
I can confirm for file based fallback, ID3 tags will disconnect clients. When I stripped all ID3 tags, fallback worked as expected. Tested with 2.4.0-kh15 and Chrome 85.0.4183.121 (Official Build) (64-bit)
Hi. I experience an issue with switch-over to fallback (in my case, to mp3 file) when the listener is a browser based player in Chrome and Opera, as well as any mobile browser. The player just disconnects during the switch to fallback, and must be restarted to continue. This issue is not present in Firefox or IE/Edge browsers, nor on VLC and other non-browser based players. The issue does not seem to depend on the limit-rate setting; i.e. it appears with or without the (correct/matching) limit-rate setting in the xml file.
To try to diagnose, I recorded the switch-over moment using a raw curl command. It created a continuous mp3 file, obviously with a new header at the time of "splicing". I then played this file in a Chrome browser to see if it will disconnect at the splice moment, but it played it without a problem. Thus it doesn't seem to be the new headers or partial frames at the moment of switch-over.
Any idea what the cause of this issue may be?
Best regards Christo