# Music Assistant Support Repository: Issue Tracking and Automation > music-assistant/support is the public support and feedback workspace for the Music Assistant jukebox integration, rather than the server implementation itself. It organizes bug reports, feature requests, questions, and automated issue triage for the project. **music-assistant/support** — Music Assistant issue tracker - Repository: https://github.com/music-assistant/support - Website: https://music-assistant.io - Stars: 1,512 · Forks: 51 - Language: Unknown - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/music-assistant-support ## What Music Assistant support repository contains music-assistant/support is the support-facing repository for Music Assistant, a project described in its README as turning a Home Assistant instance into a jukebox for streaming media to Home Assistant media players. This repository is aimed at people operating the integration, reporting defects, asking questions, or proposing new capabilities. It is not the repository that contains the Music Assistant server implementation. The README links directly to the documentation at music-assistant.io and separately links to the server releases. The repository is primarily an issue and discussion workspace. Bug reports belong in the GitHub issue tracker, while feature requests and ideas belong in GitHub Discussions. The project also provides a Q&A category, a Discord community link, and a documentation site. This division matters because a user looking for installation instructions is directed to the documentation rather than to an install script or deployment package in this repository. The repository's visible top-level structure is small: .github/, .gitignore, and README.md. Based on that layout, the operational automation is associated with the .github directory. The README says that the support workflow uses automated actions to manage issues, but it does not present this repository as a standalone runtime service. ## How Music Assistant triage handles a new report The README documents a lifecycle that begins when an issue is opened or reopened. A Triage Bot runs first and performs several tasks: it applies provider labels, assigns a maintainer, validates the issue template, and analyzes logs. The workflow diagram then separates valid templates from invalid ones. A valid report receives a needs-attention label, allowing maintainers and the issue author to exchange details. An invalid report receives a waiting-for-user label, and the bot asks the issue author to correct it. The state labels reflect who is expected to respond next. When a maintainer comments, the workflow removes needs-attention and applies waiting-for-user. When the issue author comments, it removes waiting-for-user and restores needs-attention. This is a response-tracking loop rather than a one-time moderation step. The README states that the loop continues until the issue is confirmed as a bug or resolved. Once a bug is confirmed, including cases marked with bug or Fix to be Confirmed, response tracking stops and the issue enters the development pipeline. The labels are frozen at that point according to the documented diagram. This is a meaningful boundary between support coordination and development work, but the README does not explain how confirmed bugs are assigned, scheduled, or transferred to the server repository. ## Stale reports and automatic closure in music-assistant/support The support workflow includes inactivity handling. An issue marked waiting-for-user receives a stale warning after 14 days. If the user still does not respond, the workflow waits three more days and automatically closes the issue, adding an auto-closed label. A separate path handles issues that no longer carry a response-state label. Those issues receive a stale warning after 60 days, followed by 14 more days before automatic closure. Any new activity removes the stale label automatically. The README also states that bot and community comments do not trigger label changes. This distinction can affect the apparent state of a report: activity by a maintainer or the issue author is relevant to the response loop, while automated or community comments are not treated as a change to the waiting state. Some issues are exempt from automatic closure. The documented exemptions are issues carrying bug, Fix to be Confirmed, enhancement, or pinned. After closure, the workflow waits 30 days before locking the thread, preventing further comments. This design limits late conversation in old reports, although the README does not state whether an administrator can reopen a locked thread or whether there is an appeal process. ## Submitting a Music Assistant bug report or feature request The repository does not document a local installation command because it is the support issue tracker, not the Music Assistant server. The README points users who need help to the documentation at music-assistant.io. It also directs users who want to contribute to the project's help resources to the contribution page linked in the README. No installation flags, package names, configuration keys, ports, or environment variables are documented here, so there is no justified install command to reproduce. For a defect, the README asks users to open an issue and include detailed information and logfiles. It also asks users to check whether the issue has already been reported. Those two instructions define the first practical steps for a new user. The automation adds another important expectation. A report should follow the repository's issue template closely enough for the template validation step to classify it as valid. If validation fails, the bot asks the user to correct the report and places the issue in waiting-for-user. Feature requests have a different route. The README directs them to GitHub Discussions, specifically the feature requests and ideas category. Users can vote for an existing request, join the discussion, or create a new request. Questions and tutorials belong in the Q&A section. This routing reduces the chance that a feature proposal will be handled as a playback defect, although the README does not describe the internal acceptance process for proposed features. ## What the support repository does not document The repository is useful for support coordination, but its documentation is narrow. It does not provide a rollback procedure, server configuration reference, upgrade guide, compatibility matrix, or procedure for migrating an existing Home Assistant installation. It also does not explain which Music Assistant server version corresponds to a particular report, and the issue automation documentation is delegated to .github/scripts/README.md rather than reproduced in the main README. That omission creates a practical limitation for adoption decisions. Users can rely on this repository as the front door for reporting and community support, but they must consult music-assistant.io or the separate server repository for installation and technical implementation details. The release information shown for recent Music Assistant versions comes from the server project context identified by the README's release link, not from a release process documented in music-assistant/support. The repository's purpose also makes it a poor fit for anyone expecting a runnable jukebox application in this checkout. The visible layout contains support automation and repository metadata, not application code. A user who needs to inspect playback providers, configure media libraries, or diagnose server internals should not treat the support issue tracker as the source for those tasks. ## Maintenance and licensing status of music-assistant/support The repository is not archived, and its last push was on 2026-10-16. The repository was therefore recently updated according to its published history, but the README focuses on the support process rather than publishing a compatibility policy or upgrade schedule. The visible repository contents do not identify a license, so no licensing terms can be confirmed from the repository information. A user who needs to reuse code or automation should verify the repository's license before assuming permissions. The automation itself creates an ongoing maintenance consideration. Issue triage depends on templates, bot behavior, labels, log analysis, and workflow rules. The README says that bot and community comments do not trigger label changes, which is useful to understand operationally, but it does not provide the exact implementation behind the Triage Bot. Changes to those rules could therefore affect how reports move between states. The release entries do not define an upgrade path for this support repository. They identify Music Assistant releases dated 2024-12-07, 2024-12-04, and 2024-11-21, but the README does not say that these releases are maintained or deployed by the support repository. Users should separately verify the relevant server release and consult the project documentation before changing a production installation. ## Conclusion Music Assistant users who want to report playback problems or propose changes should use this repository, while users looking for the server source code should visit the separate server project. Before submitting, check for an existing report, include detailed information and logfiles, and review the issue automation rules because valid templates, missing responses, and confirmed bugs follow different paths. ## FAQ ### Where should I report a Music Assistant bug? Open an issue in the Music Assistant support issue tracker at https://github.com/music-assistant/support/issues. The README asks you to include detailed information and logfiles and to check for an existing report first. ### How do I request a new Music Assistant feature? Use the GitHub Discussions category for feature requests and ideas at https://github.com/music-assistant/support/discussions/categories/feature-requests-and-ideas. The README says you can vote for an existing request, join a discussion, or add a new one. ### What happens if I do not respond to a Music Assistant support issue? An issue labeled waiting-for-user receives a stale warning after 14 days and is automatically closed three days later if activity does not resume. Bot and community comments do not trigger label changes, while any new activity removes the stale label automatically. ## Sources - [Issues](https://github.com/music-assistant/support/issues) - [music-assistant/support on GitHub](https://github.com/music-assistant/support) - [Project website](https://music-assistant.io) - [README](https://github.com/music-assistant/support/blob/main/README.md) - [Releases](https://github.com/music-assistant/support/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/music-assistant-support