The Beetle web interface

[ctrueden]

This discussion is a followup to the old beets forum topic Beetle : a web interface for beets talking about Beetle, a very cool (but still very immature) alternative web interface for beets written by @laBecasse.

On Mar 15, 2021 5:27 PM, I wrote:

I got it up and running, but I have two problems:

1. I do not see any album art. I have set my .env correctly to my server’s hostname on the LAN. My issue is that beets web is not serving the album art: e.g. http://myserver.lan:8337/album/42/art returns 404 for the album, even though every track of the album has the album art embedded in the music file. I thought maybe this was because I only keep album art embedded in metadata, and don’t write out cover.jpg files or whatever, but I tried creating a cover.jpg and restarting beet web and it still 404s. What am I missing?
2. I get a 500 server error every time I click anything, or search for anything. But if I reload the page with Ctrl+R, the query loads. Unfortunately, that clears the currently playing song and play queue, so it’s only limitedly useful as a workaround. I tried with both npm run start and npm run dev but nothing shows up on the console in response to the 500. Is there a log file somewhere? Or a way to enable verbose/debugging mode to learn more about the errors?

I just wanted to share that I finally got around to playing with Beetle some more, and I fixed both of the above issues.

Displaying album art

I fixed the album art issue by forking beets to modify the web plugin; see ctrueden/beets@d4542ed. My problem stemmed from the fact that I have fetchart + embedart set to embed album art into each track while deleting the external album cover file:

embedart:
  compare_threshold: 50
  ifempty: yes
  remove_art_file: yes

So the artpath field is thus empty for all of my albums, and therefore accesses to beets web's /album/12345/art endpoint all yield 404. To work around this issue, I modified the web plugin to also look for art embedded in album tracks if using the artpath DB field fails.

With this improvement in place, my Beetle is now beeautiful as intended:

If this approach is interesting for upstream, I could file a PR, but I thought I'd ask first if people think this is even a good idea generally (possible performance issues, etc.)?

Fixing the 500 errors

Beetle needs a BEETLE_API environment variable pointing to where the beets web API is being served. Unfortunately, there is no distinction between internal/server-facing versus external/client-facing API endpoint, and npm run preview runs over localhost only by default, and I was unable to figure out how to convince the --host flag to expose Beetle more broadly on my network. To address this, and related issues, I split the env var into two—API_SERVER_URL and BEETLE_API_CLIENT—and encapsulated a bunch of Beetle's API accesses into dedicated endpoints in src/routes/api; see ctrueden/beetle@3a866b8 for the complete patch, done with assistance from Claude.

Result: my Beetle instance now works when doing "single-page application" loads by clicking links, as well as when doing full page loads e.g. by pressing ctrl+R.

@laBecasse Unfortunately, it is difficult for me to file a PR with this fix, because I cannot log into GitLab, because I cannot receive emails from them—they simply never arrive. Apparently it's a problem lots of people have with GitLab? 🤷 Anyway, that's why I forked Beetle to GitHub rather than my space in GitLab.

Running with a proxy/reverse-proxy setup

I run beets on a Linux server named worf, where I have:

1. music collection (mounted over NFS from a NAS named quark) rooted at /quark/music
2. music collection served by Apache at http://worf.local/data/music
3. beets web running at http://localhost:8337, proxied to http://worf.local/beets
4. beetle running at http://localhost:3000, proxied to http://worf.local/music

beets config.yaml configuration for web plugin:

web:
  host: 0.0.0.0
  cors: '*'
  reverse_proxy: true
  include_paths: true

Beetle `.env` config

# Beets API endpoint for server-side requests (used by Node.js backend)
# Should be accessible from the server (localhost:8337 or internal IP)
API_SERVER_URL=http://localhost:8337

# Beets API endpoint for client-side requests (used by browser for images, etc)
# Should be accessible from the client browser (public URL or proxy)
BEETLE_API_CLIENT=http://worf.local/beets

# host of beetle (without base); only required for the RSS feed
BEETLE_HOST=http://worf.local

# you must not put slash at the end of base
# e.g. /beetle/ fails, and /beetle works
BEETLE_BASE=/music

# beet web api do not serve file
# by supporting partial content HTTP method (code 206)
# you may want to serve the files using another static access point
# Setting the following parameters enables an alternative access
# It first requires that web.path is set to true in your beet configuration !
#
# root directory of your library
BEETLE_FILES_DIR=/quark/music
# access url of the library root
BEETLE_FILES_URL=http://worf.local/data/music/

# path of the directory containing your playlist files (*.m3u)
BEETLE_PLAYLISTS_DIR=/quark/music/Playlists

Apache web server configuration

<VirtualHost *:80>
        #ServerName www.example.com
        ServerAlias worf.local  
                                          
        ServerAdmin webadmin@localhost
        DocumentRoot /var/www/html
                                          
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # Serve music library over HTTP, so Beetle web interface works better.
        Alias /data/ "/quark/"
        <Directory "/quark">
                Options +Indexes
                AllowOverride None
                Require all granted
        </Directory>
        RedirectMatch 301 ^/data$ /data/

        ProxyPreserveHost on
        ProxyRequests off

        ProxyPass        /beets/ http://127.0.0.1:8337/ nocanon
        ProxyPassReverse /beets/ http://127.0.0.1:8337/
        <Location /beets/>
                ProxyAddHeaders on
                RequestHeader set X-Forwarded-Path "/beets"
                RequestHeader set X-Script-Name "/beets"
                RequestHeader set X-Scheme expr=%{REQUEST_SCHEME}
        </Location>
        RedirectMatch 301 ^/beets$ /beets/

        ProxyPass        /music http://127.0.0.1:3000/music
        ProxyPassReverse /music http://127.0.0.1:3000/music
        #RedirectMatch 301 ^/music$ /music/
</VirtualHost>

Things that still don't work

• I haven't gotten the playlists-related features working yet. Clicking playlists still yields a 500 for me.
• The web scrobbling via my browser's web scrobbler plugin does not work (web scrobbler reports "This website is not supported"), even though the PR adding it (Beetle connector web-scrobbler/web-scrobbler#3098) was merged almost 4 years ago now.

I may spend some time trying to fix both of these issues relatively soon; we'll see!

In the meantime, I hope this post helps someone who wants to run a nicer web interface for beets than the web plugin's proof of concept implementation.

P.S. Another way to get a much nicer web interface is via iBroadcast, which lets you upload your own music collection to the cloud privately (like Google Play Music used to do, and YouTube Music still lets you do except that it is technically poor for several reasons IMHO), and then access it anywhere via a nice web player. I wrote the beets-ibroadcast plugin to facilitate partial or complete uploads of beets libraries into iBroadcast, as well as keeping tags and playlists synced.

P.P.S. See also #4336, which aims to discuss possible improvements to the beets-web interface.

[semohr]

To anyone looking for alternative web interfaces for beets, you might also want to check out beets-flask, a project I’m working on with @pSpitzner. It’s a similarly a web interface for beets that aims to provide a clean, responsive UI and easy integration with an existing beets setups.

It’s also still evolving, but it might be worth a look if you’re experimenting at the moment.

[ctrueden]

Thanks for cluing me in, @semohr. The beets-flask project looks awesome. I'm excited to play with it when I have some more spare time. 😄