Cue file tracks are multiply duplicated in the loaded Foobar playlist

[jerryosity]

When a foobar playlist contains tracks from within a cue file, foo_xspf generates the xml as expected, but when you load the xspf into Foobar, the newly created playlist contains multiply duplicated entries. For example, if you have a cue with 12 tracks, foo_xspf will generate 12 duplicated sets of the 12 tracks in the loaded Foobar playlist -- the duplications are not present in the xspf file.

[Using foo_xspf_1 in foobar2000 v1.3.9]

[Chocobo1]

Can you post a small sample (the generated xspf of course) here? And what are you trying to achieve?

[jerryosity]

Thanks for the prompt reply. I am trying to use foo_xspf to globally change the file locations across my Foobar2000 playlists, since I have consolidated my music drives and paths have changed. (I want to save to xspf, search and replace the text, then reload back into Foobar.) I can't do this location change within Foobar directly because I do not use the Foobar media libary feature and don't want to.

Most of my music tracks are in cue files on single CD images. That's where I have the problem. For example, I have a playlist containing 14 tracks, all from a single cue file. I save it to an xspf, and all looks fine. See attached xspf file. CueFileTracks.txt I then globally replace the file locations in the xspf and reload back into Foobar2000. I should then see a new playlist with just the 14 tracks. Instead, the new playlist contains 14x14 = 196 tracks: The set of 14 tracks is duplicated 14 times in the playlist.

[Chocobo1]

I think I know where the problem is, but it will need time to fix & test.

I cannot guarantee this will be fixed in a timely matter.

[jerryosity]

Ok. I'll be happy to beta test the change, Mike. I suspect this is happening because the basic action of Foobar2000 when you load a cue, is to load all the tracks in it. Don't know if you have the means in the SDK to specify that just a track of the cue should be loaded or if you can work around this in a hook/callback when the XML parser processes the element. If not or it's too messy, I could live with a change that at least loads all the tracks from the associated cue, but just once, even if the playlist only contained selected tracks.

[Chocobo1]

Ok. I'll be happy to beta test the change,

Here's a version for you: foo_xspf_1.zip

Also note that you should make sure the following settings are checked:

• Read -> <location>
• Read -> <trackNum>
• Read -> Disable resolving <location>

[jerryosity]

Mike, you have resolved the cue issues with this fix! One problem remains: the value for the cue file itself is missing the "file:///" prefix in the xspf file and thus, when loaded into Foobar, the track can't be found.

I tested a playlist containing a mix of selected cue tracks and standalone flacs mingled together, and the resulting loaded entries appeared as totally expected, except for the cue track location issue mentioned above.

Mike Tzou mailto:notifications@github.com Thursday, January 28, 2016 01:20

Here's a version for you to verity: foo_xspf_1.zip https://github.com/Chocobo1/foo_xspf_1/files/107756/foo_xspf_1.zip

Also note that you should make sure the following settings are checked:

• |Read -> |
• |Read -> |
• |Read -> Disable resolving |.

— Reply to this email directly or view it on GitHub https://github.com/Chocobo1/foo_xspf_1/issues/1#issuecomment-176006843.

[Chocobo1]

"file:///" prefix in the xspf file and thus, when loaded into Foobar, the track can't be found.

Try uncheck the setting Write -> Use relative path whenever possible.

If all problems are gone, I'll bump the version and release new version also I guess I need to put some explanation for the settings on the project page...

[jerryosity]

Unchecked it but the problem remains.

Separately, what do the options for partial and multiple match do?

Mike Tzou mailto:notifications@github.com Thursday, January 28, 2016 09:47

Try uncheck the setting |Write -> Use relative path whenever possible|.

If all problems are gone, I'll bump the version and release new version also I guess I need to put some explanation on the project page...

— Reply to this email directly or view it on GitHub https://github.com/Chocobo1/foo_xspf_1/issues/1#issuecomment-176220042.

[Chocobo1]

Unchecked it but the problem remains.

This is weird :\ Can you regenerate a new xspf playlist after unchecking that setting? And post it here. The xspf on your second post did have file:/// prefix.

Separately, what do the options for partial and multiple match do?

When not using the info in <location>, foo_xspf_1 will try to match the data provided (for example <title>, if it's setting is checked) with tracks in fb2k media library and thus could result in multiple matches. If not checked, only 1 of all matches will be added to fb2k.

When partial match is checked, providing The will match The song & ... the end. Otherwise only tracks that exact match will be added.

[jerryosity]

Mike, my mistake. Ignore this. The fix works fine! Go ahead and release it. You can use the explanation below for the change, if it's useful. Once you release it, I will post news of the fix on my thread at the Foobar support forum.

FIXED: When loading xspf files that cite tracks inside cue files, all the tracks in the cue would be loaded multiple times (one full set for each cue appearing in the xspf.) Now, only one track entry will appear in the created Foobar2000 playlist for each cue in the xspf file.

Mike Tzou mailto:notifications@github.com Thursday, January 28, 2016 10:15

Unchecked it but the problem remains.

This is weird :\ Can you regenerate a new xspf playlist after unchecking that setting? And post it here. The xspf on your second post did have |file:///| prefix.

Separately, what do the options for partial and multiple match do?

When not using the info in ||, foo_xspf_1 will try to match the data provided (for example |