Forget this.
I found some other related problem which most probably is the real cause. Now I must find in the code where this happens. Won't be today, and for sure not "your today".

Kuo-Yao,

It is correct that the timer stops a bit before the end when another track is coming up.

I found *the* problem though, and right now I am working on a decent solution. Should be in this topic within an hour.

Thanks for your effors,
Peter

Found this one 500 meters from my house (this is really true). I could move to there of course, but first I'll investigate getting a cable from here to there.


This one's 150th birthday was celebrated some three months ago. Must have real ancient power.

Yeah, and in the mean time I am pulling my hair out here.

With "the DAC running too fast" I meant that it consumes more that 44100 samples per second. Thus, a file indiciated as taking 4:00 minutes, is finished at 3:51 etc.

Could you please measure this ?

Note that the times as indicated in the playlist are not 1:1 derived from the track data, but -depending on your ripping means- from tag data in the file which could be just wrong. In that case the DAC doesn't need to be too fast, but the same problem results.

Looking at the log files I can't think of anything else, than things being wrong in the timing area. I must say though that


this really makes me wonder. This can only happen when the "Split file at size" is set low, so to avoid confusion with this one, now please set it real high again (like 2500). Again, only for testing.

So, start a track, and press the stopwatch when you hear sound (better have some popular music that starts at once loudly). Stop the stopwatch when no sound is there anymore. Note that usually this is 2 seconds before the selection bar turns on at the next track. This is the usual gap in between songs. So, do not stop the stopwatch when the selection bar reappears ... you are two seconds late then. Just when the music stops.




PS: The dragging of the timer pointer is totally unrelated; dragging it towards the end indeed may cause anomalies. It should of course not crash the computer, so I will look into that (never did it, while knowing things go wrong there).

Edit : Actually I don't think you will find anything wrong with this. I already saw that things are not dealt with 100% right, or IOW all was explicitly made for Unattended (I just didn't think of Attended to much at creating the new method in 0.9w), but in the mean time I don't see how things go wrong.
Additionally, I recall my own not being able to copy it anymore, while before each track would go wrong (which I blamed the compiler for).
But please let me know the stopwatch results anyway, so it can be excluded as the cause !

I can make the dealy it longer or even make a parameter for it. But note that at each click the delay time is reset to 0.
Switching from going up to going down is a kind of Olympic sport, yes. Trainikng Biathlon will help I guess. Especially shooting.

Hahaha, no, I am sorry !
(not that I don't want, but this is just not possible (anymore)).

Peter

You seem to refer to something that someone (probably I) mentioned as a negative ? or ?
I most certainly did not intend to ...

Well, currently I really don't know how to proceed on this one. Maybe this tip helps you at helping me what is going on :

At a "No Track given" error, XXEngine3 expects a next track to have been prepared by XXHighEnd. There is 14 seconds to do so before XXEngine3 gives up and presents the message.
Now, when you look at XXHighEnd (Attended) you'll see the selection bar disappearing, which is the time XXHighEnd starts preparing the track. "Preparing" means a.o. conversion from FLAC to WAV when in order. After this XXEngine3 has to do some things as well, and this is included in the 14 seconds. Thus, the time XXHighEnd needs plus the time XXEngine3 needs can last 14 seconds at maximum.

There are a few reasons (besides bugs ! -> appearently there was a bug also, since solving something solved it for Leo) that these 14 seconds can be too short :

1.
The disk where the file has to be loaded from is sleeping and has to spinup. This takes time, and how long depends on the drive.
This reason by itself should encourage you to test with files on the OS disk. Chances are little or zero that this disk will sleep ever.

2.
The drive is very slow or the track is very long (and the combination of course). For example, an USB disk just *is* slow.
This reason by itself may encourage you to test from a drive of which you know it should be fast. Direct SATAII is the fastest (for consumer PCs).
Do not tick "Copy to XX-drive by standard" (at testing this).

3.
The CPU is not the fastest. Note that this sure is not about the clock speed only, and things like second (lots of) level cache contribute highly to the speed. For example, might you hace a Celeron CPU, I'd almost say "drop that".
The CPU is needed within the preparation stage of XXEngine3, and it is also needed within the preparation stage of XXHighEnd when conversions need to take place.
This reason by itself should encourage you to test with native .WAV files first.
Also, do not tick the "AA" checkbox.
Note : To me it seems logic that your CPU might nog be the fastest, because the changes from 0.9v to some later version from 0.9w(-5 I think) are about more CPU activity in XXEngine3. If I am right on this, you should (for testing purposes) set "Split File at size" to the minimum of 12MB. Furthermore you can tick the Mem checkbox (main area) which avoids an in-memory copy, and lastly you could tell the system (again for these test purposes) that your DAC is 16 bits.

4.
Your DAC runs too fast.
When the DAC runs too fast, XXEngine3 will be finished with the track earlier than XXHighEnd expects. Note that the time bar from XXHighEnd is unrelated to the actual playing position from XXEngine3.
To check this, you should take your stopwatch and measure tracks for their consumed length. If a 5 minute track is over 2% fast, you will run into problems. Besides that you will have another problem.

Please let me know if you can make it work by means of the above "tweaks", and which one(s) did it, if so.
If nothing helps, don't forget to send me the log files, as I asked for earlier.



Now this is something that really smells to something else being very wrong, most probably related to the other problem;
I really can't think of what, because repositioning this slider actually does nothing. However, it will restart XXEngine3 and incurs for some temporary heavy load. Is this bad ? I wouldn't know why except for encouraging for some additional delay in things. But this hanging up the whole PC ?

This occurring phenomenon makes me believe you should try another PC if available. From there on you possibly can learn what is actually going on.
But note : Somehow you call this "fast forward" while really it is nothing of that kind. It just skips (or goes back to whatever position you dictate). Now, you could be just clicking besides the slider to skip a piece of the track, or even hold down the mouse button and move it around. The latter will let skip the pointer faster than holding it still. However, this will start XXEngine3 over and over and over and *that* may incur for a total system crash.
So if you are dowing it like this instead of picking up the pointer and dragging it to somewhere else ... don't. Also, don't pick it up for dragging when playback has not commenced yet.

Well, good luck with all, and keep in mind : there still can be a normal stupid bug in there.

Peter

Allright, never mind. I think I could mimic the behaviour, and the only thing I can't be sure is whether I did that at the right place in the code. This is for you to check in 0.9w-8 (later).

Btw, you didn't send me that email I think. So if you could paste the same in an email body (not as Notepad attachment -> you actually did that in here), I guess I can make unicode of that (if it not already it).

If you don't know the email address, it's in your activation (or PayPal) email.
Thanks !

Sadly, when I create a folder structure of this, it doesn't error. But now I wonder :

Does the below look like you can read it ... I don't think so. So in the end I will be doing it not the same aas you have it.

Hey, I think that is very helpful.
Ok, I will build in "some" solution that at least the error won't show. At this moment I am not sure though whether specific functionality can be maintained in that case, but we'll see.

Regards,
Peter

Kuo-Yao,

Thanks. When you say this is the only track, but you say also :


Do you mean that you have one track which chinese characters in them, or you have several but only this one goes wrong ?

Can you please switch on Loggin (Settings Area), let it go wrong for at least one time, and send me both the XX and X3 log files ? Please be sure that you send all the X3 files from your session where it goes wrong (look at the date/time which is in the file name). Better send too many than too few.

Thank you,
Peter