-
Notifications
You must be signed in to change notification settings - Fork 54
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
Comments
if you use LavaSrc with Lavaplayer directly (not as a lavalink plugin) you can implement your own tldr: in theory yes, but someone would need to pr this |
Gotcha. In the meantime, #73 could be a very useful thing to prioritize so this issue can be handled on the consumer side. |
that issue has nothing to do with this issue. |
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? |
Yes that info would be exposed once the track is actually playing |
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 |
Well, you could always resolve the track on your side in the client & just not use Spotify & apple music from LavaSrc |
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! |
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.
The text was updated successfully, but these errors were encountered: