ah ha! I think this is where things become unstuck .. well .. from my perspective anyway .. LOL.

In the screen capture below there are Explorer views of the files as they exist on my study PC ( lower section ) and the equivalent as they exist on my HTPC. Note the 'date created' column differences. Now, I would have expected that if you put in a Date Picker range of 18th - 19th they would have been picked up, but they don't, you need to extend that range to the 11th to get them, and that's my issue.

Is this any more helpful?

Cheers,

Russ

hehe ... can I blame you then for my lack of sleep due to extended nightly listening sessions on a system which hasn't hiccupped since 0.9v-6a was released


Perhaps if I outline the scenario I wish to achieve it may be easier to understand where I am coming from.

I normally do my ripping of new albums on my study PC. These new rips may reside there for a few days or even weeks until I have built up enough new albums to fit onto a blank DVD for secondary archival purposes in case my primary harddrive archiving goes belly up. During the time I am accumulating my new music, I access ( over my LAN ) and play that new music from my HTPC in the theatre. The HTPC contains all my music spread across several drives, EXCLUDING MY LATEST STUFF.

After I have filled up a DVD's worth of new music I then copy all that chuck of music to the HTPC drives into the appropriate main folders. It is after this copy process that I then need to identify the data I have just created, and thus create gallery entries for them.

Early this morning I tried using the Date Picker on my laptop to test its functionality and noticed the conditions I mentioned above in the previous post, namely that XXHE appears to be using the 'date modified' attribute of the files upon which to base its selection. I found this out by comparing the date and time displayed within XX's library listing description to the attributes of the files when viewed via Explorer.

Yesterday ( 18th ), I copied over a chuck of new music to the HTPC and tried setting the Date Picker to the range 18th to 19th and nothing showed up. I extended the range to 17th to 19th and a few showed up, and interestingly enough, not all the CD's from a particular boxset. I went back to the 16th - 19th and a few more showed up. Well, you get the idea.

I can only conclude from this that it isn't doing what I expected. I still think using the 'date created' attribute would work.

Are you able to test this procedure on your system Peter just to assure me I'm not going  in my old age!

Many thanks for your perseverence.

Cheers,

Russ

Doh! Thanks for the reminder about that little button Peter. It's a valuable function I had forgotten about.

I have noticed though that you appear to be using the 'data modified' attribute of the first audio data track within a folder upon which to base your search/sort criteria. Would it not be more appropriate to use the 'date created' attribute of the actual folder itself containing the audio tracks?

If you copy folders across systems the 'date modified' attribute won't necessarily be changed to reflect current date and may be many months older than the actual creation date of the new files. Searching under these conditions may result in albums NOT being displayed after the Date Picker has done its job.

Thoughts ??

In principle though, the Date Picker will do what I am seeking

  Peter,

Russ

edited 19th ( see bold NOT added )

G'day Peter,

I may have missed discussion about this on the forum, but I can't find a way to have my library folder art displayed other than in alphabetical order. I was hoping to be able to have it shown sorted by date creation order so I could more easily identify new albums I have added recently to my data folders. This would make it much easier to append these new albums to the galleries.

Is that possible currently or a feature you could incorporate?

Thanks,

Russ

Ideally I would like to see a little additional flexibility in addition to your request.

Ability to:

-  double left click an an individual track ( or tracks ) to play immediately ( thus overriding the current playlist )
-  right click on an individual track ( or tracks ) to enqueue on the current playing playlist
-  drag and drop an individual track ( or tracks ) onto an XXHE icon on the desktop.

These are pretty much the play functionality I was used to when using Foorbar and seemed to cover all needs.

Hopefully they can be incorporated into XXHE when Peter is comfortable that all the main bugs have been squashed.

Cheers

Russ

ah ha .. thanks again for a broader explanation. I have likely assumed incorrectly that ALL the folder art needed to be loaded into memory at the same time, but thinking further about it, that wouldn't be the best way to do. The actual coverart data only needs loading into memory when that art needs 'displaying' in whatever manner. An index of some sort within your program would be a much faster method of keeping track of things I would think.

and yeah .. I wasn't going to reduce the additional coverart info the the point where it was unreadable. Kinda defeats the purpose then.

Cheers,

Russ

Thanks for the explanation of your logic here Peter. I can understand where you are coming from now, especially the desire to keep the source folder disks from having to spin up if idle. My gallery folders are getting quite large ( approaching 9GB in total ) so I'm looking for any means to reduce load time. I am systematically going through each folder.jpg to reduce them to an average 500x500 pixels ( which I find is a good compromise ) so over time I hope to reduce the load burden. It would help if I stopped buying more music too .. LOL

Cheers,

Russ

I discovered a flaw using the 'chk' box feature to create the galleries. If you have the 'chk' box ticked, and you use the procedure I outlined earlier to select all entries ( ie. highlight the first entry , scroll down to the last entry and while holding down the SHIFT key you click on that last entry ), that all the entries seem to sequentially have their additional artwork displayed in the right hand pane when the system is going through the process of highlighting all the entries. This REALLY slowed down the selection process and makes it unworkable when you have many albums to process. I therefore chose to NOT use the 'chk' box.

Have you found this to be the case on your system also Peter ?

I've been thinking ( dangerous I know .. LOL ), that perhaps the additional coverart etc. need not necessarily be copied over to the Gallery folders, but simply have only the folders.jpg there. This should significantly speed up the loading of the galleries I would think. I noticed there is a cross-reference file in both gallery and source folder now, so perhaps that could be used to involk the displaying of data ( from the source folder ) in the right pane when an entry in the centre pane is selected.

Thanks,

Russ

Thanks for these results. For comparison, the fastest drive in my system, a WD 1TB SATA drive starts off at 92.3MB/sec transfer rate and drops to 41MB/sec ( presumably at the inner core ) giving an average of 73.3MB/sec. Its burst speed is 149.8 MB/sec. The access time though is where the huge difference occurs; the SATA drive averages 14.7 ms. There will be some variability due to system configuration/speed, but overall you have given a very sound argument for using a SSD for the galleries.

May I ask which brand and model did you choose?

Cheers,

Russ

Edit: I just found the model you bought (mentioned in an earlier post by yourself )

I'd be interested in knowing how fast those SSD's are currently. If you have a moment, could you grab HDTUNE (v 2.55 ) from http://www.hdtune.com/ are run a quick benchmark on it. I'm particularly interested in its Average Transfer Rate and Access Time results. My Galleries are getting a big these days and I'm looking for ways of speeding up response also.

Thanks,

Russ

G'day SeVeReD,

you don't necessarily need the 'chk box' active to create your entries into the Gallery.

Leave the 'chk' box unticked, and perform your search function as normal to get the list of entries you want showing up in the middle library panel.

Select the first entry with the left mouse button so that it is highlighted. Use the scroll bar to go to the end of your listing, then, while HOLDING DOWN the SHIFT key, click on the last entry with the left mouse button. ALL the entries should then be highlighted. While they are all selected, click on the right mouse button and perform the "gallery/add to gallery" function.

Give that a try.

Cheers,

Russ

Well done Peter 

I'm glad to have been some help in getting this issue sorted out. I can imagine your frustration in chasing this one down.

Folks, just to re-iterate what Peter mentioned in the release notes for 0.9v-6, if anyone experiences any further glitches or error conditions coming up, please report them here on the forum. It's the only way Peter can find out about them. There are many combinations of hardware in use amongst us and sometimes these combinations act in a manner that Peter could not test for explicitly in his coding.

Cheers all 

Russ

Upon starting 0.9v-3a, if the path specified in the most recent playlist ( !CurrentlyPlaying.PLXX ) was no longer valid, the program would bring up an error condition window and request for the program to be closed. It was necessary to delete that playlist entry before XXHE would stay up and continue as normal.

With 0.9v-4, that same condition now brings up a different error message window titled "Show CoverArt" and says "Could not find a part of the path 'X:\XXXXXXX\XXXXXXX' etc. Clicking on the OK button now allows you to access XXHE as normal and you can then click on the 'clear' button to remove the entries in the current playlist. This solution has effectively solved the bug seen in 0.9v-3a.

Thanks Peter.

Cheers,

Russ

I have mentioned this to Peter also. In the interim, you can get around the bug by deleting the "!CurrentlyPlaying.PLXX" file ( normally in your install directory) and restarting XXHE. No need to 'reinstall' everything.

Cheers,

Russ

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

Cheers,

Russ