PDA

View Full Version : Is this a bug, song search problem, update



Steven Moore
2005-01-03, 07:39
Just to let you know the search bug is still there, in my set-up
anyway. (os x, slim 5.4)
It only occurs after a rescan and then when you search for a song that
cannot be found, ie that is not in the playlists.
The same symptoms occur, it returns an empty message and then you get
the problem with slim server not connected message flashing every 10
seconds for a couple of minutes. After this it returns to normal.
Searches after this work fine also. The previous errors have gone since
I created the Playlists folder inside the music folder.
I consulted the console log and got this error I am pretty sure this is
the output to the console at the time of the disconnection:

getpeername() on closed socket GEN5 at
/System/Library/Perl/5.8.1/darwin-thread-multi-2level/IO/Socket.pm line
206.

I've also tried wiping the cache and rescanning the playlists.

BTW is it ok to delete the slim.log file(167mb) (I had the d_info
checked)?

Thanks

Steven Moore

kdf
2005-01-03, 10:49
Quoting Steven Moore <steven (AT) mooreni (DOT) freeserve.co.uk>:

> Just to let you know the search bug is still there, in my set-up
> anyway. (os x, slim 5.4)
> It only occurs after a rescan and then when you search for a song that
> cannot be found, ie that is not in the playlists.
> The same symptoms occur, it returns an empty message and then you get
> the problem with slim server not connected message flashing every 10
> seconds for a couple of minutes. After this it returns to normal.

This is due to the extensive CPU effort to do a search for a specific song.
This cannot be fixed with the 5.4 stream of code. The server has a hard coded
data storage scheme that doesn't make it friendly for song searches. The
server gets bogged down and does not send any data to the player for a long
time. The player then thinks the server is gone. This would be particularly
bad for a song not found because the server would obviously search through 100%
of the data.

The 6.0 stream, currently available in nightly builds, is in alpha testing. It
uses a Relational Database for the backend, with queries through SQL. This
should provide much faster searching ability.

> Searches after this work fine also. The previous errors have gone since
> I created the Playlists folder inside the music folder.
> I consulted the console log and got this error I am pretty sure this is
> the output to the console at the time of the disconnection:
>
> getpeername() on closed socket GEN5 at
> /System/Library/Perl/5.8.1/darwin-thread-multi-2level/IO/Socket.pm line
> 206.

This just means that the player connection is lost, temporarily. Its a mostly
harmless warning.

> I've also tried wiping the cache and rescanning the playlists.
>
> BTW is it ok to delete the slim.log file(167mb) (I had the d_info
> checked)?

if you dont need it any more, delete away :)
-kdf

Steven Moore
2005-01-03, 11:01
Thanks for the reply,

Yes the cpu went right up, as did disk activity when going through the
search >7800 tracks. Looking forward to the next release.

Steven Moore

On 3 Jan 2005, at 5:49 pm, kdf wrote:

> Quoting Steven Moore <steven (AT) mooreni (DOT) freeserve.co.uk>:
>
>> Just to let you know the search bug is still there, in my set-up
>> anyway. (os x, slim 5.4)
>> It only occurs after a rescan and then when you search for a song that
>> cannot be found, ie that is not in the playlists.
>> The same symptoms occur, it returns an empty message and then you get
>> the problem with slim server not connected message flashing every 10
>> seconds for a couple of minutes. After this it returns to normal.
>
> This is due to the extensive CPU effort to do a search for a specific
> song.
> This cannot be fixed with the 5.4 stream of code. The server has a
> hard coded
> data storage scheme that doesn't make it friendly for song searches.
> The
> server gets bogged down and does not send any data to the player for a
> long
> time. The player then thinks the server is gone. This would be
> particularly
> bad for a song not found because the server would obviously search
> through 100%
> of the data.
>
> The 6.0 stream, currently available in nightly builds, is in alpha
> testing. It
> uses a Relational Database for the backend, with queries through SQL.
> This
> should provide much faster searching ability.
>
>> Searches after this work fine also. The previous errors have gone
>> since
>> I created the Playlists folder inside the music folder.
>> I consulted the console log and got this error I am pretty sure this
>> is
>> the output to the console at the time of the disconnection:
>>
>> getpeername() on closed socket GEN5 at
>> /System/Library/Perl/5.8.1/darwin-thread-multi-2level/IO/Socket.pm
>> line
>> 206.
>
> This just means that the player connection is lost, temporarily. Its
> a mostly
> harmless warning.
>
>> I've also tried wiping the cache and rescanning the playlists.
>>
>> BTW is it ok to delete the slim.log file(167mb) (I had the d_info
>> checked)?
>
> if you dont need it any more, delete away :)
> -kdf
>

kdf
2005-01-03, 11:12
Quoting Steven Moore <steven (AT) mooreni (DOT) freeserve.co.uk>:

> Thanks for the reply,
>
> Yes the cpu went right up, as did disk activity when going through the
> search >7800 tracks. Looking forward to the next release.
>
Disapointing as it may be for this particular problem, the next official release
will be 5.4.1. 6.0 is a big change, and will take time and testing. The
release of 6.0 currently has not been given a timeframe (at least none that
I've seen).

-kdf