Bug 1826 – bad playlists can put slimserver into an infinite loop

Bug 1826 - bad playlists can put slimserver into an infinite loop

Summary:

bad playlists can put slimserver into an infinite loop

Status:	RESOLVED FIXED

Product:	Logitech Media Server
Classification:	Unclassified
Component:	Playlists
Version:	6.1.0
Platform:	PC All

Importance:	P2 normal (vote)
Target Milestone:	---
Assigned To:	Dan Sully

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-07-15 13:33 UTC by michael
Modified:	2008-09-15 14:36 UTC (History)
CC List:	0 users

See Also:
Category:	---

Attachments
infinite loop playlist (12 bytes, text/plain) 2005-07-22 14:13 UTC, michael	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description michael 2005-07-15 13:33:05 UTC

As of change 3507 (really 3508) scanning will follow playlists referenced by
other playlists, without dectecting loops.  With some bad playlist combinations,
this can cause the scanning to go into an infinet loop.  Previous to this
revision, bad playlists didn't cause noticible issues.

Obviously the right thing to do is to fix the bad playlists, but having loop
detection might prevent some amount of frustration and bug reports from
customers who don't realize they have them. (Especially since most playlists are
generated by automated tools.)

The simplest test case is an m3u file that refers to itself.

Comment 1 Dan Sully 2005-07-18 08:25:40 UTC

Michael - I've not able to be able reproduce this - I have a m3u file referring to another another m3u file, 
but parsing stops as normal.

Could you upload a specific test case?

Thanks.

Comment 2 Dan Sully 2005-07-19 14:12:38 UTC

Pushing this off post 6.1

Comment 3 michael 2005-07-22 14:13:59 UTC

Created attachment 661 [details]
infinite loop playlist

Comment 4 Dan Sully 2005-07-25 09:20:37 UTC

Fixed in subversion change 3795.