Closed maxall41 closed 1 year ago
Whenever I saw something like this in testing, it tended to be because I'd been served a page body or other HTTP response instead of valid audio data. What website are you making requests to? What codecs do you have enabled?
The funny thing is I'm using the exact same file served from the exact same URL between play requests. And it seems to happen intermittently. And I'm not changing anything between requests. The file I'm using is: https://www.ee.columbia.edu/~dpwe/sounds/music/africa-toto.wav. And the codecs I have enabled are:
symphonia = { version = "0.5.2", features = ['pcm','mp3','wav','isomp4','aac','alac'] }
I also made sure I'm not getting rate limited or anything
Update: This also seems to happen when seeking at a lower frequency. I think this may be due to the servers serving africa-toto.wav (the test file I'm using) seem to be straight out of the 90s and are limited to about 900kbs so maybe there is some sort of issue here when the server isn't keeping up on occasion or something. Because it only very rarely happens with other tracks.
I have been able to confirm that this issue is due to the server not being able to keep up. This also explains why the frequency goes up with more concurrent tracks of the same song served from the same server.
I just spun up 100 concurrent downloads of the file using request (77.9 Mbps) and then opened the URL in a web browser:
You are, in fact, being served an HTML document every once in a while, which can't be parsed as audio so the probing step fails. Status code is 520, which apparently means an unknown web server error in Cloudflare parlance. We should probably be checking Response::status
on our side, which is a simple enough change if you feel like adding it to src/input/sources/http.rs
.
Sure Il make a PR
Any chance we can get the status logged out via tracing
if the process exits with a status code other than 0?
@Skarlett That's a problem on current
, where development is practically frozen. next
does not call out to external processes.
Songbird version:
next
Rust version (
rustc -V
): 1.69Serenity/Twilight version:
next
branch serenityDescription: I'm getting intermittent symphonia
reached probe limit
errors on thenext
branch with about a 1/50 to a 1/5 chance of happening. It's a bit hard to tell because of the low sample size. It does seem to increase with more load (more concurrent streams). But its not a large load about 5 concurrent streams with 11% CPU Usage and only 30MB Memory usage. And i'm not entirely sure that is the case. Here is the log section when it happens:This happens when using the HttpRequest source. Though it may happen with others as I haven't tested any others.
Steps to reproduce:
Environment Arch: x86 OS: Ubuntu Linux System: 4 Core 8GB