The idea is to have the server safely shutdown BEFORE it loses power, so that BIOS setting wouldn’t mean anything. The server does not loose power while it it running, so it will never “restore last state after AC loss”. The idea is that you can run a low power device (the raspberry pi) for which you don’t care if power is cut abruptly and that can talk to both the UPS and the wake-on-lan of the server directly over ethernet. It being local means those WOL are much more likely to work than trying to send them from outside your network when you’re remote. It’s a lot simpler to set this up once than it is to recover a server with a corrupted file system due to power loss or lose access to your server for weeks because a thunderstorm knocked out power for 30min at the beginning of a long trip. That pi can also take care of other always on services like a pi-hole, home assistant, etc.
- 0 Posts
- 6 Comments
Wolf314159@startrek.websiteto
Selfhosted@lemmy.world•Anyone know a good Selfhosted yt-dlp manager?English
5·3 months agoCould they not think of an original name? Calling it YouTube-dl is just unnecessarily lazy and confusing. This appears to be mostly a docker image of yt-dlp, which is itself a fork of youtube-dl.
So much safer to go one album at a time using Picard. Picard makes it easy to go down the list of a disorganized directory, identify most things automatically, allow in depth review and modifications to what Picard came up with, and standardize file naming. I’ve tried to let programs like Lidarr and beets automate it, but they always ends up causing more and more complex problems to discover and solve after awhile. Music releases are complex and sources are diverse, using distinct standards of form and format. It’s not a problem that can realistically be solved for my entire music library without the guiding hand of a librarian. I could listen to my library for over six months without repeating, even 1 album out of a 100 mis-tagged or misidentifyied could take me years to discover.
I do like to automate the less critical and more machine oriented library tasks like adding genres tags, replaygain, and lyrics as you do. Just not things like the metadata tags, file naming, or album art (embedded or otherwise).
Wow, if the demo was too much for the developers to maintain that doesn’t inspire confidence in my patience to maintain it on my machine.
Wolf314159@startrek.websiteto
Selfhosted@lemmy.world•Dedicated music server or all-in-one media server?English
2·1 year agoPlexamp has gotten better lately. It can save your progress on audiobooks now. It’s a per library feature, so I have one library of music (that does not save progress) and one for audiobooks (that does save progress). I used to have trouble with some audiobook formats (M4Bs needed to be converted (really just renamed) to mp4s, but that wasn’t necessary for the last few I loaded. Plex still has a little trouble with standards around multiple authors and different productions (and different readers) of a single book, but that’s more of an ID3 tag problem and is resolved if you’re consistent in normalizing the tags on your library. I’ve also used the syncing features a bunch for offline time (like on a plane or on long trips). For a large library, I see syncing offline files as a necessary feature.
And before the Jellyfin fanboys chime in, if Jellyfin could match these audio and syncing features (and be easier to setup for access outside my LAN and sharing with family), I jump ship in a heartbeat.
In thousands of songs, I’ve never noticed Picard doing anything to the length of the files. I tend to manually review every album by running it through Picard and letting it handle the renaming and tagging. That structure used to be Artist/Year Album/Song. I’ve been less strict about naming the songs themselves. It’s always at least track - Title, but sometimes Artist - Album - Disc # - is prepended. Eventually I ran into a situation where I had multiple versions of a release/album with different enough content to warrant keeping both, so now I throw a release ID number (if is exists) after the album name, and inside brackets, for the directory name.
It’s a very flat structure by design, so I’m never quibbling about where I sourced something or what particular genre it is when I’m looking for it. That dramatically reduces the likelihood of duplicates too. Real metadata is better left to tags, since that’s mostly what any player will see anyway.
If I’m having trouble getting Picard to recognize something it always because: musicbrainz.org is missing the release, doesn’t have acoustic ID, or Picard preferred the album track when I’m trying to rename and tag a single or EP. Adding the release info and acoustic ID to musicbrainz is easy and I can usually use the info before the release is even reviewed, but often in trying to add the release I’ll find the correct one and now I can help fill out the data about it.
I treat musicbrainz.org as MY metadata database. If a release is missing or has problems, I do the work to make it better. It’s good digital citizenship and learning about their rules for releases helps me manage my server better.