sebbadk / sonica Goto Github PK

This causes a crash, which breaks all clients.

Primarily thinking about the freedesktop notification spec, but a cross-platform method would be preferable.

We might as well allow users to respond with something like 1,2,6 to select both search 1, 2 and 6.
Proposed by @Rawrior

This sorta ties into #28

Separating the command invocation and command logic would make it infinitely easier to test everything. This will in turn will make it easier to change and/or add and/or remove things.

Sending a spotify link to the deez player caused the bot to crash with a stack overflow.

Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow.
Python runtime state: initialized

Thread 0x00007fe1f2a07640 (most recent call first):
  File "/home/sebbadk/software/sonica/playlist.py", line 29 in __autonext
  
Thread 0x00007fe1fabd3640 (most recent call first):
File "/lib/python3.9/threading.py", line 316 in wait
File "/lib/python3.9/concurrent/futures/_base.py", line 440 in result
File "/lib/python3.9/site-packages/discord/gateway.py", line 156 in run
File "/lib/python3.9/threading.py", line 973 in _bootstrap_inner
File "/lib/python3.9/threading.py", line 930 in _bootstrap

Thread 0x00007fe1fb3d4640 (most recent call first):
File "/lib/python3.9/concurrent/futures/thread.py", line 75 in _worker
File "/lib/python3.9/threading.py", line 910 in run
File "/lib/python3.9/threading.py", line 973 in _bootstrap_inner
File "/lib/python3.9/threading.py", line 930 in _bootstrap

Current thread 0x00007fe20aded340 (most recent call first):
File "/lib/python3.9/email/utils.py", line 57 in _has_surrogates
File "/lib/python3.9/email/_policybase.py", line 287 in _sanitize_header
File "/lib/python3.9/email/_policybase.py", line 316 in header_fetch_parse
File "/lib/python3.9/email/message.py", line 471 in get
File "/lib/python3.9/email/message.py", line 578 in get_content_type
File "/lib/python3.9/email/message.py", line 594 in get_content_maintype
File "/lib/python3.9/email/feedparser.py", line 295 in _parsegen
File "/lib/python3.9/email/feedparser.py", line 180 in _call_parse
File "/lib/python3.9/email/feedparser.py", line 176 in feed
File "/lib/python3.9/email/parser.py", line 56 in parse
File "/lib/python3.9/email/parser.py", line 67 in parsestr
File "/lib/python3.9/http/client.py", line 234 in parse_headers
File "/lib/python3.9/http/client.py", line 335 in begin
File "/lib/python3.9/http/client.py", line 1349 in getresponse
File "/lib/python3.9/site-packages/urllib3/connectionpool.py", line 440 in _make_request
File "/lib/python3.9/site-packages/urllib3/connectionpool.py", line 699 in urlopen
File "/lib/python3.9/site-packages/requests/adapters.py", line 439 in send
File "/lib/python3.9/site-packages/requests/sessions.py", line 655 in send
File "/lib/python3.9/site-packages/requests/sessions.py", line 542 in request
File "/lib/python3.9/site-packages/requests/sessions.py", line 555 in get
File "/lib/python3.9/site-packages/deezer/api.py", line 34 in api_call
File "/lib/python3.9/site-packages/deezer/api.py", line 42 in api_call
...

Could also add a command to remove specific songs from the queue

Add support for Matrix as an open-source alternative to Discord.

Right now all engines are hardcoded, but it would be cool if they just plugged into the system.
This will require them to be able to request certain parameters, but otherwise remain mostly the same, since they are already pretty generic.

Github offers Github actions as a CI pipeline implementaiton. Adding a syntax/style enforcer such as Black and/or running tests automatically (once #34 is fully fixed?) could be beneficial to working on the project.

For some actions, and on some platforms, having a clickable UI might be a way nicer way of interacting with the bot (mobile platforms especially).
This could be implemented via something like Elm and hosted directly by the bot, or adding an HTTP REST interface to the bot.

Right now Sonicas cutesy personality might not be for everyone, is only in english, and is hardcoded into the Discord frontend.

It would be nice to use a translation/localisation library to split all responses off into files, so we could use them in multiple frontends, and so Sonica could have a more bland personality for boring people xD

This could be done by exposing the LibraryEngine for search from other daemons, and then adding a FederationEngine that looks through a given list of Sonica instances and uses their LibraryEngines to find songs from.

As the codebase gets bigger and bigger, it gets harder and harder to work on. Splitting command parsing up and splitting functionality into several functions would make everything much easier to work with in the long run.

Current output can sometimes have songs with identical titles by identical artists. For example:

I found a bunch of songs:
1: [Song title] by [Artist]
2: [Song title] by [Artist]
3: [Song title] (radio edit) by [Artist]
...

Adding the album to search information could help with choosing and/or clearing up confusion. Like so:

I found a bunch of songs:
1: [Song title] by [Artist] from the album [Album title]
2: [Song title] by [Artist] from the album [Album title]
3: [Song title] (radio edit) by [Artist] from the album [Album title]
...

This will allow us to use more languages since the current properly supported languages for gRPC is still somewhat small.
The rest interface will also make it easier to interface with Sonica from webhooks and the like.

An alternative to this is to generate a gRPC REST gateway, but this makes the gRPC spec longer, and requires 2 services to run the daemon. The REST method might have lower performance than gRPC.

Right now you can only download via a search, but for something like the song Odyssey by Home, it doesn't show up in the first 10 results.

Expansion of issue #17

It's not currently used, so we should consider moving away from it before it's too late. Some of our contributors can't install it, meaning it would be hard or impossible for them to test their changes.

As an alternative, we could go completely library-free, and keep track of the tags in a separate json file, though this would also incur some development overhead.

There seems be be errors whenever a command matches nothing, as if Sonica always tries to access the enumerators with the channel-id even if the channel has no enumerator yet.

This was held back in the first iteration, but implementation is already underway

Writing for example queue 10 could show the next 10 autoplay songs, or queue all to show the rest of the autoplay songs (assuming #2 is fixed first).

The up next functionality should remain the same, in that it shows the whole up next queue.

Having a way to have some tags excluded at certain times and included at others would be great.
vocalfree and friday tags is probably the ones i would like, but a dynamic way that supports any tags would be best.

pytaglib can already add and read this from the files.

Could be that songs were added by mistake, or that the version of the song isn't what was expected

Being able to reshuffle the currently-playing list would be nice :)

Currently, all paths are concatenated via strings and assumes unix paths.
This should be fixed to use pathlib or something similar.

As an extension/rewrite of #39

Sonica will gladly try to send a message that is over the limit, causing a command abort.

If we are gonna have different interfaces to control Sonica, and many different loops listening for input, i think we should do an architecture overhaul.
I've been looking at gRPC and it seems perfect for this usecase, not only will each part of Sonica be a seperate process that can be restarted as necessary, it can also handle implementations in multiple languages, so the webserver could be crystal, while the discord and core is kept python, etc.

This could be done by making a two-way non-blocking api like the websocket gateway the default.
Alternatively, a client that just creates threads for each requests, and allows quick mass-lookup of something like spotify-playlists would be really nice for users coming to Sonica from other platforms.

If Sonica only finds a single song it should automatically be added to the playlist

We want to be able to add a song to the top of the queue.

Not exactly sure how this could be done, since the parsing of the command for the enumeration would have to be expanded kind of a lot.

Otherwise the creation of the enumerator could be changed, so that you could write next [player] [search term]

This is the generic mediaplayer protocol, that automatically allows media player keys, connection with KDEConnect, control of playback through DE and more.
It should be relatively simple to do.

Some songs may be radio edits but not marked as such, or may be extended cuts. This is completely unknown until the song actually plays. Having the song length along in the search could alleviate this.

Given that engines have rank, gathering the results and sorting them by rank afterwards should be quite easy.

Currently, only the local engines folder gets imported, but it would be best if the the included engines are included by default.
We should then also add an option to disable the default ones or select only some engines to add.

Save Deezer ARL key in a file when used for the first time, and read it when Sonica is started for the first time

Since much of the project had been personified as Sonica and responds in a cutesy way, it would be great to have a cute avatar to go along with the project.

Now that the refactor has been done, we need to reimplement the discord interface to get back to around the same status as the v0.1 bot.

Old functionality was just to type 1 to select item 1, but now you have to write try_enumerator 1, which is annoying.

The response to queue should be the currently playing song, what is currently called queue, and what the next X songs in the playlist after up next.

For example, the output could be:

I'm playing **[Song]** by *[Artist]*. Up next is:
**[Other song]** by *[Other artist]*

After that, I will play:
**[Song 1]** by *[Artist 1]*
...
**[Song N]** by *[Artist N]*

If there is no songs up next, the output could be:

I'm playing **[Song]** by *[Artist]*.

After that, I will play:
**[Song 1]** by *[Artist 1]*
...
**[Song N]** by *[Artist N]*

Since the refactor to use discord.ext we have been parsing every message in every channel as a command, which is a bit weird. We should limit it to non-sonica messages and to only channels that contains music in the name.