[CHANGES MADE] [BUG] NSF/NSFe playlist incorrect for some files

[nelsonhf]

Hi, i'm using WACUP v1.99.47.23960 with the included NSF/NSFe Player (in_notyansf.dll) v0.9.7 and in some files the playlist gets an incorrect (larger) number of tracks than the actual file has (compared with another player like NSFPlay or plug-in). As an example this is the same file opened with WACUP and NSFPlay:

[dro]

I can reproduce this problem but I don't see why it's happening as it's just using what the nsfplug code is reporting back unless there's something that's changed between the standalone player & what's on github currently (couldn't see any obvious difference). Other nsfe I've thrown at it appear to be reporting the correct number of subsongs compared to what nsfplay is indicating which is odd but then some are also showing more than are expected so I'll have to do some more digging into what's going wrong here.

[edit]
Ok I think I get what's going on here. The files can have a 'playlist size' or a 'total song' which I'm using the later so everything that might be present is going to be extracted. I'm debating what to do & might have to add an option to the preferences to control which value is used when they're different (as your example shows it's a 16 track playlist but is reporting 54 songs though nsfplay doesn't seem to do that so I don't know if that's a quirk of the format or something else). Other ones I've given to it will show a playlist size & the tracks (maybe it's something about the metadata that's provided) so I'll see what I end up doing once I've thrown more files at this.

[nelsonhf]

Thank you, the issue has been fixed in the latest builds. A question: Is it possible to show the track names in the playlist? I tried using the ATF formatting but it only shows the %artist% and %filename% tags (it seams that the plugin doesn't return the tag %title%)

[dro]

I'll have to look into why title is missing as I hadn't noticed it tbh as my playlist items seemed to be showing it whereas it's only via the alt+3 dialog that it's obviously failing to fill the fields when there is the handling to return it like with artist & few other metadata values (which seem to be returned as expected from an initial look).

[dro]

It'll need a new build as the input plug-in is seemingly working fine but with the alt+3 aspect there's a problem with how the core is handling the look-up for filepaths ending like "nsfe::NSF,16,,,0,,0" which is already meant to be dealt with to extract it out as 'nsfe' but something is going awry which I've still to debug further (but have a simple change for that which is better to do anyway). I can't replicate the normal atf handling failing to get the metadata unless you've got those items in the local library & if so then you'll need to try refreshing them as the metadata from that is used instead of always going to the file.

[edit]
I can do it as part of a post-release update patch instead of needing to involve a complete so that'll go up in the next few days.