consider trying 6.5.  no further development is going on with 6.3.1

David, if you do a clear library and rescan everything do the playlists show back up?

(In reply to comment #1)
> consider trying 6.5.  no further development is going on with 6.3.1

This is unfortunately no option for me. I need a stable version.

(In reply to comment #2)
> David, if you do a clear library and rescan everything do the playlists show
> back up?

Christopher, I tried a clear library and a complete rescan. It took more than one hour to rescan everything (180 GB data, 1 GHz EPIA ). After the rescan again no playlists.
I can imagine this behaviour is hard to reproduce. For the time being, I guess it's better to stick to 6.2.2.

Well I'm still certainly interested in trying to figure this problem out.  Is it possible you could attach one of your playlists to this bug using the "Create a New Attachment" link, above?

the clip from the log above shows only detail for teh current playlist rendering.  This only applies to the current player playlist http page.  If you want to take a look at what is going on in regard to the playlist scanning, turn on d_import, d_scan and d_parse before initiating a scan or at the command line.  The log will then show much greater detail from the playlist scanning.

(In reply to comment #4)
> Well I'm still certainly interested in trying to figure this problem out.  Is
> it possible you could attach one of your playlists to this bug using the
> "Create a New Attachment" link, above?

I think i've figured it out. Yesterday I decided to install the 6.5beta version. I entered the playlist location (data/public/music/playlists) in the server settings. An error message appeared saying the choosen directory didn't exist. I changed the path to /data/public/music/playlists (please notice the leading forward slash) and everything worked fine. 
In Windows I went back to my vmware snapshot (slimserver 6.3.1) and did the same (changing the path by entering the forward slash at the begin). Now the playlists did show up again. 
My conclusion: In 6.3.1 there is no error message in case a path doesn't exist (a missing forward slash at the begin, in my case).

Now I've got another related problem (It would be great if you got any clue). In 6.5beta the playlists will not disappear if i delete the files from the playlist directory and a rescan (I've checked this out only with playlists only option because of the time it takes to do a complete rescan and cleaning the library). Exactly the opposite problem. Now I want them to disappear but they won't disappear :=(
Seems the playlists are also stored in a cache or in the mysql database??

Thanks anyway for your time.

David 

(In reply to comment #5)
> the clip from the log above shows only detail for teh current playlist
> rendering.  This only applies to the current player playlist http page.  If you
> want to take a look at what is going on in regard to the playlist scanning,
> turn on d_import, d_scan and d_parse before initiating a scan or at the command
> line.  The log will then show much greater detail from the playlist scanning.

I still can't figure it out. I thought I solved it (see one of my latest replies to Chris). 
It works correctly in my VMware environment but not on my linux server.
As you suggested I've turned on the debugging settings. The only result after a rescan (playlist, look for
new music) in the log file :
2006-08-17 22:03:55.1412 Import: Wiped all in-memory caches.

B.t.w I did a test with the 6.5beta release on my server. This particular problem didn't occur (although 
the where other problems).

Created attachment 1439 [details]
a playlist saved by the slimserver gui

That appears to be a valid .m3u file.

Very strange.  I tried it on my debian 6.3.1 platform (under vmware, I have to admit) and it seemed to work okay with similarly-named folders for playlists and music.

I'm really wracking my brain now.  is your data/public/music directory on the local filesystem?  Or is it mounted from somewhere else?

(In reply to comment #9)
> That appears to be a valid .m3u file.
> Very strange.  I tried it on my debian 6.3.1 platform (under vmware, I have to
> admit) and it seemed to work okay with similarly-named folders for playlists
> and music.
> I'm really wracking my brain now.  is your data/public/music directory on the
> local filesystem?  Or is it mounted from somewhere else?
It is on the local filesystem.
A friend of mine (he uses a similar configuration) has the same problem. He uses slimserver 6.2.1.
Could it be a user rights/owner issue. The data/public/music directory is created as root with 777 rights. Shouldn't the owner be slimserver?

The best I can do at the moment is work to make sure this doesn't happen in the 6.5 release.

(In reply to comment #11)
> The best I can do at the moment is work to make sure this doesn't happen in the
> 6.5 release.

Actually, this doesn't happen in 6.5 (see comment #7). In 6.5 I encountered a lot of other problems. For instance: digital noise at my external DAC after turning off the SB2, playlists that won't be removed form cache, for each song in a multi disc album a separate album entry in the browse by album section etc.

Have you got any idea when the 6.5 will officially be released or an indaction on which term? Must I think in weeks, months or quarter years?).

I will post this particular problem to the forum.

Thanks anyway.

David

 

The Transporter product requires Slimserver 6.5, and it's slated to ship on Sep 18th, so Slimserver 6.5 will almost certainly be out on or before that date.

For some reason (I really don't know how) playlists now appear in the playlist section after a rescan (slimserver 6.3.1). I haven't changed a bit.
Still some strange things:
1.
I can not browse playlists I've created outside the slimserver web GUI. For instance playlists generated
with foobar2000 in windows, saved as m3u, in unix format and utf8 codepage still won't appear.
2.
Playlists-songs with non-ASCII characters won't show-up in the playlists after a rescan. I can browse them as long as I don't start the rescan.

Debug info:
ists/Chopin%20favourites.m3u made file:///data/public/music/flac/Chopin,%20Fr%E9d%E9ric/Nocturnes%20[Moravec]%20(disc%202)/03-C%20minor,%20Op.%2048,%20No.%201.flac
2006-08-23 15:18:55.9334 isList(file:///data/public/music/flac/Chopin,%20Fr%E9d%E9ric/Nocturnes%20[Moravec]%20(disc%202)/03-C%20minor,%20Op.%2048,%20No.%201.flac) == 0
2006-08-23 15:18:55.9349 not a list: file:///data/public/music/flac/Chopin,%20Fr%E9d%E9ric/Nocturnes%20[Moravec]%20(disc%202)/03-C%20minor,%20Op.%2048,%20No.%201.flac
2006-08-23 15:18:55.9366 adding single item: file:///data/public/music/flac/Chopin,%20Fr%E9d%E9ric/Nocturnes%20[Moravec]%20(disc%202)/03-C%20minor,%20Op.%2048,%20No.%201.flac, type flc
2006-08-23 15:18:56.0008 [/data/public/music/flac/Chopin, Fr�d�ric/Nocturnes [Moravec] (disc 2)/03-C minor, Op. 48, No. 1.flac] does not exist or cannot be read: No such file or directory at /usr/local/SlimServer_v6.3.1/CPAN/Audio/FLAC/Header.pm line 59.
2006-08-23 15:18:56.0030 ERROR: Couldn't open file: [/data/public/music/flac/Chopin, Fr�d�ric/Nocturnes [Moravec] (disc 2)/03-C minor, Op. 48, No. 1.flac] for reading: No such file or directory

Have you got any clue?
Thanks in advance,

David

One or both of these remaining issues may be related to bug 2475, a perl bug that prevents us from reading non-ASCII filenames at the moment.

I'd be happy to have a look at your troublesome Foobar-generated playlist file if you'd upload it.

(In reply to comment #15)
> One or both of these remaining issues may be related to bug 2475, a perl bug
> that prevents us from reading non-ASCII filenames at the moment.
> I'd be happy to have a look at your troublesome Foobar-generated playlist file
> if you'd upload it.
I'm not sure it's related to that bug. I have no problems with these filenames in a windows environment.
Please find enclosed two playlists:

1. Chopin favorites.m3u
This playlist is generated by slimserver. It contains non ascii characters in the filename but
these are not exotic ones like japanese characters. Extended ascii characters only. After a rescan the
filenames with extended ascii characters won't shop up in the playlist.
If I open the file in textpad (window app) I noticed the playlist is extended m3u and the codepage
used is utf-8(signature). I'm not sure if it is required to use extended m3u and a utf-8(signature) codepage
for slimserver in Linux (once again, no problems in a windows environment).

2. foobarplaylist.m3u
I've created a simple playlist with a few songs. I saved the playlist as a m3u file. 
Furthermore I did some manipulation with TextPad (like replacement of \ to / etc.) and finally saved the
file as a UNIX format and utf-8 codepage. FYI: In TextPad you can also choose the Unicode of Unicode(Big endian)
codepage but not the utf-8(signature) codepage. This playlist won't show up in the playlist section (for 
song with or without extended ascii characters in their filenames)

Good luck with it.
David

Created attachment 1467 [details]
foobar generated playlist

Created attachment 1468 [details]
slimserver generated playlist

David - can you try a recent nightly?

I've fixed a similar problem with iTunes playlists not showing up (it had nothing to do specifically with iTunes).

I believe this may be the same.

If you're running on Linux, you can start SlimServer up, then in another shell, run:

./scanner --wipe --d_import --progress

Thanks

ping David

(In reply to comment #19)
> David - can you try a recent nightly?
> I've fixed a similar problem with iTunes playlists not showing up (it had
> nothing to do specifically with iTunes).
> I believe this may be the same.
> If you're running on Linux, you can start SlimServer up, then in another shell,
> run:
> ./scanner --wipe --d_import --progress
> Thanks

Sorry for the late reply. I was on holiday.
Have you fixed it in 6.3.x or in the 6.5 version.
The 6.5 I guess?

Subject: Re:  Browse playlists section is empty after rescan music library

6.5 only. Beta2 was released today. http://slimdevices.com/dev_nightly.html

Yes, 6.5 only.

beta3 was released last week. We'll be releasing 6.5.0 officially on the 18th

David:  Is this happening in the 6.5 release for you still?

Moving to 6.5.1 pending David reproducing this in 6.5.

David? We're preparing to release 6.5.1 shortly - would like to know if this is fixed for you in 6.5.0 or the 6.5.1 nightlies.

Thanks

(In reply to comment #25)
> David? We're preparing to release 6.5.1 shortly - would like to know if this is
> fixed for you in 6.5.0 or the 6.5.1 nightlies.
> Thanks
Hi Dan,
I have not tested it on my linux box because I've got some problems installing 6.5.0. I've installed a beta version of 6.5.0 earlier (deb package), removed it and installed the official release. Installing it went succesful but I can not start the server. The slimserver script in /etc/init.d/ is not installed or disappeared.
Probably this is no bug so I won't bother you with this problem. Have to sort it out using the forums.

Anyway, I've tested it in vmware (clean ubuntu session without previous slimserver versions). Installation ok, and the bug did not appear. So I assume it is fixed although there might be a little chance the problem still exists in a non-virtual environment.

Is it possible to reopen this bug as soon as I'm able to get 6.5.0 running on my Linux box and the bug reappears?

Thanks anyway for the excellent support.

David

Yes, it is possible to reopen a bug if you see it again.

Thanks