Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to specify stricter matching/resolving requirements (spotify) #107

Open
lorenblue opened this issue Aug 24, 2023 · 8 comments
Open
Labels
enhancement New feature or request good first issue Good for newcomers up for grabs

Comments

@lorenblue
Copy link
Contributor

Hi!

Not sure exactly how the internals work with this plugin, but I am wondering if it's possible to tighten up what counts a track matched/found/resolved (whatever word you want to use) when inputting a Spotify link.

As an example, this spotify track ends up resolving to something that's usually 1 hr+, even though the duration of the actual requested track is a mere minute. In a case like this, would it not be nice to be able to check that the resolved audio is way longer than requested (and possibly has a different title, author, etc.), and then count that as a failed retrieval?

Sorry for the vague/non-technical description, but hopefully that makes sense.

@topi314
Copy link
Owner

topi314 commented Aug 25, 2023

if you use LavaSrc with Lavaplayer directly (not as a lavalink plugin) you can implement your own MirroringAudioTrackResolver. That doesn't work with plugins ofc, but there could be different default implementations for it which you could choose from when using LavaSrc as a plugin.

tldr: in theory yes, but someone would need to pr this

@topi314 topi314 added enhancement New feature or request good first issue Good for newcomers up for grabs labels Aug 25, 2023
@lorenblue
Copy link
Contributor Author

Gotcha. In the meantime, #73 could be a very useful thing to prioritize so this issue can be handled on the consumer side.

@topi314
Copy link
Owner

topi314 commented Aug 25, 2023

that issue has nothing to do with this issue.
All that pr is intended to do is tell you what underlaying track is being used when the spotify or apple music track is being played

@lorenblue
Copy link
Contributor Author

But if I know what underlaying track is being used, can't I just setup my own logic to determine whether it's close enough to my requirements? Or are you saying that the underlaying track info would be exposed too late (e.g. the track is already playing) to be able to do something about it?

@topi314
Copy link
Owner

topi314 commented Aug 25, 2023

Yes that info would be exposed once the track is actually playing

@lorenblue
Copy link
Contributor Author

lorenblue commented Aug 25, 2023

Fair enough, but I do still think it would allow for some degree of mismatch handling (or at least acknowledgement), where there is currently none

@topi314
Copy link
Owner

topi314 commented Aug 25, 2023

Well, you could always resolve the track on your side in the client & just not use Spotify & apple music from LavaSrc

@lorenblue
Copy link
Contributor Author

Hmm ya that could work. This does seem like quite the pickle overall - hopefully someone can jump in here and try to tackle this within Lavasrc (lavaplayer) with a pr as you said. Until then I'll stay tuned!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers up for grabs
Projects
None yet
Development

No branches or pull requests

2 participants