Possibility for immediate playback after download/update

[rominator1983]

It would be nice to have an option in the search result list to immediately begin playback after download. That is to say, what is the point of the download if not to play it back at some time.

I played around with a popular download program that returned a stream URL that could be added to mpd but unfortunately that option got broken by a popular video platform quite some time ago for streams that are longer than only some minutes.

I was thinking about adding a new button in the search result list next to the existing download button to handle that.

There are some caveats to overcome to accomplish that.
The download of the file happens on the server side while mpd communication is happening through the browser over the ws2mpd bridge. That means that after an accomplished download the client triggers the mpd update with the download folder.
Of course this might take some time and there is no way to check if that has finished successfully and added the downloaded file. Second the destination of the download is not transported to the client at the moment so the client cannot add the file to the queue.

The download handler on the server side streams the console output to the client so there is no structured data communication going on here.

As I see it, this leaves us basically with two architectural options (ugliest first to cancel them out quickly so pleeeaaaase read to the end):

• Add some logic to the server to talk to mpd to be able to add the file after the update (of course there must be some wait and/or looping for the add to be reliable. This is of course a break in the architecture of the entire application and I would see why one would not want that.
• Add some option to hand over the generated filename back to the client. Then the client could (after some waiting for the update) add the file by calling addid on mpd and playing the title by calling playid.
  The means of giving back the filename are a different story since the download endpoint streams the results back to the client at the moment. 3 options come to my mind (again, ugliest first):
  • Talking to another additional endpoint to get the filename would introduce state on the server.
  • Giving the filename back as an HTTP header might work but at that point in time the HTTP response body has of course already been written mostly and from what I know and confirmed by a quick google search, things go downhill quickly when trying to attempt that at all.
  • Giving something back in the stream by some convention would also not be my first choice but probably work best from a reliability standpoint. The server could write some magic string in the output like CYP_WRITTENFILENAME: and the client could interpret that, read the file name from the response and add that to mpd (after waiting for the update).

So I am thinking about a PR for that but don't want to put the work in before hearing your thoughts on that.
I would go for the last mentioned option (return file name in the stream of the download endpoint).

Thanks for the great app by the way. I really enjoy using it.

[rominator1983]

I do see something now that I have not seen before.
The update of mpd accepts a path that can also be a relative filename. So by doing what I suggested, the update can be triggered only for the just downloaded file. That would probably be very quick and we could remove the folder variable in cyp.js.

[ondras]

Sorry for the delayed response!

In general, I think that it makes perfect sense user-wise (download and immediate playback).

• Add some logic to the server to talk to mpd to be able to add the file after the update (of course there must be some wait and/or looping for the add to be reliable. This is of course a break in the architecture of the entire application and I would see why one would not want that.

I do not recall exactly how this works, but the MPD communication is done via the ws2mpd package. This communication channel can be probably enhanced with a public interface (called from the function that handles downloads) that does the mpd update relative_path command.

• Talking to another additional endpoint to get the filename would introduce state on the server.

Yeah, looks hairy.

• Giving the filename back as an HTTP header might work but at that point in time the HTTP response body has of course already been written mostly and from what I know and confirmed by a quick google search, things go downhill quickly when trying to attempt that at all.

Yep, not possible. Once we stream ther very first body byte, headers are out of reach.

Giving something back in the stream by some convention would also not be my first choice but probably work best from a reliability standpoint.

Exactly, this is how we would notify the client. Instead of streaming the body, we might use Server-sent Events, introduce some structure into the data and pass the filename in the stream.

In my opinion, the pure server-based solution (via ws2mpd) is a better choice. But I have not looked into it in more detail yet.