Bug 2198 - Playlists intermittently broken, display with track ID rather than name
: Playlists intermittently broken, display with track ID rather than name
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 6.2.0
: PC RedHat Linux
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-26 06:07 UTC by Jeff Coffler
Modified: 2008-09-15 14:36 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
SlimServer log file with d_parse and d_source enabled (101.87 KB, text/plain)
2005-09-27 09:21 UTC, Jeff Coffler
Details
Playlist file for ZooFiddle playlist (3.69 KB, text/plain)
2005-09-27 09:21 UTC, Jeff Coffler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Coffler 2005-09-26 06:07:26 UTC
I'm having problems with Playlists on a 9/17 nightly of 6.2 as well as a 9/25 
nightly of 6.2.

If I have a playlist and browse to it (via the CLI or via the WWW interface), 
and then queue it to play, it fails to play.  No errors appear 
in /tmp/slimserver.log.  If you let me know what debug flags to enable, I'd be 
happy to try again and post more details.

I've noticed the following symptoms:

1. If a playlist will be "broken" (i.e. not play), then 'playlisttracks' in 
the CLI will return the track # rather than the track name,

2. If a "broken" playlist is queued to play, then the CLI 'status' command 
will list the track ID in the title field with no further information for the 
item (no artist or album),

3. I can duplicate this via the WWW interface.  If I pick a "broken" playlist 
and queue it to play, then the WWW interface will show entries like "602 
by", "603 by", "604 by" (etc) for each song in the playlist.

4. Some playlists work fine, some don't.  I regenerated a failing playlist 
from scratch via the WWW interface, saved it again, and then reproduced the 
problem again.

Doing a new search for playlists (in the WWW interface) made one failing 
playlist work and another working playlist fail ...

Any advice or suggestions would be appreciated, thanks.

I was using 6.0, and had no problems at all with playlists.  I couldn't run 
6.1 due to playlist issues within the CLI.  Since those were recolved in 6.2, 
I moved to 6.2 (and updated my SlimServerMod module for AMX N4tLinx automation 
systems to use it), but then came across this problem.

Thanks in advance ...
Comment 1 KDF 2005-09-26 09:34:33 UTC
Have a look at bug 2189.  Likely a related problem, possibly a dupe.
Comment 2 Jeff Coffler 2005-09-26 09:47:44 UTC
Bug 2189 looks different.  My playlist files appear correct.  It's just the 
WWW (and CLI) interfaces that are screwy (and the fact that I can't play the 
files).

It sounds like it may be the same root problem, though ... (unsure).
Comment 3 Fred 2005-09-26 10:01:42 UTC
Could this be related to bug 2028 ? Same general idea, in that DB items are not reported correctly at times 
by the proper function calls.
Comment 4 Jeff Coffler 2005-09-26 14:13:29 UTC
Bug 2028 looks different too.  I specifically did NOT get any warning messages 
at all in my log file (/tmp/slimserver.log) when this problem occurs.  No 
adverse warnings are printed - the playlist simply doesn't work.
Comment 5 KDF 2005-09-26 15:59:34 UTC
jeff, do the same playlists always fail?  Please attach one to this report, also
add a section of log for d_parse and d_source when you try to play the playlist.
Comment 6 Jeff Coffler 2005-09-27 09:19:27 UTC
Okay, I have some more information.  Sorry it took me a bit to gather it for 
you.

>Jeff, do the same playlists always fail?

Always striving to give concise answers: "Uh, sort of."

When a playlist fails, that playlist fails repetitively.  I couldn't shake it 
with the "ZooFiddle" playlist (attached here) until I deleted it and recreated 
it.

When I deleted and recreated ZooFiddle, it then started working.  However, 
after following the steps below, it failed again.

Here's my sequence of steps in reproducing this:

1. Move a lot of playlists out of my playlist directory (I did this because of 
this issue that I originally found, and wanted to reduce the footprint of 
playlists to help isolate).  Note that ZooFiddle.m3u was moved out as well,

2. Rebuild the entire database (from scratch),

3. An oddity: When the scan completed, I tried to queue one of two playlists 
that remained in the playlist directory, and the problem reproduced.  When I 
cleared the playlist, enabled the debug flags you specified, then tried to 
reproduce, I couldn't.  I'm guessing that the problem reproduces after a scan 
for some period of time, then stops (perhaps some housekeeping is still going 
on just after a scan completes?).

4. Move the playlists back into the playlist directory.

5. Rescan just playlists.

Now the problem reproduces quite consistently.  I've attached slimserver.log 
(with d_parse and d_source enabled) as well as a copy of the playlist, 
ZooFiddle.m3u.

Another oddity that I noticed: When I did #5 above, the rescan never appeared 
to complete (it was running the next day).  However, if I restart the server 
and then rebuild the entire database from scratch, the database does build 
correctly and does finish.  I'm certain that I have no links in my music 
directory, just a whole buncha music files (266 albums with 3757 songs by 131 
artists, all in FLAC format).

Let me know if you need more details or information.  At this point, all of my 
playlists work EXCEPT ZooFiddle.  I'm confident that if I delete and recreate 
ZooFiddle, it'll begin to work as well (but I don't want to do that unless you 
guys want me to test further).
Comment 7 Jeff Coffler 2005-09-27 09:21:02 UTC
Created attachment 865 [details]
SlimServer log file with d_parse and d_source enabled
Comment 8 Jeff Coffler 2005-09-27 09:21:37 UTC
Created attachment 866 [details]
Playlist file for ZooFiddle playlist
Comment 9 Dan Sully 2005-09-27 13:19:46 UTC
This should be fixed in subversion change 4438