bafdyce / botamusique Goto Github PK

If possible without JS.

E.g. running !list with a huge list of files in the music directory leads to a long reply message. Depending on the mumble server's settings this message might be rejected by the server.

The bot should be able to determine whether a given message was successfully sent (or determine the maximimum message length in characters). Then the message should be either truncated, split into multiple messages, or it should just send an error message.

• Pre-download track when queued
• Dont re-download already downloaded tracks
• Delete old tracks if they were not played in the last x days (or if space is tight)
• Show cached tracks

• Items in the queue and the 'now playing' item should show the user who added this track to the queue.
• For requests made via the web interface we could just name this "user" web or something similar
  • And/Or (if possible) use the http basic auth username from the proxy (if available), preferably without passing the pw to the application

Describe the bug
See Steps to reproduce.

Affected version
be6b4d4

Steps To Reproduce
Steps to reproduce the behavior:

1. Send the bot a private message with a !playurl <url> command without HTML formatting of the message.
2. The bot crashes and disconnects from mumble

Expected behavior
The bot should play the given sound file.

Screenshots/Log

Traceback (most recent call last):
  File "mumbleBot.py", line 350, in <module>
    botamusique = MumbleBot(args)
  File "mumbleBot.py", line 80, in __init__
    self.loop()
  File "mumbleBot.py", line 308, in loop
    self.launch_next()
  File "mumbleBot.py", line 238, in launch_next
    url = m.group(1)
AttributeError: 'NoneType' object has no attribute 'group'
bot exited with return code 1

For the bot to be registered on the mumble server it needs a client certificate.

On hold until #17 is fixed.

write "now playing" info to comment

Pause playback and resume at the same spot again.

Just some simple styling to make the web interface a little prettier to look at.

Show:

• track name
• source
• time info (duration, current timestamp)
• who requested it
• track statistics? (see #34 )

• e.g. when uploading a wrong file
• Currently the user only sees a general error message without any info about the actual error.

• It should be somehow re-architected so that mumble-commands and the web interface access the same object/function (to minimize duplicate code).

• times played
• times skipped
• last played

• add timestamps
• write log to file (See issue #37)
• more information in general

• Not a major bug but it's a bit annoying

Do a pentest at some point in the future

cache it unless refresh is neccessary

Error message:

File "botamusique/interface.py", line 92, in index
    var.playlist.remove("file", request.form['delete_music'])
TypeError: remove() takes exactly one argument (2 given)

After we finished most (major) issues, properly reviewed, and tested them we should create pull requests to merge them back to the upstream repo. Either in one huge PR or in several independant smaller pull requests. Before that (but after implementing most issues) we should contact the upstream maintainer to talk about the changes.

(...) even when clicking x on a different (but duplicate) item in the playlist.

• Currently it looks like ('file', 'path')
• We should use the the same format as in 'currently playing'
• Also add estimated time of playback start?

Currently when there's a connection issue between the bot and the connected mumble server (after successfully joining the server) the bot just quits. However, there are situations where it might be desired if the bot would try to reconnect:

• There's just a temporary connection issue
• Mumble server is restaring (for whatever reason)

In case the bot loses the connection to the server it should retry to connect a number of times (n) with some time (t) delay between each connection retry.

Each parameter should be configurable (command line and/or config file) with some meaningful default values if omitted.

ps: dreddit is recruiting

• At least in the web interface
• Maybe also as a mumble command (will be difficult to implement user-friendly though)

This issue is related to #27

• restful or restlike?
• allows building a command line client later on