PDA

View Full Version : cue file problem



Xantia38
2005-07-22, 08:54
Hello,

I have a problem with the new 6.1.0 and 6.1.1 releases. My music is in wav files and the track info comes from cue files. The new server versions recognize both files, but when I try to play music, I get an error message: "Problem: can't open file". The server seems to run well as it does properly recognize MP3 files.

Needless to say that all cue and wav files worked perfectly with the previous SlimServer version 6.01. Between tests I always clean the database completely so that it get's a chance to reestablish itself under new conditions.

Thanks for any help you may provide,
Wolfgang.

Details:
- server 6.1.1, running on Win XP Pro
- all file types, except wav-wav and mp3-mp3 are disabled
- here is a copy of a cue file: (only the first two tracks are shown)

FILE "Barclay James Harvest ~ Berlin.wav" WAVE
TITLE "Berlin - A Concert For The People"
PERFORMER "Barclay James Harvest"
GENRE "Pop & Rock"
CATALOG "3259180002626"
TRACK 1 AUDIO
TITLE "Berlin"
PERFORMER "Barclay James Harvest"
BAND "Berlin - A Concert For The People"
YEAR "1982"
GENRE "Pop & Rock"
ISRC GBF068200010
INDEX 00 00:00:00
INDEX 01 00:00:32
REM END 05:41:07
TRACK 2 AUDIO
TITLE "Loving Is Easy"
PERFORMER "Barclay James Harvest"
BAND "Berlin - A Concert For The People"
YEAR "1982"
GENRE "Pop & Rock"
ISRC GBF068200020
INDEX 00 05:37:39
INDEX 01 05:41:07
REM END 10:22:32

- here is a d_parse log trace: only the last two tracks of the cue file are shown, followed by a series of error messages. This trace was done with 6.1.0, but the problem remains under 6.1.1.

2005-07-22 06:13:55.1403 URL: file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#2434.56-2784.36
2005-07-22 06:13:55.1404 TRACKNUM: 8
2005-07-22 06:13:55.1404 TITLE: Child Of The Universe
2005-07-22 06:13:55.1405 ARTIST: Barclay James Harvest
2005-07-22 06:13:55.1405 BAND: Berlin - A Concert For The People
2005-07-22 06:13:55.1406 YEAR: 1982
2005-07-22 06:13:55.1406 GENRE: Pop & Rock
2005-07-22 06:13:55.1407 ALBUM: Berlin - A Concert For The People
2005-07-22 06:13:55.1407 URL: file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#2784.36-3111.73333333333
2005-07-22 06:13:55.1408 TRACKNUM: 9
2005-07-22 06:13:55.1408 TITLE: Hymn
2005-07-22 06:13:55.1409 ARTIST: Barclay James Harvest
2005-07-22 06:13:55.1409 BAND: Berlin - A Concert For The People
2005-07-22 06:13:55.1410 YEAR: 1982
2005-07-22 06:13:55.1410 GENRE: Pop & Rock
2005-07-22 06:13:55.1411 ALBUM: Berlin - A Concert For The People
2005-07-22 06:13:55.1523 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#0.42666 6666666667-341.093333333333
2005-07-22 06:13:55.1956 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#341.093 333333333-622.426666666667
2005-07-22 06:13:55.2245 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#622.426 666666667-1071.56
2005-07-22 06:13:55.2520 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#1071.56-1356.33333333333
2005-07-22 06:13:55.2794 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#1356.33 333333333-1722.56
2005-07-22 06:13:55.3066 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#1722.56-2187
2005-07-22 06:13:55.3351 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#2187-2434.56
2005-07-22 06:13:55.3627 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#2434.56-2784.36
2005-07-22 06:13:55.3901 parse: Couldn't process anchored file fragment for file:///E:/AV/New%20recordings/Barclay%20James%20Harvest%20~%20Berlin.wav#2784.36-3111.73333333333
2005-07-22 06:13:55.4259 returning: 9 items

Xantia38
2005-07-22, 10:33
Hello,

after further investigation I believe to have found the problem. Maybe someone with better understanding of Perl and the SlimServer code can help me with this:

All my cue file entries have an END statement for each track, including the last one. This is done by the program which generates the cue files.

In SlimServer, the code in Parse.pm reads the cue file with sub readCUE, which calls parseCUE and later on processAnchor. This latter, processAnchor, will check whether $attributesHash->{'SECS'} has a value, which can only have been generated by the line 314:
my $track = $ds->updateOrCreate({
'url' => $filename,
'readTags' => 1,
});

However, this line gets only called when at least the last track in a cue sheet doesn't have an END statement and the length of the wav file needs to be read from that file itself.

To test the "theory" I removed the last END statement from my cue file and indeed, this solves the problem.

I think this is a bug, because the code makes false assumptions. It also makes the code behave differently from previous versions of SlimServer. And last, but not least, this removes a nice feature, which allows to have multiple cue sheets for a given wav file.

Can someone with better understanding of all this please check this. I can then file a bug report.

Thanks,
Wolfgang.

Ben Sandee
2005-07-22, 10:45
> Can someone with better understanding of all this please check this. I
> can then file a bug report.

Wolfgang,

Go ahead and file a bug report right now -- don't wait for someone to
tell you "yes it's a bug". You've done the research yourself.

Ben

kdf
2005-07-22, 11:02
Quoting Xantia38 <Xantia38.1sl0kb (AT) no-mx (DOT) forums.slimdevices.com>:

>
> Hello,
>
> after further investigation I believe to have found the problem. Maybe
> someone with better understanding of Perl and the SlimServer code can
> help me with this:
>
> All my cue file entries have an END statement for each track, including
> the last one. This is done by the program which generates the cue
> files.
>
> In SlimServer, the code in Parse.pm reads the cue file with sub
> readCUE, which calls parseCUE and later on processAnchor. This latter,
> processAnchor, will check whether $attributesHash->{'SECS'} has a
> value, which can only have been generated by the line 314:
> my $track = $ds->updateOrCreate({
> 'url' => $filename,
> 'readTags' => 1,
> });
>
> However, this line gets only called when at least the last track in a
> cue sheet doesn't have an END statement and the length of the wav file
> needs to be read from that file itself.
>
> To test the "theory" I removed the last END statement from my cue file
> and indeed, this solves the problem.
>
> I think this is a bug, because the code makes false assumptions. It
> also makes the code behave differently from previous versions of
> SlimServer. And last, but not least, this removes a nice feature, which
> allows to have multiple cue sheets for a given wav file.
>
> Can someone with better understanding of all this please check this. I
> can then file a bug report.


I believe this is an existing bug. I think there used to be a problem with the
last track in cue files, which was solved by the special case you mention
above. Clearly this is resulted in a problem for the cue sheets that are
generated by your application.

Does this seem on track?
http://bugs.slimdevices.com/show_bug.cgi?id=656

Take a look at the first few comments, as the later ones started getting into a
different issue.

If this is applicable, please re-open or file a new bug (referencing the old one
as the cause, if applicable)

-kdf

Xantia38
2005-07-22, 11:22
Quoting Xantia38 <Xantia38.1sl0kb (AT) no-mx (DOT) forums.slimdevices.com>:
[color=blue]


Does this seem on track?
http://bugs.slimdevices.com/show_bug.cgi?id=656

Take a look at the first few comments, as the later ones started getting into a
different issue.

If this is applicable, please re-open or file a new bug (referencing the old one
as the cause, if applicable)

-kdf

KDF,

Thanks for your reply, but I am not sure this is the same bug. They may be related though. In my case, all tracks are listed in the SlimServer listings, including the last one.

What is strage is that the errors shown in d_parse are genered by processAnchor because either start, end or "SECS" is missing. Given that the d_parse log shows start and end times as part of the track URIs, I assume the "SECS" piece is missing. Normally this piece is added by calling updateOrCreate when there is no END statement for the last track (line 314 in the Parse.pm file).

However, at line 438, sub readCUE calls updateOrCreate just in case before it calls processAnchor, so the information should be there, but it isn't. This is where my knowledge of the system stops. A possible fix may be to call updateOrCreate in any case while still in the parseCUE subroutine.

Wolfgang.

Xantia38
2005-07-22, 11:32
KDF,

After looking at the code, I agree with you that what is listed as the patch for bug 656 has been removed from the Parse.pm file and the original line is back in there. This is line 341.

I do not know how to compile the Perl code to do my own testing. Otherwise I would be of more help here.

Thanks again,
Wolfgang.

kdf
2005-07-22, 11:40
Quoting Xantia38 <Xantia38.1sl3cb (AT) no-mx (DOT) forums.slimdevices.com>:

>
> KDF,
>
> After looking at the code, I agree with you that what is listed as the
> patch for bug 656 has been removed from the Parse.pm file and the
> original line is back in there. This is line 341.
>
> I do not know how to compile the Perl code to do my own testing.
> Otherwise I would be of more help here.

That's fine. Do not worry. youve given lots of info already. Cue sheets are a
known problem, and a complex one due to the variations in content, and the
inredibly rapid changes in the data that slimserver requires. This should be a
bit more stable now, so these other issues can hopefully start making more
progress.

If you are curious, you can download ActivePerl from activestate.com and run
slimserver.pl instead of slim.exe. This will then use the perl code directly
without the need to compile.
-kdf

Xantia38
2005-07-22, 12:05
Thanks for advice, KDF. I'll start playing around with it.

There are a few other things I wanted to "customize".

Wolfgang.