YTPlayer Additional Features: Song Interleave, Song Timeout, Song Bumping



Hi everyone,

I’ve been thinking for a while that there are some features in the YTPlayer that I’d really like to see in order to better control what song plays when. So I guess I’ll try to add them! All these features would be options on the ytplayer page, and they are as follows:

  • Interleave Frequency: [float, >=0] Will play a song from the playlist after every n songs from the queue. For example, 2 means every 3rd song will be from pl, 0.5 means 2 songs in every 3 will be from pl
  • Song timeout: [int >=0] Number of seconds between consecutive queueings of the same song.
  • Queue bumping: [bool] If enabled, when a song is queued, it will be placed between user’s songs who have a greater number of songs remaining in the queue.

I think this should all be fairly easy as it’s mainly (fully?) in youtubePlayer.js. The worst part imo is probably going to be maintaining a separate list of all queued songs over the timeout period.

Other features I’ve been thinking about, and might add later:

  • Skip and Punish: Skip the current song and ban/timeout the user who requested it
  • Steal and Attribute: Some sort of perma-mention for users who get their songs stolen.

Anyways, those are just some of my thoughts for now. Hopefully I’ll have it up and running in the next few days!



Just as a side note, if you add more commands and features to the page, you will more than likely need to modify the Java Core: create handling for web socket payloads, create new events. Then wire the events via $.api.on(), and catch events in youtubePlayer.js. You might also need two-way communication (have the Core push data to the page) if you are going to allow commands to change some features and you want it updated on the page.

Remember to use thread safe data objects, that caused problems at one point in the past when thread safe objects were not utilized.



Thanks for the tips!

I think since all the features I’m adding are just settings, I can maybe handle it all in the scripts through IniDb. I’ve already got song timeouts working without needing to modify the Core. But I suppose if I want people to be able to change the settings via command, then I would have to?

It doesn’t seem like something I’d have a need to change very often, so I might just leave it in the ytplayer settings interface only for now.


You can go that route, but to send data to the GUI (web page) data is sent over a websocket. If you are only making the configurations applicable in the script that is one thing. If you are also adding support to make modifications and to see changes made in Chat in the GUI, then that is a different thing - for example, the volume control, when modified in Chat, sends a signal to the web page to update, and vice versa. If the song timeout is intended to be viewed/modified in the GUI, you might need to look at how volume works.


So I’m nearing completion of the three features I really wanted to see. What’s the best way to share this? Should I just upload a patch? Should I make a pull request on GH?


You can submit a pull request. It has to include testing results, as we like to see folks testing their software changes before requesting a push to the master release branch. We try to do a code review at least but, do not always have the time to perform tests of the changes – especially if we do not understand what the behavior should entirely be, the developer of that change would.



Great! Thank you!

What sort of testing results would you expect to see? I took a quick look, but didn’t see anywhere to include any unit tests.

I’m including some fundamental changes to how YTPlayer queues songs, but with the default configuration I’ve included, absolutely nothing changes.

I’ve finished up all the features, and am just in the process of working out a few bugs now. I’ll be using this in a production environment, so it seems the best I could do (without further guidance) is say “It works great for me! :D”


I believe the testing results would be the same way that you found bugs - by running the code and ensuring that it works.

Showing the commands is good - this shows that the language scripts are in good order.
That the commands are working as expected.
Show that I can’t use -1 for a value for the options that expect 0 or above to be entered.
Show thread safety as applicable. We have had thread safety issues in the YouTube Player code previously.

Essentially, you have the user story developed, with what you are expecting to produce. Show that it works and has not inadvertently caused a bug in the YouTube Player.

What I normally ask my employees to do (yes, I manage a software team during the day and develop software myself) is to show me positive and negative tests and I need to be able to understand their code and it needs to fit into the coding guidelines. All of this is pretty much laid out when you submit a pull request.