[Feature Request] pause a playlist/youtube video and resume from where it stops

[ajmandourah]

It would be great to add a feature that let you pause a youtube video /playlist and resume from where it stopped . I looked in the source code and it only stop is implemented.

[DuckBoss]

This feature was suggested last year but the same issue still persists where the audio thread/instance will end as soon as it is no longer receiving audio data from vlc. This means that if the video is paused, the audio instance would end and it would instead move onto the next song in the playlist. Currently, I have been only able to implement a stop and seek method.

I'll look into it and see if I can find a way to emulate a pause feature.

[ajmandourah]

I see. I haven't played around with vlc before but if its the thread complaining about not reviving an audio see if it possible to play a 1 sec endless loop from where the audio position is and setting the volume to zero. It's dirty I know. I dunno if it can be implemented this way. I will brainstorm some ideas if you think it will be helping.

[ajmandourah]

One other possibility is to let the thread end store the position. As the resume command executed you can seek to the wanted position then.

For playlists the video number in the queue and the position can be used in the same way..... Probably.

[DuckBoss]

One other possibility is to let the thread end store the position. As the resume command executed you can seek to the wanted position then.

For playlists the video number in the queue and the position can be used in the same way..... Probably.

Yes, I was thinking of doing it this way. However I found out that VLC has a web interface that can be enabled on launch, which accepts web requests for commands such as stopping/playing/pausing, etc. If I can figure out a way to keep a single VLC instance open without stopping/creating new ones, then I might be able to implement a way to send web requests from the bot to the VLC interface directly.

I tested out part of this theory and VLC seems to keep the stream open when pausing, and the bot was able to handle playing/pausing from the VLC web interface.

The only problem is that this would require a rewrite of the youtube plugin (and probably any other audio plugin) to use a single VLC instance initialized during bot startup, and add tracks/playlists dynamically. This means I would probably have to provide an API for plugins to access VLC through the bot with web requests.

I'll look further into it and test some things out. I need to optimize the playlist loading times anyways so I'll most likely be rewriting the youtube plugin. This would also open up possibilities to directly interface with the VLC equalizer, audio filters, etc.

[DuckBoss]

Okay, so I ran a few tests based on my last comment and this seems possible. There are a lot of things that need to overhauled though.

• Use single instance of VLC that stays alive when the bot is online.
• Create custom API to send web requests to VLC web interface to directly control VLC interface.
• Overhaul all audio plugins to use this single instance of VLC and use the custom API to send commands to the VLC interface.

Based on the small tests I've run, this would allow for any supported commands by the VLC web interface such as stopping, playing, pausing, playlist/video queuing, etc. This system would also allow the bot's own web interface to directly interface with VLC.

This is a pretty big task, so this might take a while...

[ajmandourah]

This is actually great. I dont know the fearures of the VLC web interface but I reckon alot of possibilities is there (probable even streaming). great job. looking forward to it actually.

[DuckBoss]

Complications so far:

• It seems that I won't be able to use VLC's built-in playlists as the bot wouldn't be able to detect when VLC switches to the next song in the playlist without constantly polling the VLC web interface, which is extremely inefficient. I'm going to update my custom queue system and use that instead. From a user's perspective, they shouldn't notice any difference.
• VLC's interface automatically generates the track name from the uri, which in this case is a youtube stream which makes the name a long URL. There doesn't seem to be anyway to manually set the track names either. This is a problem when using VLC's playlist system, but this should also be resolved when I use my custom queue system.

Good news so far:

• It seems play/pause/seek are all still functional using VLC's web interface.
• The custom API I've made to access VLC with http requests is functional and fully working now.

Let me know if you have any suggestions or ideas, I'm experimenting with a lot of different things

[DuckBoss]

I'm putting this update on hold temporarily. I've been getting some weird issues with the VLC web interface so I'll continue working on this when I am closer to a v4.0.0 release.

[DuckBoss]

Turns out that this won't work out using VLC's web interface, so instead I've made my own embedded media player from scratch that will only use VLC for audio output. It should be a lot more robust and optimized than using VLC's web interface. I'm nearly done implementing the updates and it will be released in v4.0.0, which should be coming soon.

[DuckBoss]

Hello! I've implemented !pause/!resume commands to v4.0.0 which will be released soon.

[ajmandourah]

Wow this is great! Can't wait to try it out. So what is the difference now between the old VLC usage and now that you are using your own media player? Is there any impact on performance?

[DuckBoss]

Great question, I'll try to summarize the best I can since the actual changes were a lot.

So, the code for audio playback that I've been using for the sound_board/youtube plugins have had the same structure since v1.0+ and it was a very brute-force method of managing audio threads and playlists/queues. I've spent the last week or so reworking the audio handling from scratch by implementing an "audio interface" which is a centralized library in the bot that will handle most audio functions. Using this audio interface, all plugins now have a centralized method of playing audio, instead of each plugin handling audio separately (which caused lots of bugs/crashes).

The VLC software itself will be used the same as before, but there will be a lot of changes internally to make everything run smooth and fast.

I'll list out some major features/changes in v4.0.0 below:

• Reworked Commands/Aliases Processing System
• New alias processing so that aliases work regardless of what command token you use (ex: !echo/~echo/$echo)
• New callback-based command processing in plugins which make adding new commands super easy.
• Centralized audio controls for whatever plugin is using the audio interface.
• !volume/!pause/!resume/!replay/!shuffle/!skip/!stop/!loop/etc etc.... are commands for the audio interface that will work across any audio plugin (no more separate commands for each plugin, like !sbstop or !ytstop, etc.)
• Improved "Do Not Interrupt" system so audio plugins don't accidentally play over each other
• Improved track looping system (no longer interrupts audio/queue)
• Any audio plugin (third-party or not) can easily use this audio interface to make plugin development fast.
• Centralized audio information handling which means that web interface development for audio plugins will be a lot easier.
• Optional Audio Ducking so the bot automatically lowers the volume when it detects people talking in the channel.
• New volume fading feature so that changes in volume are smooth and not abrupt.
• Major performance/memory optimizations with new audio interface system:
• Audio threads are created from the audio interface library and will prevent memory leaks and frozen audio
• Major media plugin improvements (youtube plugin has been renamed to media plugin)
• SoundCloud URL support (no playlists yet)
• Youtube playlists generation won't take forever to load (and no audio breaks when generating)
• Faster youtube searching and video loading
• Improved thumbnail image retrieval and management
• Major sound board plugin improvements
• Support for queuing sound board clips (optional feature, default behaviour is still the same as v3)
• New commands: !sbnow/!sbquiet/!sbquietnow/!sbrandomnow/etc etc
• LOTS OF BUG FIXES (way too many to explain)

I have a v4.0.0 release checklist in case anyone wants to track the remaining items to complete before release.

Hope you like v4.0.0 when it comes out!

[DuckBoss]

Hello! If you have some time, could you try out the v4.0.0 Test Branch I have set up? I want to try to get some people to test the bot before I release v4.0.0. Since I'm a solo developer, there's bound to be some bugs I didn't catch.

As far as setting up the new version, it should be similar to v3.0. I recommend setting this up separately to any existing version you have, and to setup this version from scratch. I recommend creating the config.ini file from the config_template.ini file in the cfg/ folder, and the bot should be able to set everything up based on your config.ini file when you launch it. You can also just copy the aliases_template.csv file and rename it to global_aliases.csv and place it in the cfg/ folder for the default aliases. I don't recommend trying to use any old configs with this new version for testing.

I will be updating the wiki with the full documentation when I'm closer to releasing the new version. Please let me know if you run into any problems, or have any questions.

[ajmandourah]

Absolutely! I will try it out tomorrow after work on a separate server. I will let you know if sth occurs

[DuckBoss]

I'm going to close this issue, but you can still post your feedback here or start a new issue report if any problems occur.