View Full Version : Changed Tags Not Recognized By Slimserver

2007-11-25, 09:07
I've been having a recurring problem with Slimserver that I'm hoping someone here can help me out with.

Slimserver isn't picking up Tags that I'm changing even after rescans. I've noticed the problem most often with genre tags. Here's what I've tried:

1. I've changed the tags in itunes.
2. When that didn't work I used "Tag & Rename"
3. When that didn't work I deleted all ID3v1 tags using Tag & Rename
4. When that didn't work I used the "Clear library and Rescan" method rather than looking for new and changed music

I'm running Slimserver 6.5.2 on Windows XP.

2007-11-27, 12:26
anyone? Bueller? Anyone...

Kevin Lepard
2007-11-27, 12:38
Have you tried telling Slimserver to look for "New & Changed" music?
Or have you had it delete the database and rescan everything from


On Nov 27, 2007, at 11:26 , chrispy wrote:

> anyone? Bueller? Anyone...
> --
> chrispy
> ------------------------------------------------------------------------
> chrispy's Profile: http://forums.slimdevices.com/member.php?userid=14146
> View this thread: http://forums.slimdevices.com/showthread.php?t=40555

2007-11-27, 12:46
I experience the same - changed tags (using FLAC) are not picked up using "New & Changed", nor is changed artwork.

I always end up having to do a complete rescan.

Currently using latest svn 7.0.

2007-11-27, 14:29
have you told the application that you are editing the tags with to preserve the files date/timestamp?

if the editor changes the tags, but preserves the file's original date and time, that would explain why slimserver doesn't see it as being a new or changed file.

don't know if that's what's happening to you, but something to check for.

2007-11-27, 14:40
No, the timestamps are changed. I updated some tags last night, the modified date reflects last nights changes, but a rescan did not pick them up.

I hand replaced a Folder.jpg cover art file, which is not detected as new or changed either.

2007-11-27, 14:53
I haven't changed any timestamps, not sure if tag and rename does that or not, but I have done full rescans so it shouldn't matter. Thanks for the suggestion though...any other ideas? The problem is kind of driving me nuts.

2007-11-27, 15:20
Somewhat different symptom here, but possibly a similar cause??



2007-11-27, 15:40
i only have a few mp3 files, but i do vaguely recall something like this maybe happening to me - related to the different familes and versions of ID3 tags.

i used MP3Tag to strip out all the older, conflicting tags, and properly update the others ... and the changes stuck and were updated into the database.

(i think there may be duplicate sets of tags in the file, you are editing/updating one, but slimserver is scanning the other ... mp3tag cleaned things up nicely, there are options in it's config menus to strip out and save APE/ID3 etc)


2007-11-27, 20:32
Thanks for all replies. David C's suggestion panned out. I deleted the problem tags using MP3Tag and rescanned and the changes finally stuck. Not sure if it was MP3Tag that ultimately did the trick or just the fact that I actually deleted the tags before rewriting. Either way it's a relief to finally have this problem in hand...now I just have to apply it to another 30 albums or so...

On a side note if any of the slimdevices developers are reading this maybe there's a way to make the slimserver scanner a little less sensitive to data that gets buried in the tags this way? Obviously there was some kind of weird data that was buried in there, but since iTunes, Windows, and 3 tagging programs (ID3tagit, Tag&Rename, MP3Tag) all missed it I'm led to believe that they're finding a way to ignore corrupt data that Slim Server should be too. I feel like I'm spending way too much time obsessing over minute details to cater to a device that I bought to make my life easier.

(Still, in all, this forum and the support provided here are great and highly appreciated.)

2007-11-27, 21:42
In my case, the files are FLAC and have no conflicting tags; never have. Either way, this doesn't account for cover art not being recognized as changed.