Create A To-Be-Played and Have-Played Queue

artforlife commented 8 years ago

We could add a queue, similar to that of Mixcloud (bottom bar) that shows the things one played recently or allows to queue things to be played next.

cipher1729 commented 8 years ago

I am working on issue #222. Along with the basic feature, I am also keeping track of the songs played till now (it's stored in a browser session variable ). That can be integrated into a GUI to show 'played recently' and a 'new queue' ?

artforlife commented 8 years ago

Is there a separate branch for your feature?

shakeelmohamed commented 8 years ago

@artforlife Is there something we still need to do for this if #222 and #1 are added?

cipher1729 commented 8 years ago

@artforlife No, there's no branch in the main repo for my feature. I'm still pushing changes to my fork, in the 'autoplay' branch

artforlife commented 8 years ago

@shakeelmohamed Well, I do not use the Youtube playlist feature. What is it like in a nutshell? I am envisioning a sort of To-Play-Later queue. Think of this as bookmarking certain things with intention to return to them later.

shakeelmohamed commented 8 years ago

@artforlife that's basically it. YouTube actually has a special "watch later" playlist designed just for this purpose

artforlife commented 8 years ago

Is there a PR for this yet? Perhaps we can see a screenshot or something.

shakeelmohamed commented 8 years ago

@artforlife there is no PR yet

shakeelmohamed commented 7 years ago

We discussed some ideas in #212, tying this "later" playlist to YouTube/Soundcloud accounts is my preferred approach.

shakeelmohamed commented 7 years ago

FYI, we can use Auth0 for free until we week 7k users - not likely to happen 😄 The full tutorial is here we'd just need to request the appropriate YouTube permission scope for Google account login.

~~I'm not sure how we'd handle Soundcloud if we went that route... any ideas?~~ edit: looks like Auth0 supports SoundCloud so that's a non-issue: https://auth0.com/docs/identityproviders however, I'm not sure how we'd handle "mixed" playlists

i-radwan commented 7 years ago

I would like to start working on this issue if possible 😄 , my approach will be:

Store the videos the user have played in a queue (which is stored in localStorage)
When the user selects one video from the queue, the video will start playing (the queue will be displayed below the "Click for Demo" button)
The user can delete videos from the playing queue.
Allow the user to drag/rearrange videos in the queue.
Enable adding videos to the queue from the search result list (for playing them in the future).

Has anybody finished developing any of these points or shall I start from scratch ?

shakeelmohamed commented 7 years ago

@hemoali thanks for jumping in!

I see this feature as a 2 part implementation:

Add the Auth0 authentication flow to authenticate with YouTube via Oauth. Then using the authentication token, retrieve items from the users's YouTube "Watch Later" playlist.
Integrate with some of the work in #244 to deal with the playback of the playlist.

i-radwan commented 7 years ago

@shakeelmohamed I'm working on it now, but I've some problems with YouTube API authentication using the tokens retrieved from Auth0 (cannot find the right flow). However, I'll keep searching and if you have any advice/tutorial, it will be much appreciated 😄

shakeelmohamed commented 7 years ago

@hemoali did you see this guide? https://auth0.com/docs/quickstart/spa/jquery

i-radwan commented 7 years ago

@shakeelmohamed Yeah sure, I've followed this tutorial and the last piece of it (https://auth0.com/docs/quickstart/spa/jquery/08-calling-apis) gave me the 401 error when calling the YouTube API. However, from what I've understood (from the searches I've been doing) that the access token of the services we need to use (e.g. YouTube) is kept hidden for security reasons, and to get this access_token we have to send a request using our application client_secret key (which is provided by Auth0), and to keep this secret key secret we need a back-end which will be called from the client side (passing the token-id generated on the client side), then on the back-end, by using the secret key, we can get the access_token of the service (e.g. YouTube) and then use it to get the required data and return it to the client side. However, I think there's another easier flow (because if this is the only available flow, this means that Auth0 isn't useful as it could be), but I cannot figure one right now 😄

i-radwan commented 7 years ago

Well looks like this is the correct flow to achieve a secure process 😄

i-radwan commented 7 years ago

@shakeelmohamed I've tried the Google APIs, and the authentication process went very well. But the shock was that YouTube API disabled the access to "Watch Later" and "Watch History" from the API after Sep. 15 2016 😞 as shown here

I will try to find a workaround (although that a simple search revealed no solution 😞). Now I think we may make our own queue and then sync it with playlist into YouTube/Soundcloud

shakeelmohamed commented 7 years ago

@hemoali ouch. I know I ran into this on another project, https://github.com/shakeelmohamed/youtube-watch-later/issues/2 but I didn't realize the data simply isn't available anymore.

One workaround (so we don't have to deal with a database) is using a "Zen Audio Player" playlist (create it if it doesn't exit).

i-radwan commented 7 years ago

Just to keep others updated:

What I've added:

Sign the user in using Google Javascript Library (OAuth2).
Create the app playlist named 'Zen Audio Player'. If the user already has a playlist with this name, the app will use it instead of making new one (To handle clearing localStorage or using Zap across many devices).
When the user plays a video, it gets added to the playlist (unless it's already added).

What I'm planning to add:

Display this playlist as a queue allowing the user to see it and play its videos.
Allow the user to delete videos from this playlist.

Suggestion:

Depending on statistics, will caching the videos as mp3 files on the server be a user-demanded service? As I think most users who use such service want to listen to some videos without consuming their data packages and without waiting for videos to load. We can offer this conversion service as paid service or special service for the users who use the app often.

shakeelmohamed commented 7 years ago

Overall though, I think you've got the right approach for the implementation. I'm excited to see the PR 🎉

will caching the videos as mp3 files on the server be a user-demanded service?

@hemoali I'm not interested in entering the copyright infringement legal mess around this feature. Moreover, the website is 100% hosted by GitHub pages for free and there is no "backend" server to host mp3s. We don't support mobile devices, so I don't see an issue around data usage for most users. There are several other services that will allow you to download mp3s from YouTube videos, let's leave that to the experts 😄 Monetizing sounds appealing, but I wouldn't have open-sourced this project if I cared about profitability.

Utkarshbhimte commented 7 years ago

Is this issue still up for grabs? Would very much like to make a basic playlist functionality on this? without using 0Auth just localStorage and maybe also another button to share that playlist.

shakeelmohamed commented 7 years ago

@Utkarshbhimte yep, go for it!

andy-shi88 commented 7 years ago

what's the status of this issue? I think I could make multiple playlist on localstorage here, that'd be great I think for us to listen to multiple group of songs and keeping it simple at the same time. 👍 what do you think?

shakeelmohamed commented 7 years ago

@andy-shi88 this hasn't implemented yet, go for it if you're interested!

avalan4e57 commented 7 years ago

I think that my last pull request closes this issue also. Tell me if am I right or there's still something to work on the issue.

shakeelmohamed commented 7 years ago

@avalan4e57 I think this issue is asking for a different feature than #258, @artforlife can you verify?

chandan1794 commented 5 years ago

Is it still open? I'd like to have a shot on it. I'd try without OAuth, just localStorage.

shakeelmohamed commented 5 years ago

@chandan1794 go for it!

EvaThil commented 5 years ago

Me and a fellow student is doing a course in project development for our software engineering bachelor. We'd like to have a go at implementing a version of this functionality. Both creating new playlists as well as using the API to load existing YouTube ones as an alternative for continuous playing. Any pointers appreciated, especially additional requirements/wishes for the finished outcome. We have 4 weeks set aside for the construction process.

shakeelmohamed commented 5 years ago

@EvaThil Very cool! Feel free to ping me on Gitter and we can find some time to chat more in depth about meeting the goals of your course.

There was a decent amount of work done in #291 but seems to have been abandoned, feel free to use that as a starting point.

jingwu21 commented 4 years ago

Is this still open? If so I would like to have a go at implementing this feature.

shakeelmohamed commented 4 years ago

@jingwu21 yes, although I'm not sure if the app is even functional right now. See #321

jingwu21 commented 4 years ago

When I try to run the site locally it says the page isn't working and that the request is invalid. Is that caused by the current problem or am I running it wrong?

shakeelmohamed commented 4 years ago

@jingwu21 I think so. Can you share a screenshot, and any console messages?

k----n commented 4 years ago

Is anybody working on this? I am also interested in developing this.

k----n commented 4 years ago

The PR #336 solves half of this issue, but more work still needs to be done for a 'to-be-played' queue.

What's needed is the refactoring of the search functionality so that it does't reload the page and break continuity of the music playing. This can be achieved by replacing elements in the stage and using https://github.com/browserstate/history.js/ to manage the urls. Once that has been completed, it is trivial to add to the 'playlist' of PR #336 .

I do not have time at the moment to refactor the search functionality to implement the 'to-be-played' queue, but feel free to help out if you can!

AT1452 commented 4 years ago

Is this issue still up for grabs?

k----n commented 4 years ago

Is this issue still up for grabs?

@AT1452 IIRC, the search functionality of PR #336 solves half the issue. The 'to-be-played' queue hasn't been implemented yet.

ryekerjh commented 4 years ago

@AT1452 @k----n have either of you started tackling the to-be-played queue yet?

k----n commented 4 years ago

@ryekerjh No. But it appears to me that major refactoring of the search needs to happen to get it to work.

ryekerjh commented 4 years ago

@ryekerjh No. But it appears to me that major refactoring of the search needs to happen to get it to work.

Gotcha. I will leave this one to cool off a bit and check back in in a bit to see if that major refactor has taken place. Thanks for the speedy response!

thehitmanranjan commented 1 year ago

@shakeelmohamed Can I work on this?

shakeelmohamed commented 1 year ago

@thehitmanranjan Sure, go ahead

zen-audio-player / zen-audio-player.github.io

Create A To-Be-Played and Have-Played Queue #229

I would like to start working on this issue if possible 😄 , my approach will be: