Delay starting PFOA on a networked pc

[hdradio]

As I have told you, I have tested a file 16 hours long. That file was at the history list among other files.
Don't forget that we are talking for a networked pc. And as you have already told me, when you tried the same scenario, you also saw a huge difference loading very large files with Prescan off.

[radio42]

Are you sure, that it is your playback history window?
The playback history (as the name suggests) contains the last effectively played tracks - i.e. as last played from your regular/scheduled playlists.
Why would this window always contain files being 16 hours long? Or maybe it was simply the case, as you tested those suddenly...?!
Or do you may be mean the Explorer Window or the Trackboard?

However, all these windows do behave similar (like a regular playlist window), meaning by default, for the visible entries the most recent TAG data is being read in (to display that in the window).
So it is not, that all the playback history entries are being read at startup, but only the visible entries are read (to determine the current/most recent TAG data).

That is the same for the visible Trackboard entries, the visible Explorer Window entries, the Standby Players (if they contained loaded entries), the cartwall entries etc.
For all these visible entries (which are being restored) at startup of ProppFrexx either then most recent TAG data is read in resp. those entries are directly loaded/created (e.g. as for the cartwall entries or the Standby Players)...meaning, that file needs to be opened and read!

In the end, this is an 'unsolvable issue' when using (slow) networked devices, as what you experience is plain and stupid TAG reading resp. a file open/read:
- with the 'No Prescan' option disabled (default) this means 100% accurate duration determination and sample accurate seeking enabled
- with the 'No Prescan' option enabled this might means only duration estimation and sample accurate seeking disabled

So no matter if in your particular case the initial TAG reading was trigged by some 'very huge' playback history entries...this can happen at any time later as well!
E.g. assume you schedule such huge files for regular playback to a regular playlist ... or you would use 16 hour long files as cartwall entries ... the same would happen, simple TAG reading and pre-scanning of the file to determine its exact length.

That's one of the reasons, why I always claim, that a fast I/O sub-system is important.
(there are professional ultra-fast network storage solutions available for those type of usage scenarios, e.g. a Fibre-Channel based SAN)
But in the end it boils down to the same question: can commodity/consumer hardware be used for any usage scenario: yes it can, if you can live with certain limitations...
(but in reality I guess it is a rare case, that your frequently deal with 16 hours long files...and if yes, consumer hardware/networks are not what you should use; or you must live with some accuracy limitations)

[radio42]

Yes, of course we are talking about a 'networked PC' - that's why I explained all the above and talked about a fast I/O sub-system!
And yes, that's why I added the 'No Prescan' option...so that you can turn it off, if needed.
And that is why I explained the reason why 'Prescan' is enabled by default!

I am not sure what "...I should not forget..." ?
I guess the options are pretty clear:
- use a fast I/O sub-system and leave Prescan turned on (recommended) and exact duration determination and sample accurate seeking is guaranteed
- when using a slow I/O sub-system you can now turn if off; but get the mentioned limitations in return

In the end its pretty obvious: you can not get 'everything' for 'nothing'...