karlheyes / icecast-kh

KH branch of icecast
GNU General Public License v2.0
300 stars 107 forks source link

Fallbacks disconnect clients #308

Open Nick6489 opened 4 years ago

Nick6489 commented 4 years ago

In KH13, Whenever a stream disconnects, falling back to its fallback mount, the listener's audio stops. The same happens if the primary stream takes over, and it does not matter what format is being used.

karlheyes commented 4 years ago

Do you have the level 4 error log to show this?

karl.

Nick6489 commented 4 years ago

I had to recreate it, but I did do so. I unfortunately had to do it live fire, so the log is a little large. Pay attention to anything involving the /christmus mount, where I enduced the error to happen, but it would happen in any other mount as well. http://archives.tbrn.net/extras/unsortable/error.log

karlheyes commented 4 years ago

can you verify whether the fix in the master tree resolves this for you. I was not able to duplicate it but did see a possible cause which is now fixed.

karl

Nick6489 commented 4 years ago

Nope, it's still just as bad, possibly worse. Falback immediately disconnects, whereas you might, in the past, have gotten a burst of the fallback mount. Log is here. http://archives.tbrn.net/extras/unsortable/error1.log

karlheyes commented 4 years ago

looking at that log, it looks like the stream was not on long enough for an average rate to fully establish. It currently needs that for a fallback file and when that is missing then it does not bother to fallback. Needs at least 40 secs to establish. You can specify a limit-rate or use the [192] type syntax in the filename or just wait the 40 secs.

Annoyingly, what I want to do eventually is not actually move the listeners but swap the feed as that will be less complex and keeps listeners isolated from shared mounts.

karl

karlheyes commented 4 years ago

Just for reference, the issue in your first log is not the fallback per-se, but the override. It was bringing the listeners back onto the mount on source reconnect, but the lag check was tripping forcing the listener off.

karl

Nick6489 commented 4 years ago

OK, I'll put KH back on the system and check it in real conditions.

Along a similar line, mainline Icecast will redirect to a fallback file if someone connects to a stream that isn't there. KH doesn't seem to do this, it only redirects when the fallback is a stream?

karlheyes commented 4 years ago

It's for the same reason. If you specify a limit-rate, bitrate or name the file with the [xxx] syntax then it will do that.

karl

Nick6489 commented 4 years ago

Thank you very much...Just to make sure I understand this, the file name should be fallback-192].mp3?

karlheyes commented 4 years ago

yes, well /fallback-[192].mp3 as an example

karl

Nick6489 commented 4 years ago

This appears to have been fixed. I will wait a week to see if any of my usual listeners report issues before I close this bug.