Changelog¶
Each release usually includes various fixes and improvements. The most noteworthy of these, as well as any features and breaking changes, are listed here.
Significant changes¶
v3.7.0 -> v4.0.0
- removed all non version
/v3
or/v4
endpoints (except/version
). /v4/websocket
does not accept any messages anymore.v4
uses thesessionId
instead of theresumeKey
for resuming.v4
now returns the tracksartworkUrl
andisrc
if the source supports it.- removal of deprecated json fields like
track
. - addition of
artworkUrl
andisrc
fields to the Track Info object. - addition of the full Track object in TrackStartEvent, TrackEndEvent, TrackExceptionEvent and TrackStuckEvent.
- updated capitalization of Track End Reason and Severity
- reworked Load Result object
All websocket ops are removed as of v4.0.0
and replaced with the following endpoints and json fields:
play
-> Update Player EndpointencodedTrack
oridentifier
fieldstop
-> Update Player EndpointencodedTrack
field withnull
pause
-> Update Player Endpointpause
fieldseek
-> Update Player Endpointposition
fieldvolume
-> Update Player Endpointvolume
fieldfilters
-> Update Player Endpointfilters
fielddestroy
-> Destroy Player EndpointvoiceUpdate
-> Update Player Endpointvoice
fieldconfigureResuming
-> Update Session Endpoint
v3.6.0 -> v3.7.0
- Moved HTTP endpoints under the new
/v3
path with/version
as the only exception. - Deprecation of the old HTTP paths.
- WebSocket handshakes should be done with
/v3/websocket
. Handshakes on/
are now deprecated. - Deprecation of all client-to-server messages (play, stop, pause, seek, volume, filters, destroy, voiceUpdate & configureResuming).
- Addition of REST endpoints intended to replace client requests.
- Addition of new WebSocket dispatch Ready OP to get
sessionId
andresume
status. - Addition of new Session/Player REST API.
- Addition of
/v3/info
, replaces/plugins
. - Deprecation of
Track.track
in existing endpoints. UseTrack.encoded
instead. - Deprecation of
TrackXEvent.track
in WebSocket dispatches. UseTrackXEvent.encodedTrack
instead. - Player now has a
state
field which contains the same structure as returned by theplayerUpdate
OP.
All websocket ops are deprecated as of v3.7.0
and replaced with the following endpoints and json fields:
play
-> Update Player Endpointtrack
oridentifier
fieldstop
-> Update Player Endpointtrack
field withnull
pause
-> Update Player Endpointpause
fieldseek
-> Update Player Endpointposition
fieldvolume
-> Update Player Endpointvolume
fieldfilters
-> Update Player Endpointfilters
fielddestroy
-> Destroy Player EndpointvoiceUpdate
-> Update Player Endpointvoice
fieldconfigureResuming
-> Update Session Endpoint
v3.3 -> v3.4
- Added filters
- The
error
string on theTrackExceptionEvent
has been deprecated and replaced by the Exception object following the same structure as theLOAD_FAILED
error on/loadtracks
. - Added the
connected
boolean to player updates. - Added source name to REST api track objects
- Clients are now requested to make their name known during handshake
v2.0 -> v3.0
- The response of
/loadtracks
has been completely changed (again since the initial v3.0 pre-release). - Lavalink v3.0 now reports its version as a handshake response header.
Lavalink-Major-Version
has a value of3
for v3.0 only. It's missing for any older version.
v1.3 -> v2.0
With the release of v2.0 many unnecessary ops were removed:
connect
disconnect
validationRes
isConnectedRes
validationReq
isConnectedReq
sendWS
With Lavalink 1.x the server had the responsibility of handling Discord VOICE_SERVER_UPDATE
s as well as its own internal ratelimiting.
This remote handling makes things unnecessarily complicated and adds a lot og points where things could go wrong.
One problem we noticed is that since JDA is unaware of ratelimits on the bot's gateway connection, it would keep adding
to the ratelimit queue to the gateway. With this update this is now the responsibility of the Lavalink client or the
Discord client.
A voice connection is now initiated by forwarding a voiceUpdate
(VOICE_SERVER_UPDATE) to the server. When you want to
disconnect or move to a different voice channel you must send Discord a new VOICE_STATE_UPDATE. If you want to move your
connection to a new Lavalink server you can simply send the VOICE_SERVER_UPDATE to the new node, and the other node
will be disconnected by Discord.
Depending on your Discord library, it may be possible to take advantage of the library's OP 4 handling. For instance, the JDA client takes advantage of JDA's websocket write thread to send OP 4s for connects, disconnects and reconnects.