v2.1.46 b515: PFL Player 'steals' duration at EOF after song position move

[Cad]

The total duration of items in the 'Properties' PFL/file tagger Player irreversibly reduces by ~50-60mS on each EOF following a song position move.  The only way to display the true duration again is to reload the file (or close and re-open the Properties dialog).

For example: open file tagger and load a file.  STOP and zero it and note the Remain time.  For example, let's say it is 02:44:26.  Now click Fade Out, then click TEST and let the song play to the end.  Now zero it again and note the Remain time has decreased by 0.05 or 0.06 seconds (in this example, 02:44:20).  Repeatedly clicking TEST (or otherwise moving the 'pointer' e.g. by END MON or drag the bar) reduces the Remain time each and every time.

Worse still, Fade Out starts playing later and later in the track, as if it is relative to the (decreasing) track duration.  You can eventually end up with no (APPARENT) Fade Out time at all!

I think we had a similar problem some versions ago, which was fixed; but it seems to have cropped up again, in build 515 onwards, as far as I can tell?  Build 509 (the last one I tried) seemed AOK.

(And yes Torben, I've posted this in bugtracker.
--
BFN
CAD

[Torben]

Can you please check whether the error goes away when you enable BASS_STREAM_PRESCAN?

I suspect that BASS.DLL reports a wrong duration at EOF.

[Cad]

Can you please check whether the error goes away when you enable BASS_STREAM_PRESCAN?

Unfortunately, the bug remains with BASS_STREAM_PRESCAN=on.

I suspect that BASS.DLL reports a wrong duration at EOF.

I agree, but it's even worse than that, because each EOF 'removes' another 0,05 or 0,06s from the reported duration.  This makes trying to check and/or move a near-EOF Fade Out cue point difficult, frustrating, and in some cases, nearly impossible!

This is the [BASS.DLL] section of my mairlist.ini file, in case that helps?

Code: [Select]

[BASS.DLL]
PlaybackBuffer=2000
UpdatePeriod=100
Plugins=
FileManagement=off
ForceMultichannel=off
BASS_STREAM_PRESCAN=on
NetworkBuffer=5000
NetworkPreBuffer=75
BASS_SAMPLE_SOFTWARE=off
BASS_SAMPLE_FLOAT=off
ForceMultichannel1=off
ForceMultichannel2=off
ForceMultichannel3=off
DriverOptions=39421
IgnoreSpeakers1=off
IgnoreSpeakers2=off
IgnoreSpeakers3=off
--
BFN
CAD

[Torben]

I agree, but it's even worse than that, because each EOF 'removes' another 0,05 or 0,06s from the reported duration.

That's not generally true. I've checked that with several files - most of the time, it decreased by 0,01 once or twice (if at all) and then increased back to the original duration.

What kind of files are you talking about anyway? MP3?

[Cad]

Sorry!  Yes they are all MP3 files, all 128kbps CBR.  The 'shrinking' definitely occurs here, is definitely 'progressive/cumulative,' and happens on every MP3 file I've tried here so far (about ten files).  If you wish, I can take a 'screen movie' and send it to you?

[later]  Hmm … seems to be happening with b506 and b505 as well, so I'll reboot that PC and try again!

[even later] No, no different after reboot, still happening on every MP3 file.  The problem DOES NOT happen with WAV files; and seems to happen once temporarily (corrects itself when rewound to zero) with the sample TEST.OGG file supplied with mAirList.  I've also noticed that the amount 'stolen' from an MP3 file at EOF appears to be directly proportional to the duration (longer file = more mS 'stolen' at EOF); so a thirty second MP3 jingle 'loses' maybe 0,01s each time whereas a three minute MP3 song loses ~0,05s each time.

Otherwise, please let me know if you need any more info., or the full set of my INI files.
--
BFN
CAD

[Cad]

I've just checked this on a second PC (different maker, different soundcard) and the problem with MP3 files is the same/similar.

On the 'second' PC:

• about 0,01 or 0,02s is being 'removed' from total duration at each EOF event
• sometimes this 'stabilises' and does not continue to 'creep' after 2 or 3 EOF events
• resetting the MP3 file to zero does not correct the duration: that always requires a reload of the file

You know, I'm almost certain there was a similar problem which we already fixed; but though i have tried, I can't find any earlier posts in here about it.  I think it was maybe 9 months to a year ago?
--
BFN
CAD

[Torben]

If I recall correctly, the other issue was related to the slider position at EOF. According to the Subversion log, I included the bugfix on January 28th, 2007. This might help you to locate the forum thread.

[Cad]

Thank you!  Found it: http://forum.mairlist.com/index.php/topic,1284.0.html is the previous time this happened.  I'll go and make sure that I have STREAM_PRESCAN, FileManagement, AND Hardware mixing all switched on, then I'll test it again.
--
BFN
CAD

[Cad]

Kudos to Herr Doktor: I have now fixed this bug, thanks to his pointer to the original topic.

What I had forgotten/not realised is that mAirList now stores Device settings separately for each Player, each PFL Player associated with a Player (or the Cartwall), and the 'Extra PFL' Player.  I was changing STREAM_PRESCAN only in the [BASS.DLL] section of mairlist.ini >SIGH!<.

In each Player's/PFL Player's Device settings, file management is on by default but STREAM_PRESCAN is OFF by default.  After using Config to switch STREAM_PRESCAN ON for each Player's/PFL Player's Device (a bit of a chore when you have two Playlists with three Players each ), everything is working correctly and the File Tagger no longer 'steals' duration when the OnEOF event fires.

THANK YOU!

Torben: could you please update Mantis to mark this Issue 'closed/fixed/no action needed' and also please add a note to the Issue that the 'fix' is to set STREAM_PRESCAN on EACH Player/PFL Player?  Thanks in advance.
--
BFN
CAD

[Torben]

Done.