A lightweight YouTube client for Linux, without requiring an API key.
Create a new token called *URLS*, a space-separated list of the YouTube URLs of the videos a user has selected. This would allow a user to create a new video_player config using *URLS* instead of *URL*, such that when a user selects multiple videos, all their selected videos would get passed to mpv at once and appear as a playlist within mpv. The benefit to the user is that these multiple videos would be queued to play back-to-back in the same mpv instance. I like to start playing my queued videos on a particular monitor, then switch to another monitor to get some other stuff done. What happens currently is that once the first video ends, that mpv window closes, and a new mpv window with the next video in the queue opens on the current workspace/monitor, interrupting my workflow. By using *URLS*, the queue would be loaded into one mpv instance on the initial workspace/monitor, and once the first video ends, the next video would begin playing in the same mpv instance on the workspace/monitor I started the first video, therefore not interrupting my workflow. The second benefit is that because mpv is managing the queue, I can switch to the mpv window to examine the queue, and jump around in the queue to play a different video if I choose. The third benefit is that pipe-viewer would return to the video list immediately after I hit enter to play my selected videos, which would allow me to continue to browse videos/users/etc. as I choose, and would even allow me to select another batch of videos to send to mpv. Additionally, by integrating task spooler into the mix, these batches of videos would queue up and play sequentially. However, in this case, after the first task completes, the next queued task in task spooler would open on the current workspace/monitor, which is why this is not a solution, and why this *URLS* feature is required.
This issue appears to be discussing a feature request or bug report related to the repository. Based on the content, it seems to be still under discussion. The issue was opened by ehula and has received 3 comments.