XXHighEnd

XXHighEnd began crashing today with the following error:

Problem Event Name:   APPCRASH
  Application Name:   XXEngine3.exe
  Application Version:   0.0.0.0
  Application Timestamp:   4e8c9903
  Fault Module Name:   CliSecureRT.dll
  Fault Module Version:   5.2.0.0
  Fault Module Timestamp:   4bed4d06
  Exception Code:   c0000005
  Exception Offset:   00001296
  OS Version:   6.1.7601.2.1.0.768.11
  Locale ID:   3081
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

This happened several times upon the completing the playback of some (but not all) tracks today. I have not changed the setup of XXhighEnd for at least a week and it has been working without crashing for several hours every day - up until today.

The only changes to the playback computer today were the addition of around 22 new FLAC files into my playlist (which I encoded directly from WAv files using DBpoweramp).

I am a bit stumped here as to what the problem is. I checked the internet for other similar error reports and in the few cases I found where such errors were reported, the developers of the software that crashed asked the users to update their software to the latest version (which apparently solved the problem).

Obviously I am using the latest version of XXHighEnd. I have had XXHighEnd crash a few times in the past but wasn't worried as I was still setting it up. But it seems strange to work fine and then I get these errors as soon as I introduce a large number of additional FLAC files to the playlist.

Hi Jon,

This for sure is the most strange;


Do you mean that tracks from before were still in the playlist and these were literally added to it (this is how I would interpret it). And, would you say this is repeatable for each of the tracks to which it happened before ?

What worries me is the module where it crashes which should be absolutely data (like dynamic data from tracks) unrelated.
Maybe it is so that now other tracks (non FLAC) fail on this too ? And if so, better maybe try tracks which played before. If they (some of them) now also fail, then I can't think of anything else than something have happened to your PC. But of that too I would say it is impossible ...

Far sought, but can't it be related to the name of the tracks ? Not that I know of any such situation for years, but in this case think of a hash code working out unexpectedly (and yes, I said it can't be data related, but it must be something ...).

Thanks,
Peter


PS: I'm almost sure I won't see anything from it, but if you switch on logging and grab/post the X3 and X3PB log files from after the happening ... who knows.

I must be a bit precautious;
Although I have never seen this, it can be data related if it's only related to the file header data. I mean, it still can't be coming from the failing module officially, but maybe that happens more often and people tend not to put up this detailed crash info. So, the fact that I didn't see this info before does not say it didn't happen before. And to this regard many sources of music files provide wrong header data. Also : quite a few of them have been solved for 0.9z-7 so if it is that ...

But *if* it is that, it should be completely repeatable by means of trying the NEXT track from the playlist where the error occured at the end of the playing one, and otherwise by means of combining those subsequent two again.
Might you find such a situation repeatable, please send me the one (or two when in combination) files via FileMail, so I can check whether it is solved here by now (and otherwise I will solve it).

What is the source ? Sample Rate and such ?

Thanks again,
Peter

I am suspecting it might have something to do with the naming of the tracks. The tracks were actually 11 pairs (so 22 in all as mentioned). Each track in the pair had identical names except for the last character only, which is a 1 or a 2. For example one pair might have been called "ibert_escales_paray_type_1.flac" and "ibert_escales_paray_type_2.flac" (the difference between type 1 and 2 was just the dithering algorythm I used to create the 16 bit files).

So I am going to make the names completely different and see if I can duplicate the error over the next few days. I do actually recall getting some odd error messages back when I first tried XXHighEnd. Back then I was using some really long names for testing purposes (like 20 plus characters).

Anyway, I will try to make the names dis-similar and see if the errors crop up again.

Also, just to answer your other question, sadly this is one of those problems I cannot reproduce 100% of the time. I have tried to get it to crash on those same files and it isn't at the moment (but I have not changed the playlist since remving it completely from the playlist window and refreshing it again. The original WAV files were ones created by me using Reaper (transcription from analogue vinyl LP). They are 24 bit, 48 KHz and I used Sound Forge Pro to create the 16 bit files, 48 KHz files. I then use dbpoweramp to create the corresponding 16 bit, 48 KHz FLAC files.

Okay, what slipped my mind also at the "hash code thing" now has come profound; It can well be that those 11 tracks with actually the same name won't work out to proper Dos 8.3 short names. It depends a bit how they look like, and you can see that in the XX log file.

Notice that an additional problem is created with the ".FLAC" which is 4 positions. So, that too has to be dealt with, and you will see in the log file how.

The length shouldn't be related (if it is this 8.3 thing at all), but the number of the now "same names" for the first 8 positions does.
Also you might focus on those underscores which again is an additiional difficulty for the OS to this regard; they won't translate to anything.
Lastly, I'm not sure how the 1 and 2 at the end relate to 8.3 names which are converted to numbers when too long; I think they shouldn't be invorporated at all (because not within the first 8 (or 7 for FLAC IIRC) positions.

Curious ! ...

OK, thanks Peter. Is there a "safe" substitute for my underscores? For example, a dash ("-"), or is it better to purely stick with alphanumerics only?

Ah, I didn't mean to say that underscores are not allowed. It is just that all "strange characters" are to be translated to numbers by that 8.3 mechanism. So, you already have long strings which for their left part are not unique, and now this piles up too. So underscores or dashes or anything else won't matter.

Well it seems I have solved the problem by limiting the number of characters of each flac file name to 3 (before the 5 characters ".flac").

Before doing this the xxengine would fall over several times per listening session, whereas after reducing the length of the names it has been working flawlessly.

This is a little baffling as I ensured the OS had the disable8dot3 setting at 0 before even installing XXHighEnd and I also tried deleting all the music and copying it back in several times without success.

So I can only think there is something strange about Windows 7 Starter that has caused this. The only other thing I can think of is that as a classical listener, many tracks have the same name, so I have to put them in different folders (I have a seperate folder for each piece of music within my main Music folder and within each of those folders there is a flac file for each movement within that piece).

Anyway, hopefully I have solved the problem and it won't reappear. It is also strange it only began as soon as I started using flac instead of wav. Well, that is one big advantage of XXHighEnd - I cannot hear the difference between flac and wav, and I cannot say that for any other player out there.

So doubling the precious capacity of my solid state drive is a small price to pay if I have to ecomomise with the length of the file names.

Jon,


Maybe not. I mean, that "FLAC" is 4 positions and has to be dealt with also. That happens within those 8 other positions (the log files will show you how). So all together it becomes too much ? I never heard of it, but maybe nobody has the files names so much unique for the left part. Btw, I am unsure about how unique those left parts are; at first I thought you had 11 the same apart from a last position, but looking at the examples it would be two of those the same only and that 11 times. Correct ?
It doesn't matter much, but if it is the latter it is not related not not-uniqueness at all; only length.

Thanks for your kind words and gald it is solved,
Peter

It seems those particular errors are solved by reducing the length of the flac file names...but there is a new side effect - XXhighEnd is now ignoring the button that stops playback after the current track is finished. So XXHighEnd will play every track in a given folder listed below the current track (as well as the current track of course) and disregards that the stop playback after current track button has been pressed.

In other words, the stop playback after current track button is now useless, as XXHighEnd now completely ignores it.

But this is a problem in 0.9z-6 anyway ! I am not sure whether this is different with Attended Playback, but for, say, 100% sure for Unattended it didn't work for 0.9z-6 (and maybe a few older versions). I just solved that two weeks back or so for 0.9z-7.

Are we talking about the same thing ? Or do you talk about Attended ? (in that case I'm not sure and *if* that is related to your solution here I'd be the most interested in one or two example files (names of them)).

It is happening in unattended only. So I will wait for version 7 then.

Okay, but then it was so before your FLACs etc. just the same.

Thanks,
Peter