PDA

View Full Version : The Worst DB Implementation?



JSonnabend
2006-04-17, 12:42
Ok, this is weird, and I can't think of a single reasonable explanation for this.

I populate my slimdb database (SQLite) from an external Access DB. Everything works great, until I start browsing my db through the SlimServer web interface.

I browse by artist (or search, for that matter) for the artist "Clap Your Hands Say Yeah". I find one album with 12 tracks. Everything is fine. The next time I browse (or search) over to that album, there are only 11 tracks. The first track no longer appears with the album. Surf over again, now there are only 10 tracks. Tracks 1 and 2 have disappeared.

What's up with this? Anyone else see this?

- Jeff

snarlydwarf
2006-04-17, 12:47
Why are you importing it instead of letting the server build it? It's a relational database and is difficult to get the entries correct in all the tables.

If it sees things it doesn't like in a record (it certainly does this when the file location isn't found), it will remove the entry.

JSonnabend
2006-04-17, 13:17
I'm copying over rather than letting it scan my tracks because my tracks aren't tagged, but I do have a complete, centrally managed, clean db with all my track information.

As for the notion that it's somehow "difficult" to populate a relational database, that's just not true. This isn't a particularly complicated schema, and there should be no reason why one can't manually build the db.

In any event, it seems that the tracks aren't disappearing, SlimServer is "renaming" the tracks. So track 1, which was "<some song title> From Clap Your Hands Say Yeah by Clap Your Hands Say Yeah" becomes "Clap Your Hands Say Yeah - <some song title> on Clap Your Hands Say Yeah." Why is SlimServer renaming the tracks in the db?

http://sonnabendlaw.com/cap1.jpg

http://sonnabendlaw.com/cap2.jpg

http://sonnabendlaw.com/cap3.jpg

azinck3
2006-04-17, 13:26
I believe that when you play the track slimserver attempts to actually read the tags at that point to try to maintain accurate DB info. Your tags don't exist so it uses it's "guess tags" feature to attempt to discern the appropriate tag info from your directory structure and filenames. It then updates its database to reflect the results of its "guess", thus resulting in the info you're seeing.

JSonnabend
2006-04-17, 13:39
I believe that when you play the track slimserver attempts to actually read the tags at that point to try to maintain accurate DB info. Your tags don't exist so it uses it's "guess tags" feature to attempt to discern the appropriate tag info from your directory structure and filenames. It then updates its database to reflect the results of its "guess", thus resulting in the info you're seeing.
Thanks for the info. I was starting to think this might be the case.

How do I turn off the "guess the tags" feature (or, for that matter, the "update the DB with the best info" feature)? I'll twiddle with the Perl code, if need be.

TIA

- Jeff

kdf
2006-04-17, 13:39
Quoting JSonnabend <JSonnabend.26fdjb1145305201 (AT) no-mx (DOT) forums.slimdevices.com>:

> Why is SlimServer renaming the tracks in the db?
>
becuase slimserver believes the file is not yet scanned, so scans for
metadata and populates the db with its data. Given that you don't
have tags, then what you have is probably the result of the guessTags
function. Try going into server settings and deleting all of the
guess tags options.

-k

JSonnabend
2006-04-17, 13:48
Thanks for the idea. I've done that already, but to no avail (the first guess tags entry reads "0" after I delete all the entries and hit "Change").

- Jeff

kdf
2006-04-17, 13:59
Quoting JSonnabend <JSonnabend.26fexb1145307001 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> Thanks for the idea. I've done that already, but to no avail (the first
> guess tags entry reads "0" after I delete all the entries and hit
> "Change").

that's odd, but "0" should fail to match anything. Thinking about
this more, the server will probably end up with the plain filename.
Unfortunately, populating the db from an outside source just isn't a
supported function. I can't even think of a simple place in the code
where you could short-circuit the data updates. Perhaps have a look
in Datastores/DBI/DBIStore and block any of the writes to the db. You
may find that there is some data missing, which could be part of the
trigger for the updates.

Also, if you are running on windows, you'll have to install ActivePerl
and run slimserver.pl, instead of slim.exe for your changes to take
effect.
-k

snarlydwarf
2006-04-17, 14:02
Slimserver also updates the database when it reads files.

Mine all have tags, so I don't know what it would do if the file has no tags at all and guesstags is off.

Browny
2006-04-18, 03:31
If you move to MySQL then you could try giving the Slimserver user only read access to the database...don't know if the code would put up with this though - its not exactly what it was designed for.

Rather than go any further down this route would it not be easier to just right a function within Access to shell out and use TAG.EXE to write the tag information to the files? It would make life a lot easier in the long run...

Malor
2006-04-18, 04:30
It would probably be less work to fix this if you put tags in the files.

The way I'd probably do it would be to determine what information I already had, and then using an Access script, copy the files into a new directory hierarchy. (I used to have my hierarchy as Artist\Year\Album\Track, for instance.) I'd do a copy, if there was room, so I didn't mess up the working files. It doesn't matter how nasty/complex this structure ends up being, because it's only temporary.

Then I'd use Foobar's masstagger feature to populate ID3 tags based on the directories I'd created in the first step. It's able to figure out, based on the pathname, what tags to use. This will take some troubleshooting to get right, but it's not that hard.

Finally, I'd reverse the first step, and put the files back where they came from. Voila.... you still have the system you originally developed, and you also have tags in all your files. Just remember to tag new ones, and you're gold.

JSonnabend
2006-04-18, 05:33
I reached the same conclusion as Malor and Brownie after thinking about my alternatives. I don't have Access, so I'll have to write a routine in Delphi or C# using DAO/ADO/OLEDB/ABCDE (or whatever MS is calling the COM interface these days).

We can tell SlimServer not to scan, it's too bad we can't tell it not to update the DB other times. Oh well. Thanks to everyone for the input. Sorry about the thread title, I was feeling a bit frustrated when I posted, I guess.

- Jeff

JJZolx
2006-04-18, 17:26
I reached the same conclusion as Malor and Brownie after thinking about my alternatives. I don't have Access, so I'll have to write a routine in Delphi or C# using DAO/ADO/OLEDB/ABCDE (or whatever MS is calling the COM interface these days).[]

We can tell SlimServer not to scan, it's too bad we can't tell it not to update the DB other times. Oh well. Thanks to everyone for the input. Sorry about the thread title, I was feeling a bit frustrated when I posted, I guess.
I don't think you ever said why you just don't tag the files and be done with it. Unless you're using a format that doesn't really support tags, such as WAV. If you can write a program to populate the database, then you could likely find a tagging library or utility to just as easily let you transfer that data to tags in the files.

But I have to agree with you... It would be nice if SlimServer could be set to not muck with the library data except when explicitly told to do so. That way we might write our own library scanning utility and not have to worry about the data being changed by Slim Server when we're doing something as (seemingly) benign as browsing in one of the user interfaces.