svn-1655 playlist bug?

[fizze]

Hi Ron,

I just discovered that in svn-1655 there seem to be some issues with status (m3u) playlists, that worked fined before.

Now, they only seem to have one file, althought that worked nice before. All playlists I checked do have a backslash isntead of a forward slash as a directory seperator, but as the first file always works flawlessly, I dont think thats a problem.

This playlist just shows up with the very first file, in this case MADRID_DE_LOS_AUSTRIAS_-_BR.MP3. It suer has worked fine since like svn-909 😉

Also, the path name contains a blank, so maybe this is related to escaping?
I’ll try to switch to a forward slash, and see what happens.

Here’s a sample of the playlist:

#EXTINF:459,Madrid de los Austrias  -  LoungeRadio ONE - Brooklyn Ole (Nickodemus & Osiris Remix)

LoungeRadio ONEMADRID_DE_LOS_AUSTRIAS_-_BR.MP3

#EXTINF:234,Koop  -  LoungeRadio ONE - Bright Nights

LoungeRadio ONEKOOP_-_BRIGHT_NIGHTS.MP3

#EXTINF:205,hooverphonic  -  LoungeRadio ONE - 2 Wicky

LoungeRadio ONEHOOVERPHONIC_-_2_WICKY.MP3

#EXTINF:3993,naked music  -  LoungeRadio ONE - Carte Blanche (The Aquanote Sessions)

LoungeRadio ONENAKED_MUSIC_-_CARTE_BLANCHE.MP3

The ls output looks like this:

//nsluzzle/public/music/compilations# ls LoungeRadio ONE/ -ral --sort=time

total 660404

-rwxr-xr-x  1 guest everyone  7346185 Oct  4  2002 MADRID_DE_LOS_AUSTRIAS_-_BR.MP3

-rwxr-xr-x  1 guest everyone  3753984 Aug  2 21:53 KOOP_-_BRIGHT_NIGHTS.MP3

-rwxr-xr-x  1 guest everyone  3293184 Aug  2 21:38 HOOVERPHONIC_-_2_WICKY.MP3

-rwxr-xr-x  1 guest everyone 63893459 Oct  4  2002 NAKED_MUSIC_-_CARTE_BLANCHE.MP3

edit:
Ok, the forward slash does not change this behaviour.

[rpedde]

@fizze wrote:

edit:
Ok, the forward slash does not change this behaviour.

I think that’s the line separator problem… I’ll take a look at this.

— Ron

[rpedde]

@rpedde wrote:

@fizze wrote:

edit:
Ok, the forward slash does not change this behaviour.

I think that’s the line separator problem… I’ll take a look at this.

— Ron

You could prove that by dos2unix’ing that file and seeing if it works. If so, I can easily have a fix next build.

— Ron

[fizze]

Ok, thats something i can try.
Weird thing is, that this files haven’t been changed and worked fine in previous nightlies. I’ll share my findings.

edit:
Alrighty, unixy lineendings do not improve the situation. Still same old.

[skellert]

I am also seeing a playlist problem with 1659 running on a fedora core 5 server and serving to a Roku M-1000.

Previously playlists worked fine. Now only the first file is being played. The playlists all have Linux line separators.

[fizze]

Ok, heres the debuglevel 9 output from that playlist scan:

2007-09-14 11:56:10 (00000400): About to scan /share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u

2007-09-14 11:56:10 (00000400): Scanning /share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u

2007-09-14 11:56:10 (00000400): Processing static playlist: /share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u

2007-09-14 11:56:10 (00000400): Executing: select * from playlists where path='/share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u' and idx=0

2007-09-14 11:56:10 (00000400): Opening file:///share/hdd/data/public/music/compilations/Lounge+Radio_ONE.m3u

2007-09-14 11:56:10 (00000400): opening /share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u

2007-09-14 11:56:10 (00000400): Executing: select count(*) from playlists where upper(title)=upper('Lounge Radio_ONE')

2007-09-14 11:56:10 (00000400): Executing: insert into playlists (title,type,items,query,db_timestamp,path,idx) values ('Lounge Radio_ONE',2,0,NULL,1189763770,'/share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u',0)

2007-09-14 11:56:10 (00000400): Executing: select id from playlists where title='Lounge Radio_ONE'

2007-09-14 11:56:10 (00000400): Checking /share/hdd/data/public/music/compilations/LoungeRadio ONE/MADRID_DE_LOS_AUSTRIAS_-_BR.MP3

2007-09-14 11:56:10 (00000400): Executing: select * from songs where path='/share/hdd/data/public/music/compilations/LoungeRadio ONE/MADRID_DE_LOS_AUSTRIAS_-_BR.MP3' and idx=0

2007-09-14 11:56:11 (00000400): Resolved /share/hdd/data/public/music/compilations/LoungeRadio ONE/MADRID_DE_LOS_AUSTRIAS_-_BR.MP3 to 6879

2007-09-14 11:56:11 (00000400): Done Scanning /share/hdd/data/public/music/compilations/Lounge Radio_ONE.m3u

Doesn’t look fishy to me, except for the fact that it aborts after the first file…

[rpedde]

@fizze wrote:

Doesn’t look fishy to me, except for the fact that it aborts after the first file…

Oooooh… yeah, that would be a bug, huh?

Wonder how the heck the config file reader is reading more than one line?

[fizze]

Yeah, I checked out the latest version from the trunk and couldn’t find anything.
Well, as previous versions worked fine, I guess it’s worth checking the revisions.

The last full scan I did was with svn-1463. Everything playlist-related was working fine then. Also was with 1655, until that full rescan 😉

Maybe thats file_io related? As i don’t recall any changes to r and n recently ?

[rpedde]

@fizze wrote:

Yeah, I checked out the latest version from the trunk and couldn’t find anything.
Well, as previous versions worked fine, I guess it’s worth checking the revisions.

The last full scan I did was with svn-1463. Everything playlist-related was working fine then. Also was with 1655, until that full rescan 😉

Maybe thats file_io related? As i don’t recall any changes to r and n recently ?

It was unrelated. it was in the playlist reader itself. I didn’t migrate it from fopen() to io_open() well.

The fix is in head as r1666. Sadly, I’m away from my build tools until Friday, so I won’t get a new build out until then.

— Ron

[Author]

Posts