database integration, song count

[Kevin Deane-Freeman]

Web Browser is showing:
Browsing 971 albums with 4 songs by 1089 artists

It should be 10335 songs on my system

-kdf

[Richard Purdie]

[in an offlist mail I talked to Kevin (as the response time of the list
seems high)]
> > My messages to the developers mailing list aren't appearing so I thought
I'd
> > try and take this offlist to see if I can help.
>
> There is a setting to have yoru own posts sent back to you.
> http://lists.slimdevices.com/lists/options/developers

I'm set to recieve them. For some reason, they just took 5 hours to come
back to me!

Dean: Has something been holding up the mail on the server?

> > Where are your mp3 files?
>
> I have the server running at /usr/local/slimserver on Mandrak Linux 9.1,
with
> the mp3 files mounted to /mnt/mp3 using ext3fs on both.

Which is a very similar configuration to my own...

> > Should a file be accessible by the server on the following path?:
> >
> > /mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New York
(1994)/Nirvana -
> > 08 - On A Plain.mp3
>
> yes, that's correct.

Ok. To get the error you got, the server ran the code

if ( -e '/mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New York
(1994)/Nirvana - 08 - On A Plain.mp3' )

and came back false, despite the fact the file exists!

Any ideas anyone? (perl isn't my best language). The code concerned is in
checkForChanges() in Info.pm

> > > Web Browser is showing:
> > > Browsing 971 albums with 4 songs by 1089 artists
> > >
> > > It should be 10335 songs on my system
> >
> > I'll worry about that when we sort the first problem... :-/
>
> no problem. The songs ARE there when I browse. I haven't noticed any
missing.
> It just seems to want to delete and recache a large number on startup.

I see the same problem here so the two issues are not related. I'll look
into it and see if I can find the problem (and if it's cache code related or
not).

RP

[Kevin Deane-Freeman]

Quoting Richard Purdie <rpurdie (AT) rpsys (DOT) net>:

> [in an offlist mail I talked to Kevin (as the response time of the list
> seems high)]
> > > My messages to the developers mailing list aren't appearing so I thought
> I'd
> > > try and take this offlist to see if I can help.
> >
> > There is a setting to have yoru own posts sent back to you.
> > http://lists.slimdevices.com/lists/options/developers
>
> I'm set to recieve them. For some reason, they just took 5 hours to come
> back to me!
>
> Dean: Has something been holding up the mail on the server?
>
> > > Where are your mp3 files?
> >
> > I have the server running at /usr/local/slimserver on Mandrak Linux 9.1,
> with
> > the mp3 files mounted to /mnt/mp3 using ext3fs on both.
>
> Which is a very similar configuration to my own...
>
> > > Should a file be accessible by the server on the following path?:
> > >
> > > /mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New York
> (1994)/Nirvana -
> > > 08 - On A Plain.mp3
> >
> > yes, that's correct.
>
> Ok. To get the error you got, the server ran the code
>
> if ( -e '/mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New York
> (1994)/Nirvana - 08 - On A Plain.mp3' )
>
> and came back false, despite the fact the file exists!

> Any ideas anyone? (perl isn't my best language). The code concerned is in
> checkForChanges() in Info.pm

Sorry...check that. Turns out its not there. Of course, now I'm wondering how
it got there in the first place in order to be deleted! I stopped the server,
patched, started...then turned on database cache, stopped, restarted (in order
to use a fresh scan). Then the db was created. A while later, I stopped and
restarted and got those delete messages. That file didn't exist, and doesn't
exist in that location. The delete may be correct, but it should not be there
to have to be deleted.
-kdf

[Richard Purdie]

> > if ( -e '/mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New
> > York (1994)/Nirvana - 08 - On A Plain.mp3' )
>
> Sorry...check that. Turns out its not there. Of course, now I'm
wondering how
> it got there in the first place in order to be deleted! I stopped the
server,
> patched, started...then turned on database cache, stopped, restarted (in
order
> to use a fresh scan). Then the db was created. A while later, I stopped
and
> restarted and got those delete messages. That file didn't exist, and
doesn't
> exist in that location. The delete may be correct, but it should not be
there
> to have to be deleted.

I think I can explain this. It's all actually working

Upon reload after a file has been deleted, it should just print that message
once to say "yes, I've removed the file from the cache as it no longer
exists". Next time you stop and start, it should no longer be there.

However, there is the "issue" that if you have stale tracks in your
playlist, you will see a few of these messages. Say one of your playlists
has a link to the non-existent file. The server will try and find it and
fail. The server still puts something into the cache and sets the type flag
from the filename (presumably so it doesn't keep looking for the non
existent file). This data is saved to disk by the cache code. It's dropped
on reload as it's invalid. Scanning of the playlist reloads it though

I'm therefore going to suggest that the non existent file is listed in one
of your playlists and the server is behaving as correctly as it can. Clean
up your playlists and the message will disappear!

Re: the song count issue, I can see the problem and it is the caching code.
I'm working on a solution. The caching code also wasn't dealing with file
types other than mp3 correctly - I have this fixed and will send a patch
when I sort the other problem.

RP

[Kevin Deane-Freeman]

Quoting Richard Purdie <rpurdie (AT) rpsys (DOT) net>:

> > > if ( -e '/mnt/mp3/Unsorted/NIRVANA/Nirvana - Unplugged in New
> > > York (1994)/Nirvana - 08 - On A Plain.mp3' )
> >
> > Sorry...check that. Turns out its not there. Of course, now I'm
> wondering how
> > it got there in the first place in order to be deleted! I stopped the
> server,
> > patched, started...then turned on database cache, stopped, restarted (in
> order
> > to use a fresh scan). Then the db was created. A while later, I stopped
> and
> > restarted and got those delete messages. That file didn't exist, and
> doesn't
> > exist in that location. The delete may be correct, but it should not be
> there
> > to have to be deleted.
>
> I think I can explain this. It's all actually working
>
> Clean
> up your playlists and the message will disappear!
aw mom, do I have to??
Thanks Hopefully this also explains the deleting cover art messages.
Didn't occur to me that it would be scanning playlists as well.


> Re: the song count issue, I can see the problem and it is the caching code.
> I'm working on a solution. The caching code also wasn't dealing with file
> types other than mp3 correctly - I have this fixed and will send a patch
> when I sort the other problem.

cheers!
kdf

[Richard Purdie]

> > Clean up your playlists and the message will disappear!
> aw mom, do I have to??
> Thanks Hopefully this also explains the deleting cover art messages.
> Didn't occur to me that it would be scanning playlists as well.

Any data held in infoCache is preserved. The code throws anything away that
it feels is suspect though for obvious reasons. I'm not sure what it would
do about the images. In theory we should cache that data and keep it on
restart. I'm be interested to know if the code does or doesn't (I don't have
use the image functionality).

On the subject of the image data, my system seems to look for it upon each
browser refresh. Once the system has checked, surely it should stop looking
if it doesn't exist? (Could we use a system like the TAG=1 variable?)

> > Re: the song count issue, I can see the problem and it is the caching
code.
> > I'm working on a solution. The caching code also wasn't dealing with
file
> > types other than mp3 correctly - I have this fixed and will send a patch
> > when I sort the other problem.

Patch attached. This fixes three things:

1. None mp3 files should now be added to the genreCache correctly
2. The songs count is corrected
3. HTTP URLs don't affect the song count (it was one out on my system and it
wasn't my code doing it! I found it was the version check code causing the
count to get increased by one - the attached patch fixes it as well

RP