There was a library in JS that offered encoding tracks if all of the details were known, but this library isn't up to date for the new track format. I may have also hallucinated that there used to be an endpoint for encoding the track without calling /loadtracks, but I can't find it in the API docs. My use case is that I proxy google video track loading and I don't want /loadtracks to attempt to load info from the http source when I send it the google video URI. Is there a way to bypass this or can an API route be added?
#Encoding a track if all of the details are known without calling /loadtracks
1 messages · Page 1 of 1 (latest)
There are no plans to add such an endpoint.
The player update endpoint accepts an identifier which needs to resolve to a track. Use that to load songs from links
Doesnt that internally go the same route as /loadtracks?
If you say it's fine that lavalink requests the googlevideo url multiple times then I guess it's fine
Yes
I've had some problems with the initial request to a /videoplayback url not wanting to accept subsequent requests if a range parameter was missing
so make sure to supply one
Can you elaborate?
on what lol
so like on the url just append an &range=?????
google video servers will refuse the connection if the initial request does not contain a range parameter
if it doesn't exist, yes
&range=0-{content length}
oh yeah
your seeking will be fucked because yt uses this parameter instead of a range header
Well here's where I am captial f fucked. If I load tracks the google video url and then lavalink encodes that then doesnt do that for me when it decodes it on its end
you should write a plugin to do this stuff for you
well then your only wya is to wirte a plugin lol
too slow topi
and to play them
Well. That I'll get to when I care
I also make use of isSeekable in my client so I can just disabled that for the time being
(and probably never do anything about it)
Was gonna correct you on that
yes
the music is fine
the experience is fuck you YouTube I'm happy it works at all
Why not just adapt https://www.npmjs.com/package/lavaplayer-track-info to accept the additional information?
be far easier than making a plugin i think
that won't fix seeking
h
this is what I'm responding to
ah
but anyway, as I was typing:
writeUTF(title) // track info v1
writeUTF(author) // track info v1
writeLong(length) // track info v1
writeUTF(identifier) // track info v1
writeBoolean(isStream) // track info v1
writeNullableUTF(uri) // track info v2
writeNullableUTF(artworkUrl) // track info v3
writeNullableUTF(isrc) // track info v3
writeUTF(sourceName) // track info v1
// this part is reserved for source-specific data.
// a source manager can write anything it needs to store
// however what is encoded here MUST be decodable by the respective
// source manager (which source manager is used for decoding is
// defined by the sourceName field)
// Both LocalAudioSourceManager and HttpAudioSourceManager encode a
// probe info field, which is just the stream format (i.e. mp3).
// Most source managers don't need to encode anything here.
writeLong(trackPosition) // track info v1, `0` denotes beginning
// N.B. writeNullableUTF first writes a boolean (true if exists/not null) and then UTF text if boolean is true, otherwise just `false` is written and nothing more.
Theres a more up to date fork I contributed to a few times so I guess I could, but I'd have preferred the node to do the encoding so that I don't have to worry about shit like if the format ever updates like it did when plugins were added and again for v4
I am pretty sure the format didn't change when plugins were added
and yes the format changed when v4 dropped, one of the reasons we pushed v4
Did isrc, artworkUrl and pluginData all get added at the same time?
isrc & artwork got added with v4
what you call pluginData was always there
aka source specific fields
no, that would have been considered a breaking change and required lavalink v4
we would have stayed on v3 if we didn't add isrc & artwork url
v3.7 came with a new rest api, but that was not breaking in any way
some libraries "broke" because they errored on unknown websocket ops
but additions are not considered breaking
I now realized I am mixing in stuff from my own LavaLink server software
I'll just contribute to the library then 👍
the reason why we also say that encoding your own tracks is unsupported is because it's complicated, we don't want to deal with people fucking up internals and then crying for help
so if you encode custom tracks you are usually on your own, we don't want to deal with that
you also need to provide the probe info for http tracks
writing a plugin for this would be pretty simple
(a custom source manager)
And that's totally reasonable, just I think there can be safe guards from that kind of thing at least if you guys implemented it like if for example fields are declared required by certain sources and then just 400 if they're not present. Perhaps also give plugins the ability to capture their specific fields and see if the values are legal
I don't think something like this would be breaking either
if we provide docs, we support it
and people will use it
if you want to skip the /loadtracks endpoint just use the identifier field in the player update endpoint, that's why it exists
I do have some plans regarding encoded tracks in v5
Would you be willing to disclose such plans? 👀
I've already talked about those in #lavalink-dev
but basically just get rid of it and send json objects around
¯_(ツ)_/¯
we already send the json objects in every event anyway
What was the whole point of encoded tracks anyways
so point in even having this fucked up fragile format in the first place
encoded tracks were never supposed to be used like they are now, they were used to send tracks across lavaplayer nodes
it's just a binary format to be more efficient, it would have been an internal detail in lavaplayer
but got exposed in lavalink, but the format is a pita to work with if you don't know what fields could be there
I am personally all for json tracks, just PATCH session might be tricky since some source managers could only need 1 field while others need all
/loadtracks will return all the fields needed
so you can see what is inside there
¯_(ツ)_/¯
Right but currently PATCH session is as simple as pass a track or identifier
LoadType: track
{
"encoded": "QAAB+gMABURhbnRlAAlOb3J0aGxhbmUAAAAAAAVItgAWNmpqeDFLdldLNE9BekQwSmltekhpWQABADVodHRwczovL29wZW4uc3BvdGlmeS5jb20vdHJhY2svNmpqeDFLdldLNE9BekQwSmltekhpWQEAQGh0dHBzOi8vaS5zY2RuLmNvL2ltYWdlL2FiNjc2MTZkMDAwMGIyNzNhYTY4MWI2ZTgxNmYzMmI0NTQwMGU4NTMBAAxER0EwSDIzOTgxMTkAB3Nwb3RpZnkBAAVEYW50ZQEANWh0dHBzOi8vb3Blbi5zcG90aWZ5LmNvbS9hbGJ1bS81QkM1OFZUVWY0YWFvR1Zramh0eDlVAQA2aHR0cHM6Ly9vcGVuLnNwb3RpZnkuY29tL2FydGlzdC8zcXlnNzJSR25HZEY1MjF6TVUwMnU5AQBAaHR0cHM6Ly9pLnNjZG4uY28vaW1hZ2UvYWI2NzYxNjEwMDAwZTVlYmQ5Yzg2N2RjY2Q4ZDI4ZjA4MjA5MGFjOAEAa2h0dHBzOi8vcC5zY2RuLmNvL21wMy1wcmV2aWV3LzgyZTA2NmI1ZTk0YTk0ZWYzM2YzNmM4YmEzNDExYjkzODE4OWFjNjE/Y2lkPWY4MTUxODhkOTQ2ZDRlNDNiYjI0ZmJlZmE5NDhmOGQ2AAAAAAAAAAAA",
"info": {
"identifier": "6jjx1KvWK4OAzD0JimzHiY",
"author": "Northlane",
"length": 346294,
"isStream": false,
"title": "Dante",
"uri": "https://open.spotify.com/track/6jjx1KvWK4OAzD0JimzHiY",
"sourceName": "spotify",
"position": 0,
"artworkUrl": "https://i.scdn.co/image/ab67616d0000b273aa681b6e816f32b45400e853",
"isrc": "DGA0H2398119"
},
"pluginInfo": {
"save_uri": "https://open.spotify.com/track/6jjx1KvWK4OAzD0JimzHiY",
"artistUrl": "https://open.spotify.com/artist/3qyg72RGnGdF521zMU02u9",
"previewUrl": "https://p.scdn.co/mp3-preview/82e066b5e94a94ef33f36c8ba3411b938189ac61?cid=f815188d946d4e43bb24fbefa948f8d6",
"isPreview": false,
"albumName": "Dante",
"artistArtworkUrl": "https://i.scdn.co/image/ab6761610000e5ebd9c867dccd8d28f082090ac8",
"albumUrl": "https://open.spotify.com/album/5BC58VTUf4aaoGVkjhtx9U"
},
"userData": {}
}
suck as this
minus the encoded I guess
encoded no more
possibly some of these fields different too
author -> authors
and no position
idk why this is in the encoded track to begin with
Did LL used to manage its own queue
never
Perhaps that was the plan?
why?
What else would position be used for?
Oh wait the read head
no a queue position
also some semi standardized additional fields would be nice
such as what I use in lavasrc

same with playlists
well i can add yes
v5 when
but i can't remove/change
for v5 there needs to be major rewrites in lavaplayer internals
there are some additional features some people want which require breaking lavaplayer changes too
Heard it's a mess at best so fair enough
rarely do I get excited for dev stuff :(
i'll write a lavalink server using my stuff for you
Thought you were making your own node with a totally separate api

I've written a relay before
Well. I've been waiting all this time for the shit you've been working on. Always gaslighting me about how shit my efforts were on Volcano. Public releases when
💀
Ever since you joined the Amanda discord!
nuh uh
instead of putting your efforts in Volcano and other stuff, put them into learning java & kotlin
🧠
oh v5 might also ship without any sources :)
Is uh. That a meme
no
krypton moment
all sources in plugins
I mean install what you want, sure. Could reduce memory footprint and cpu time spent on if a source manager can load an identifier
why then

Oh sources separated from LL releases
same reason as why yt is it's own thing now
I see. Smart
less painful for us
Are the other sources like in need of work though
besides the fact they make use of encoded tracks
wait nicovideo fr died?
GitHub
Niconico has completely shut down the old video delivery server (DMC) and completely migrated to the new video delivery system called DMS: https://blog.nicovideo.jp/niconews/205042.html This has re...
Well
Largely I just wanted to rewrite it and didn't know if I'd need to do any breaking changes
Much easier to tell people to switch to something at their own discretion than force a breaking change warranting a new major LP version


