0.9v-3 feedback

[Calibrator]

Hi Peter,

fantastic job you're doing on the coverart processing. It adds a nice new level of ergonomics to the viewing of all the embedded extra info that some of us like to keep for our albums.

Would you consider adding an extra function to the rightclick options when in the rightmost panel? It would be nice to have a specific "rename to Folder.jpg" function available in addition to the "rename" function currently available. I could imagine that most would only use the rename function to change an item to "Folder.jpg" so it will save a lot of typing and speed up the process of tidying up all our coverart.

I have also found a small bug I think when accessing album folders across my LAN. If a folder ( or the folder above ) contains files with a ".txt" extension ( there may be other types ), an exception window is brought up complaining that the value of _files path_ is not valid for 'filePath'. This happens under XP , I haven't tried it under Vista yet. If you can't duplicate it in your environment I will post a screen shot of the message later for you.

Users ... they always find a way ... 

Cheers,

Russ

Update: the bug happens under Vista also

[PeterSt]

Hi Russ,

Concider the Rename to Folder.jpg done. I could have thought on that one myself (with some brains ).

In order to save me some time, could you please tell what you are actually doing to let the exception appear ? "accessing album folders" doesn't tell me much since several ways exist and maybe not all those ways throw the error (plus that I can't imagine what's happening).


But wait a minute ... I recall (could be a small year ago) that you had something else with your network path or name (unrelated to Activation). Something with a (strange ?) Share Name ? ...

Peter

[PeterSt]

Russ, I need a hand here; I tried everything I could think of, but on an XP machine over the network to the Vista where the data is ... everything works here (including asking for the contents of an info.txt etc.).

But keep in mind my remark about the Share Name. Maybe you recall what that was about ?

[Calibrator]

Russ, I need a hand here; I tried everything I could think of, but on an XP machine over the network to the Vista where the data is ... everything works here (including asking for the contents of an info.txt etc.).

But keep in mind my remark about the Share Name. Maybe you recall what that was about ?

G'day Peter,

I've just woken for the day and I'll get some screen shots and system dumps ready later this morning to send.

To refresh your memory, the earlier issue I had with the share name was resolved by replacing the blanks I had been using in the name with underscores ( _ ).

The issue I am having now occurs even when accessing albums from a network drive having a single character as a share name , ex. 'C'

One thing I did notice late last night was that going from my laptop to my study PC, whenever I used the 'library' button ( top left side ) to access an album folder that had a .txt file within it, I had a system exception message come up and subsequent checking of the system management logs ( event viewer/application ) indicated that .net had suffered an error. The timing of the log entry coincided with the crash in XXHE.

I'll work on the bug report after my morning cuppa and get back asap.

Thanks mate,

Russ

[Calibrator]

Peter,

I've sent a series of screen dumps and system dumps to your email address ( too big to attached here ).

If you need further info just holla.

Cheers,

Russ

[PeterSt]

Hi Russ,

Thank you very much for all the info you sent.
The problem is caused by not using a drive letter to reference the path, and something (must sort that out) can't cope with the \\PCName reference.

I hope to have solved this by tonight, and I will post an intermediate version in this topic.
In the mean time, when you assign a drive letter to that reference it will work.

Peter

[Calibrator]

In the mean time, when you assign a drive letter to that reference it will work.

Yep ... just confirming if I "map a network drive" it works here too 

Good luck chasing down the quirky network issue!

Cheers,

Russ

[PeterSt]

Ok, for those who are bothered by the network reference bug, below is the intermediate version 0.9v-3a (XXHighEnd.exe).
Unzip it to the folder where 0.9-v3 resides.

Russ, FYI : it went wrong at the official dot-net retrieval of file association icons from the OS. To me this is kind of logic because the OS would be another one (another machine anyway). Now a routine I created myself does this job, and I hope it's official enough to cover for all situations.

Also, I found the relatively very slow response on retrieving CoverArt Data at clicking on a Library Item was caused by some time-lag in the (Vista ?) OS, which I worked around. Note that this makes the Fast Rendering checkbox (Settings Area) less valuable, because the real time was taken by this time-lag.

Lastly the Rename to Folder.jpg is in there.

[Calibrator]

Gooden Morgen Peter,

this intermediate version has resolved the network issue now thank you 

A couple of other bugs I think are there ( I know you just love bug fixing  )

The first is with the new "rename to folder.jpg" function. It doesn't seem to work consistently here. I'm trying to figure out the underlying cause of it not working 100% of the time but I think it's related to the file being locked by another program somehow. Maybe XXHE itself. Will report back on this one.

Has anyone tried this rename function and found similar issues ?

The second relates to restarting XXHE after the tracks specified within the current playlist file are no longer in their original folder when XXHE is restarted the next time. An error message requesting a bug report be send to micro$oft comes up straight away and you have no option to continue. XXHE simply shuts down. The only way I could get XXHE to behave itself was to delete the '!CurrentlyPlaying.PLXX' file from where XXHE executable resides.

If you need further info just holla.

Cheers,

bugmeister Russ 

[PeterSt]

Dear Burgermeister,

The Rename issue is known to me, and I thought I mentioned it in the Release Notes (maybe not) (this is about the Renaming in general). This is a bug I couldn't resolve, and as far as I have seen this is Vista only (honestly, I tried over the network renaming files on an XP machine, and there it works flawlessly.
So FYI : on average it takes 174 () attempts to perform the Rename, and those attemps are built in at a 4ms interval 3000 times max. Btw, this looks very very similar to Vista file management in general, which bugs half of Vista owners. I had it too, and there was really no way I could get rid of it. Upgrade to SP1 didn't help (which helps 80% of people), but a reinstall to SP0 did (note that I didn't have this right from the beginning).

Re the old items in the Playlist, yes, of course. I will solve that (I should receive some lessons on how to become a user ).

As always, thanks for reporting Russ,
Peter

[PeterSt]

PS:

Maybe XXHE itself. Will report back on this one.

Officially this is so, yes, which is related to the picture being visible a.o. in the right pane. However :

1. I did all I could think of to free everything around all the pictures and it doesn't help a thing;
2. I found that it just needs x attempts and then it works.

For those who really love bugs which can't be solved :

The 174 times I mentioned are 9 out of 10 times exactly that (meaning : not 173, not 175 but exactly 174);
Any sleeping time before the attempts do not change a thing.
Changing the sleep interval in between the attempts (my 4 ms) doesn't change a thing.

It took me a Saturday to work around this (like it is now), and it is the strangest bug I've ever seen (because of the behaviour).
Can you imagine that it took hours at first before I started to perform the Renames in a loop ? ... the one attempt just never worked, so ... it just didn't work. I thought.

Along with this goes the extremely annoying long wait times in Vista at deleting / renaming / copying files and folders, which (note !) is not about the renaming etc. itself, but about the windows showing the time it will take that stays there for 30 seconds while the real work has been done already, but won't allow you to proceed anyway. I say "along with this" because I couldn't solve this (as the whole world can't, but usually I can hehe) and it caused the really very first time in my whole life for me to re-install the OS to get something working again (and Russ, I think you know my TT stories). It's just in the same area.

Btw, the latter problem does not occur when operating the files from another PC.


100% sure this is incurred by XX itself, because the same happens from within the Library Area, and there it just works for already a long time (although I didn't try it lately).
With Delete it is exactly the same (and that too is performed in a loop).

Lastly, for the real insiders : I use an old version of the Rename (meaning the Rename command from VB) and not the official dot-net version. The latter behaves even worse (takes 1000's of attempts), which tells me that something fishy is going on with the "Managed" part of the code (managed : dot-net determines when to free memory really, and this is not up to the programmer).


Anything else ?

[PeterSt]

The first is with the new "rename to folder.jpg" function. It doesn't seem to work consistently here.

I just bumped into a solution for this. It is solved in the next version.

[Calibrator]

The first is with the new "rename to folder.jpg" function. It doesn't seem to work consistently here.

I just bumped into a solution for this. It is solved in the next version.

Well done Peter. You must have a big can of Mortein over there to have got to that bug 

Cheers,

Russ