Re: playing remote files

[Yoni Rabkin]

Grant Shangreaux <grant@churls.world> writes:

> hello all!
>
> i've got a media library on a remote machine being served with
> supysonic, which implements the subsonic api. i don't really know how it
> works, or if making emms a subsonic client is worth the trouble.

If subsonic is a proprietary server (which I think it indeed is), I see
no point in supporting it. However, if airsonic (GPLv3 apparently) is
still a thing: https://airsonic.github.io/ ...then I see no reason why
someone who enjoys running an airsonic server wouldn't write
emms-airsonic.el, and we could integrate that.

> however, i discovered that i can use `emms-add-directory` and Tramp to
> add remote files to my playlist and that `mpv` knows how to play sftp
> uris. the trouble is, the Tramp filename syntax is not a uri.
>
> i've been thinking about different ways to go about this. i could
> manually create a playlist of sftp uris for the media, but that throws
> out the nice synergy of EMMS and Tramp working together. i could hack
> into `emms-add-directory` to detect the /sftp: Tramp syntax and then
> add the tracks as url types, transforming the Tramp path to a
> uri. This has the downside of missing out on the file type
> metadata. The Tramp filename actually allows me to use the tag editor
> to operate on remote files, which is a bonus. This leads me to think
> of a third option, which is to hack into the player side of things and
> transform the Tramp path into a uri to pass as an argument instead of
> a filename. I'm not sure how general it is, and how many players
> support it though. Which brings me to thinking a new *track* type
> might be appropriate?
>
> Any thoughts? Is this work worth doing? It seems like it might be more
> conventional to figure out how to set up `mpd` on the remote and just
> use EMMS's interface to that.

I have no problem with adding a "tramp" track type to more fully support
playing and playlist manipulation over such a source.

However, why not just mount the remote directory as a local one (SSHFS,
fuse, etc.) and avoid the entire debacle?

-- 
   "Cut your own wood and it will warm you twice"