PDA

View Full Version : Browse Music Folder doesn't



dbls
2005-01-14, 10:27
When I rip new music, "Browse Music Folder" seems to
be unable to find it unless I wipe cache. I have
SlimServer 5.4.0 installed on WinXP Home SP2, with my
music directory on a network share. Previously, I had
the problem with the server on a different machine
running Windows 98, in which case the server machine
also housed the music directory.

I know this is an old topic; my questions are, is this
possibly fixed in 5.4.1, and if not, is there anything
I can do to help diagnose the problem?

-:- dbls

kdf
2005-01-14, 17:41
Quoting dbls <dbls (AT) comcast (DOT) net>:

> When I rip new music, "Browse Music Folder" seems to
> be unable to find it unless I wipe cache. I have
> SlimServer 5.4.0 installed on WinXP Home SP2, with my
> music directory on a network share. Previously, I had
> the problem with the server on a different machine
> running Windows 98, in which case the server machine
> also housed the music directory.
>
> I know this is an old topic; my questions are, is this
> possibly fixed in 5.4.1, and if not, is there anything
> I can do to help diagnose the problem?
>
> -:- dbls

There was a known problem with the browse music folder option, when the music
folder setting was blank or changed. This is fixed in 5.4.1, but this doesn't
sound liek the same problem. Where do you put the new music? If you create a
folder called 'new' then rip to subfolders of that, it shoudl work. Whereas if
you rip to a the root of your music folder, then the server can fail to notice
a change to that.

-kdf

dbls
2005-01-15, 09:53
> Quoting dbls <dbls (AT) comcast (DOT) net>:
>
>> When I rip new music, "Browse Music Folder" seems to
>> be unable to find it unless I wipe cache. I have
>> SlimServer 5.4.0 installed on WinXP Home SP2, with my
>> music directory on a network share. Previously, I had
>> the problem with the server on a different machine
>> running Windows 98, in which case the server machine
>> also housed the music directory.
>>
>> I know this is an old topic; my questions are, is this
>> possibly fixed in 5.4.1, and if not, is there anything
>> I can do to help diagnose the problem?
>>
>> -:- dbls
>
> There was a known problem with the browse music folder option, when the music
> folder setting was blank or changed. This is fixed in 5.4.1, but this doesn't
> sound liek the same problem. Where do you put the new music? If you create a
> folder called 'new' then rip to subfolders of that, it shoudl work. Whereas if
> you rip to a the root of your music folder, then the server can fail to notice
> a change to that.
>
> -kdf
>

Actually, I copied an artist folder (which contains one album
folder with 14 tracks) into the root from another computer.
This conforms with the structure of the rest of my library.

I made a few other changes, like combining some directories
that were variations of an artist's name, and moved a stray
track that was in the root. None of these changes could be
seen in Browse Music Folder.

Interestingly, when I corrected another problem I reported
yesterday (I found that some WAV files ripped from an LP *did*
have ID3V1 tags, so I changed the track titles to include
track number as a prefix), the changes showed up instantly,
even under Browse Artists.

This leads me to believe that the database scanning reads
information from the tags to build the menu structure, with
each track linked to a physical file, but then rereads the
tags from the files whenever it presents a list of tracks.
I suppose it must reuse the stored information if the
physical file is missing.

The thing that I find most confusing is that SlimServer uses
the database when browsing the music folder. I thought the
whole point was to read the folder directories in real time,
because the user knows the database is out of date.

-:- dbls

kdf
2005-01-15, 12:19
Quoting dbls <dbls (AT) comcast (DOT) net>:


> The thing that I find most confusing is that SlimServer uses
> the database when browsing the music folder. I thought the
> whole point was to read the folder directories in real time,
> because the user knows the database is out of date.

the existing problem with 5.4 is that its not really a database at all. Its
simply a stored cache. The server caches the directory information becuase
scanning the raw filesystem every time is actually much slower. The list of
files can simply be drawn from the cache if the directory is already known.
Most of the time, the server finds new files and starts a new scan. I can't
think of a specific fix, but that doesn't mean 5.4.1 isn't worth trying out.
It is not like the old nightly builds, where you take a risk. any change to
5.4.1 is carefully considered, so right now, it is very close to what it will
be when it is officially released.
-kdf