I have a various artists/junk directory that’s long been used to catch all of the miscellaneous stuff that doesn’t get filtered into the other libraries, for whatever reason. It’s almost all mp3 files, detritus collected over at least 25 years, so I’m not going to be shocked that sone of this stuff has gone over to the Dark Side.
I’ve been going through and deleting bunches of stuff, pruning dupes, removing some file formats (sorry, lone ogg vorbis), plus I should figure out auto-pruning anything under 128/44.1. I also just dumped everything into one directory, which killed yet more dupes, just to get rid of folder clutter. At some point I need to melt Picard into slag by retagging everything as best I can.
Tl;dr preamble, sorry.
I had this library on one server, moved it to the other. It exhibits the same issue on both.
Issue: the scan progresses as scans do, but inevitably it’ll get stuck on a presumably bad file. I’ve been able to spot these in the past (it’ll come up in the activity drop-down) but now…not. I just have a generic scanning notice. It seems to be stuck on something, but I can’t tell what.
My options include Plex Dancing the entire library, Plex Dancing it in pieces (it’s around 20,000 tracks), or just deciding it’s too annoying and erasing it from the hard drive it’s on. It’s (mostly) backed up, but I can’t see ever reloading it.
Anyway, as I can’t tell anything from either alerts or console, here’s logs for tax.
So you have 20,000 tracks in one big folder?
If that’s the case, Plex will most likely never be able to completely scan it. Because it tries to determine to which album those 20,000 tracks belong. So it will compute the sonic fingerprint of 20,000 tracks and then try to find a combination of tracks which constitute a known album.
Computing the sonic fingerprint of 20,000 files alone can take quite some time. But finding and comparing each possible combination of elements from a pool of 20,000 will take endless time. And there will likely be a timeout lurking in the code along the way.
So the process will never finish.
Try at least to break down the collection into subfolders, with no more than s few dozen files in each.
They were in a myriad of different folders before, which was a mess in itself, with probably 10-12,000 in the main folder. It was just the way the thing grew over time; utterly slapdash.
I thought about it for a bit, then went ahead and shut down Plex and went to work on the folder. Renamed it to Various Artists, then divided up the contents.
Right now it’s 12 very uneven subfolders. I can subdivide those, though my first step might be to go through each one and delete stuff.
This is something I’ve been saying in regards to Plex for years, though — it can have a lot of trouble with music directories if they’re really big…and mine are often test-to-destruction huge. Like the classical anthologies library I just managed to get scanning again (I had to remove complete Bach and Mozart libraries.) That thing’s been scanning for two or three days — admittedly being restarted due to server updates and such — and is making noticeable progress.
Plex seems to handle huge movie and TV libraries fine. Music (and, by extension, audiobooks) not do much. Not great with photos, either, when there’s more than a few hundred.
In my experience, if a track shows a bad duration, Plex may choke on it. It’s not a guarantee, but it is a useful test all the same. (What is frustrating is that these tracks sometimes check out as good with other tools – Plex is extra fussy.)
You can also use Process Explorer on Windows to see exactly what file the Plex transcoder is working on, because the filename is listed in the executable arguments. Checking during a stuck scan can give you another hint as to the bad file, but not all things that choke the library scan use the transcoder.
I know my Sonic Analysis barfs on a few tracks every time it runs, but the logs only reference them by Track ID and I can’t figure out how to get from that number to a filename.
I have some weird encodes in that directory, with ridiculous durations. Some with not so ridiculous durations, but certainly longer than they really are — the top two entries in the image below are actually 34 minutes long (I should know; this was a megamix project I did)
Most of these entries are correct in length, but there’s a few wonky ones.
I used to have a utility that cleaned up MP3 files — mp3fix, I think. Any local copy is buried, unfortunately, and I haven’t found it on the web in recent searches. I admit it’s been half-hearted as I’m mostly lossless these days.
This is another one. https://mp3diags.sourceforge.net/
The user interface takes quite a while to get used to, but is the most thorough tool of its type (at least of those which I have used over the years). It only handles mp3 though.
Found my way to it earlier. I’m currently running it on one directory and having it back up to another. The same developer also does a tool called Mp3Fix, but it doesn’t seem to be the same one — this deals with tagging.
