Feature-Request: http source support range

[dazzypark]

Hi, first of all thank you so much for maintaining this project!

I noticed that when playing a long audio file (e.g. a 12-hour track around 1GB in size) from an HTTP source, the entire file seems to be loaded into memory at once. This results in about 1GB of memory usage, which could potentially lead to memory leaks or high memory pressure over time.

If possible, I’d like to suggest supporting HTTP range requests for such sources, so that audio data can be loaded in smaller chunks rather than all at once. I think this might help with overall resource efficiency.

Thanks again for all your hard work!

[devoxin]

Lavaplayer already utilises the range header (I have an API endpoint that works with it so I can attest to this behaviour.)

It is also atypical for Lavaplayer to buffer the entire file in memory—it is designed to keep memory usage to a minimum and implements buffers for this very reason. It will read audio frames from a track until the internal audio frame buffer is full (which defaults to about 5 seconds worth of audio.) If its using uncontrolled amounts of memory, this may be because you have your buffer values set too large.

[dazzypark]

In my tests using Lavalink 4.1.1 (which includes Lavaplayer 2.2.3) with an HTTP source, playing a 400 MB audio file resulted in approximately a 400 MB increase in system RAM usage

test result video: https://youtu.be/ST3vNf_7uWQ?si=doz9PA4n4t59cxQ6
test audio url: https://cdn.discordapp.com/attachments/1200846195074015263/1381617283515940914/2025_6_4_1_X__KPOP_rms_xJeLLJo.opus?ex=68482add&is=6846d95d&hm=d6a04b61350afcfad1f8776272df25c990b8f7ed1babe1097d4c9813f500aa33&

[dazzypark]

java -Xmx2G -jar Lavalink.jar

[dazzypark]

I tried 'java -Xmx256M -jar Lavalink.jar' but when I play it I get an error 'Exception in thread "lava-daemon-pool-playback-1-thread-1" java.lang.OutOfMemoryError: Java heap space.'

[devoxin]

Yes, too small of a heap and Lavalink won't play nice. Unless the JVM is showing signs of memory leaking over a given timespan (uncontrolled memory usage leading to an OOM error) then I don't believe this is an issue and just how the JVM works. You allocate it memory, so it will use that memory. It jumping up by 400MB isn't cause for concern unless there is undesirable behaviour stemming from this memory usage.

[dazzypark]

If multiple users are playing simultaneously—even if each track consumes only about 3 MB of RAM—just 700 players would quickly exceed 2 GB of memory. This often causes Lavalink to shut down due to OOM (Out-of-memory).

I’ve observed that lavaplayer does use HTTP range requests in certain cases, like when a track is interrupted and replayed or when seeking. In those scenarios, it smartly doesn’t re-download previously fetched segments.

That behavior is very helpful, but currently Lavalink still downloads the entire track by default. I’d like to propose a more granular streaming approach:
• Rather than preloading the full track from the start, lavaplayer could download only the next few KB or MB (based on playback buffer needs).
• Then, as playback continues, additional segments could be fetched on-the-fly using HTTP Range requests.

This incremental loading approach could significantly reduce peak memory usage, improve GC efficiency, and lower the risk of memory-related crashes under high load.

Thanks for considering this enhancement! I’d be happy to help test or contribute to a patch that implements it.

[devoxin]

Please actually test this because I don't think you completely understand how JVM memory usage and GC works. GC doesn't always run eagerly so it won't immediately reclaim memory that is "unused". Climbing memory usage is expected, garbage collection which then drops that memory usage is expected. Unless you have experienced first-hand an OOM caused by this memory usage then there is no issue. I have not seen any cases where Lavalink/Lavaplayer is leaking memory and I've run, and managed, a variety of bots and nodes.