Dec 15 21:32:06 cachyos-x8664 mpd[59707]: exception: error
Dec 15 21:32:06 cachyos-x8664 mpd[59707]: exception: error
Dec 15 21:32:06 cachyos-x8664 mpd[59707]: exception: error
Dec 15 21:32:14 cachyos-x8664 mpd[59707]: exception: error
Dec 15 21:32:22 cachyos-x8664 mpd[59707]: exception: error
Dec 15 21:32:39 cachyos-x8664 mpd[59707]: exception: error
Good news is I can recreate it while running in a debugger and hopefully get some kind of idea of where the breakdown is.
[Unit]
Description=mpd-dbproxy
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/mpd-dbproxy --config /var/lib/mpd/mpd-dbproxy.conf
User=mpd
Now on to several weeks of real-use testing before it gets a release. Maybe not several weeks; but it's going to undergo extensive testing.
I haven't even tested database updating; which is the primary reason I made this.
I made mpd-dbcreate to solve a problem; I didn't like mpd's databases. It wasn't all mpd's fault, some plugins were to blame; but it made mpd annoying to use despite the fact it was the best at what I needed it for. It solved this problem. The music flowed; and it made MPD absolutely perfect.
But it also caused it's own issue; you couldn't update with mpd anymore. You had to update with mpd-dbcreate, then restart mpd to load the new database. This maybe wasn't really that annoying, I put up with it for a few months. After building mpd-dbcreate my brain was kind of on the track of this would require the ability to commuinicate with mpd in a way that the client API or library provided...which mpd-dbcreate had stripped out of it anyway. But, it turns out, there is a way...
mpd-dbproxy, a mpd database proxy server. mpd has the ability to proxy it's music database to other mpd instances, a thing they call satellite setup. In this arrangement, all database operations are slaved to a "master" mpd and sent "raw" t
LiveKit-Meet Container
I needed to keep the Docker theme going in my livekit stack; so here's how to make livekit-meet in to a docker container.
Clone the repo
cd meet
While I'm normally not a docker guy; I'm part of a large project in which the deployment will matter...so I figured I better start building things in Docker. This project will use livekit, so I decided to deploy that. Oh boy. There are some problems that the documentation didn't clearly cover. So...here's my janky set of notes:
They did not update the deployment script; therefore it generates non-working initializations. They are using old outdated information that is not compatible with the new versions of docker the script installs. Yes...it installs versions incompatible with itself. The only issue really is that all references to docker-compose should be docker compose. Both in the documentation and in the script.
The documentation will clearly tell you that you need port 80 forwarded to your livekit:
Changed my username to seperate everything from ham radio.
This one tripped me up becasue I couldn't see where it was documented and I'm not sure if it was something I was just expected to know...which, apparently; I didn't.
On Windows hosts you can use a named pipe or com0com to achieve a virual com port you can toss miniterm at. Why would you want to do this? Because Xenix286 doesn't have a TCP/IP stack. If I want to talk to it so I can copy/paste code, then I have to do it over terminal. Maybe I'm going to drop it on the network at a security conference in front of a telnet bridge and see who finds it.
On Windows, this was easy; com0com, serial port pass through, done. Knowing it supported named pipes..I thought this would be even easier on Linux. tty0tty, same process....no. Apparently the dropdown box only allows /dev/ttySn devices. Okay...we'll symlink it! Oh...now that device disappeared from the list. Okay..screw it...let's force the name in the config; maybe it'll work anyway. No dice.
Fast forward through a day of messing around and I finally decided t
Here's a more detailed and deep-dive in to why I created mpd-dbcreate.
First of all, when I say it was "wrong"...it was wrong for me. My massive old collection was part of the problem. I could have fixed half the issues by modifying the actual media on my drive. Would this have been easier? No. We're talking TBs of stuff. There's also a .0005% chance I'd regret modifying the collection like this in the future. I don't really want to go around changing it. It's bad enough I'm finding 20 year old garbage in folders I'd long forgotten about. "Oh, I'll remove the converted version later." I know from experience with a collection this large that those things rarely get found. There are probably still things messed up from the great-crash-and-recovery of 2002 that I....still haven't found....23 years later. Or the great backup and reset of 2005...which was 20 years ago. I finally fixed my Powerman 5000 album from 6.3 filenames though.
I never adopted databases. I still use traditional folder organization. Make a
For the last few months I'd been using Cantata as my mpd client despite the fact it's pretty much been abandoned. Wanting to break away from that, I went in search of some other clients that are still actively maintained. rmpc wasn't what I was looking for; but I liked it. But the one thing I didn't like was having it be just another tab or grouped with all my other Konsole apps.
I did this in alacritty...because at the time I wasn't using it for anything else and could just mess with it's global config all I wanted. In production...you probably want to make a seperate config file for whatever you're using. I also don't know what options you'll need to change...so hopefully you can keep up.
alacritty.toml
[window.class]
instance = "rmpc"
general = "rmpc"