TuneNet bug ("._volume name:")

Found a "bug" in TuneNet. If you open a file that is directly in the root of a volume (f.e. "Shared:rainstorm.tfd") you will get requesters asking for volumes "._Shared:" and ".AppDouble/Shared:".

I guess it is assuming that the last component in the path is a directory name.

@salass00

Hi,

I can't recreate that bug. Are you sure it's not a problem with a particular plugin? Does it occur on mp3 files for example?

Cheers,
Bean.

@bean

Not with mp3, but it does happen with protracker modules, .cym/.gym (YMAmp plugin) and .tfd (TFM plugin), .2sf.

Probably more that I haven't tested. I don't think there is much, if anything in common with these plugins.

I am using the skinnable version of TuneNet if that matters.

TN_TFM.tnplug uses PLM_FileLoad:
http://os4depot.net/?function=showfil ... /tunenet/tunetfm_plug.lha

TN_YMAmp.tnplug uses PLM_File and IDOS->Open():
http://os4depot.net/index.php?functio ... unenet/tuneymamp_plug.lha

[edit]

Strangely it doesn't happen with s98 though. What makes this plugin different?

Bump?

@salass00

Can you try the following.

1/ Empty out all plugins except the defaults, and try to recreate the problem. If not then...>

2/ Add a single plugin in one at a time and try to recreate.

You'll have to restart TuneNet each time.

I think it's probably a bug in one of the plugin detections (Test) functions. Where by it's doing an extensive test on the file (not just filename or first few bytes) and that is making it fall over.

Also try all the above from RAM DISK: as well.

Let me know how you get on, I've got some time this weekend in between GT5 to look further into the problem

Cheers,
Bean.

@bean

I did some checking by removing all plugins and adding them back one by one and it seems that it is the SNDFile plugin that is the cause of all problems.

Being a bit lazy I just used the following as TestPlayer code in this plugin:
Quote:

@salass00

Good to hear you've found it!

Cheers,
Bean.