-
Notifications
You must be signed in to change notification settings - Fork 790
feat: Basic local file support #1595
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
feat: Basic local file support #1595
Conversation
9f8be59 to
d0efe21
Compare
photovoltex
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review. Overall looks good to me, for the audio part I would like to have @roderickvd opinion about it (mainly symphonia and the player itself). From my point of view it seems to do the job but I might miss some crucial details.
2888930 to
961e2f4
Compare
|
Wait, if the tracks that will be found in the path added by |
Each device will have its own Local Files playlist based on what folders have been configured. I don't think we can get a list of sources from Spotify since a connect play request could come from an entirely different device. Even if there is file path information in the request, it may not be valid on the current device. In terms of live-updating the local file content, maybe we could use something like https://github.com/notify-rs/notify to update the lookup in the background, or only update it if we get a request to play a file we fail to find a path for. |
|
@roderickvd @photovoltex thanks for all the reviews so far, I was just wondering if you had any more feedback? I may make a start on adding some of the extra functionality in subsequent PRs, namely lifting the sample rate restriction and making the local files playlist work. Would you like me to create issues for these tasks? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long wait. From my point of view we could probably merge this.
Should we update some documentation or how to use the feature? Or is it maybe enough to link to some general instructions from spotify how it's supposed to work?
It would probably be great to still get this into the next release as this still contains breaking changes.
Spotify Connect does not allow you to move playback of a local file to the librespot device as it says that it "can't play this track". Note that this is slightly inconsistent as Spotify allows you to switch to a local file if librespot is already playing a non-local file, which currently fails with an error. However, it is possible for the desktop and iOS client to accept playback of local files. In looking at the PUT request sent to `connect-state/v1/devices/<id>` from the iOS client, it can be seen that it includes `audio/local` as an entry in the `supported_types` capability field. This commit introduces this field to the capabilities that librespot sends. For now, it is a complete lie as we do not support local file playback, but it will make the ongoing development of this feature easier, as we will not have to queue up a non-local track and attempt to switch to a local one. Testing shows that with this flag the "can't play this track" message disappears and allows librespot to (attempt) to play a local file before erroring out.
f9d9b15 to
754ca4f
Compare
|
I have squashed all my smaller commits so I didn't have to fix merge conflicts with the changelog across multiple commits. |
I'd be happy to do this, would the wiki be the best place? I get the impression the |
|
Yeah, the wiki is probably the right place. Probably adding it to the options section and then explaining it a bit in detail further below will do the job.
|
|
I have updated this page on the wiki with the new option and some brief usage instructions: https://github.com/librespot-org/librespot/wiki/Options#local-files |
|
Looks good. Let's get this merged then :D |
|
Thanks for the addition and sorry for the long wait on resolving the topic^^; |
|
Thanks @photovoltex and @roderickvd for your help 😄 Not to worry about the wait, I recognise this is just a thing you guys do in your spare time and it's the same for me. I will probably work on the sample rate issue next, so that all local files can be played. It could be quite tricky to get it working across all the backends though. |
Discussed in #1525. Adds a basic level of support for playing back local files from a connect device. The
librespotbinary must be launched with--local-file-dir/-lflags specifying search paths for local files. If a request is received to play a local file, and a file match is made based on the file's artist, album, track title, and duration, thenlibrespotwill now be able to play it.This support has the following caveats:
spotify:local-fileswhich currently causes an error in the context handling code, aslibrespotattempts to fetch it from the API and appears to get a 404. I tried to make this work, but it feels like an abstraction for context would be beneficial so we could generate context from the filesystem (currently I think we use the proto models which are obviously tightly coupled to the Spotify API). Also, I do not understand enough about the context handling code to do a good job 😅