Open Nick6489 opened 4 years ago
Do you have the level 4 error log to show this?
karl.
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
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
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
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
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
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?
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
Thank you very much...Just to make sure I understand this, the file name should be fallback-192].mp3?
yes, well /fallback-[192].mp3 as an example
karl
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.
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.