Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RhinoBanga]

Hi guys ... it's me again


When I perform an MJA.Search will it always return back the tracks in the same sort sequence?

I am hoping the answer is yes as for v2 I am using the offset within the MJFiles object as a key value to a particular album's track.

[Nikolay]

Rhino,

I'm not sure, but I think the order depends on sorting settings defined by user.

Nikolay

[RhinoBanga]

Hi Nikolay,

I'll do a test tonight to find out what is going on.

It's really strange as when I build a v2 database the track infomation is correct.   Then after I close/reopen MJ a few times suddenly all my albums contain bogus track entries which to me points to the fact that the MJA.Search return sequence has changed.   But I have not added/modified/deleted any tracks in my MJ database or altered any sort sequence.

If the return sequence is random then I am going to have to abandon v2 of AV

[RhinoBanga]

Nikolay,

Well I proved MJ is returning a random order.

Here are the first 10 entries after I created my database:

[892] ReadDB
[892] 0: Enya - A Day Without Rain - 7 - Fallen Embers
[892] 1: Enya - Enya - 4 - March Of the Celts
[892] 2: Jesus Jones - Doubt - 5 - Right Here, Right Now
[892] 3: R.E.M. - Out Of Time - 9 - Texarkana
[892] 4: Frankie Goes to Hollywood - Bang ! ... Greatest Hits - 11 - Rage Hard
[892] 5: Radiohead - Pop is Dead - 6 - You
[892] 6: Travis - The Man Who - 9 - She's So Strange
[892] 7: Various - Recess Schools Out - 2 - Born To Be Wild
[892] 8: PIL - That What Is Not - 10 - Good Things
[892] 9: Outkast - Stankonia - 17 - -
[892] 10: Steve Hackett - Voyage Of The Acolyte - 8 - Shadow Of The HierophantShadow Of The Hierophant



After exiting and entering MJ serveral times (6 I think) the order changed:

[2732] ReadDB
[2732] 0: Enya - A Day Without Rain - 7 - Fallen Embers
[2732] 1: Enya - Enya - 4 - March Of the Celts
[2732] 2: Frankie Goes to Hollywood - Bang ! ... Greatest Hits - 11 - Rage Hard
[2732] 3: R.E.M. - Out Of Time - 9 - Texarkana
[2732] 4: Jesus Jones - Doubt - 5 - Right Here, Right Now
[2732] 5: Travis - The Man Who - 9 - She's So Strange
[2732] 6: Radiohead - Pop is Dead - 6 - You
[2732] 7: PIL - That What Is Not - 10 - Good Things
[2732] 8: Various - Recess Schools Out - 2 - Born To Be Wild
[2732] 9: Outkast - Stankonia - 17 - -
[2732] 10: Steve Hackett - Voyage Of The Acolyte - 8 - Shadow Of The HierophantShadow Of The Hierophant


Here is my VB code (ODS is a call to OutputDebugString):

Private Sub DumpData(szFrom As String)
Dim lLoop1          As Long
Dim MJFile          As MJFileAutomation

   On Error Resume Next
   
   ODS ""
   ODS szFrom
   
   For lLoop1 = 0 To 10
       Set MJFile = g_MJFiles.GetFile(lLoop1)
       
       With MJFile
           ODS lLoop1 & ": " & .Artist & " - " & .Album & " - " & .Tracknumber & " - " & .Name
       End With
       
   Next
   
End Sub




Any ideas on what I can to to get MJ to keep it's sequence?

Please help!

[JimH]

Hey Rhino,

The files are returned in random order.  MJ always does any sorting after a search.

This may change in the next version... we're not sure.

Is that a huge deal?

Thanks.

-Matt

[RhinoBanga]

Unfortunately it is.

Since people were complaining about the speed of v1 with large databases (e.g. 24,000 tracks) I decided to create v2 where I would have my own database where I would do as much pre-calculating as was possible.

For example each "album" has a list of tracks sorted by track number and sorted by location (note that AV's concept of an album is different that MJ's, e.g. duplicates).

Each of these tracks has a link back to it's original MJA.Search offset for efficiency and to save me from duplicating data.

Since this offset is not guarenteed to be the same over MJ sessions even when no add/deletes/updates have been performed this sort of makes my whole database redundant

[Matt]

Is there much difference if your "line back" is just the filename string instead of an offset?  Filename lookups are very fast.

And where's the major bottle-neck?  Maybe we can make MJ faster in that area...

Thanks.

-Matt

[RhinoBanga]

Matt,

I'll try getting rid of my reliance on the search offset and perform unique MJ.Search/MJA.GetFile when I reload the data.

Also there is no bottle-neck ... it's just that I only ever call MJA.Search once and use that everywhere to link back to MJ from within AV, e.g. the track details screen).

I'll keep you posted

[RhinoBanga]

Damn ... I see one issue already

An individual track record is a list of indexes:

Public m_lIndex                         As Long
Public m_lMJIndex                       As Long
Public m_lArtistEntryIndex              As Long
Public m_lAlbumEntryIndex               As Long
Public m_lAlbumTrackIndex               As Long
Public m_lImageIndex                    As Long


So for efficiency when I am creating my DB I just allocate a long array of 6 * , write into that then perform one physical I/O writing that data out.

Now that I have to store the filename I am going to have to rework this code ... God I h8 VB sometimes.

[Matt]

Hey Rhino,

What does the MJ database need to support for you to not need your own DB?  

We've added flexible, customizable fielding (any number / types of fields) for the next version.  What else should we try to work in?

Thanks.

-Matt

[RhinoBanga]

Matt,

Here's some things off of the top of my head:

1)  Multi-key sorting ... this would save me having to export and sort using slow VB.
2)  Store on a track basis wether the entry has an external and/or internal image upon import (this will save *a lot* of time).
3)  Allow fields that are not linked to tracks, i.e. free-loating fields that are found via a lookup key.


If you are going to allow #3 then I would suggest that you work something like this:

   Set MJUserDB = MJA.OpenDatabase( "Name" )  '  Where name is a user defined string and you use that for your own internal key reference
   MJUserDB.Find( "KeyVal", MyField ) '  Where KeyVal is the lookup value, MyField is the data and it returns a bool true on success
   MJUserDB.Insert( "KeyVal", MyField )  '  Same as above
   MJUserDB.Update( "KeyVal", MyField )  '  Same as above
   MJUserDB.Delete( "KeyVal" )  '  Where KeyVal is the lookup value
   MJUserDB.Erase '  Removes all fields from the DB
   MJA.DeleteDatabase( "Name" ) '  This removes the entire DB


I could then use KeyVal's like:

ARTIST__ISFAVOURITE
ALBUM__ISFAVOURITE
ALBUM__YEAR
ALBUM__LASTPLAYED


Mind you ... I'm surprised you're asking as I thought you'd be developing your own AV as it's a killer feature which really should be integrated within MJ.   If you are developing it please let me know so I can stop working on v2 and get back to doing fun things ... like playing games ... well actually I had an idea of moving MJ/AV into a namespace extension which I thought would be very cool ... view/play your albums all within explorer.   Of course this would mean that I would have to create a plugin that allowed MJ to be controlled/queried externally ... but that should be very easy to do.

[Matt]

let me know so I can stop working on v2 and get back to doing fun things ... like playing games

Hehe.  Please keep on plugging -- you're doing an awesome job.

And about the ideas, #1 and #2 for sure.  As for #3, I don't totally understand.  You just want us to maintain an array of user customizable data?  Wouldn't data like that make more sense in your plugin since it wouldn't mean anything to anybody else anyway? (or am I missing the point)

Thanks Rhino.

-Matt

[RhinoBanga]

Allowing freeform data in the MJ library opens up all sorts of possabilities.

> You just want us to maintain an array of user customizable data

Yes and No ... An array of data but not user customizable.

Plugin's should be able to create one or more mini databases for storage purposes.

In AV's case I need to store information that is not related to a particular track, e.g. when was the album last played or if the album is a user's favourite.

And for fun (or more realistically for debugging purposes) within MJ you could then create a plugin database browser plugin that shows the database name and when you click on it it shows a listview showing the key names and values.   Onviously this would need some sort of MJQueryDatabase functions ... but that should be very easy.

> Wouldn't data like that make more sense in your plugin since it wouldn't mean anything to anybody else anyway?

But isn't the point not to rely on an external database?

For example one of our mutual users keeps his MJ library on CDR's and he has many CDR's.   Keeping all of the AV information in the MJ library keeps everything self contained.

> (or am I missing the point)

LOL ... should I really answer that

Is this any clearer or should I do a more comprehensive spec?


Finally one thing I have thought of is that (in the future) maybe AV's thumbnails (now an ImageList) will not be stored in the MJ database.   They may be stored to an IStream and loaded directly via ImageList_Read for efficiency.   Would it be possible to handle IStream's in the new DB ... or at least if I give you an hWnd of an ImageList you can load/save the contents.

[RhinoBanga]

On a follow up to your suggestion about using the filename as a lookup key.

It works but it is *very* *very* slow

With the old way it took 7 seconds to load up my 3,314 track AV database.   Now that I am having to do 3,314 Search/GetFiles that figure has jumped to 21 seconds.

With the 23,789 track AV database it used to take 40 seconds ... now it takes nearly 3 minutes

Is there any way you can fix the order of the .Search?

[Matt]

Hey Rhino,

Don't use the search interface(s) to get a single file.  Instead, just use IMJAutomation::GetFile(...)  That should make it quite a bit faster.

And we can't "fix" the order of the search, because MJ 8.0 wasn't designed to internally iterate through files in any certain order.  Like I said though, we'll optionally build sorting into the search string in the next version.  However, mapping by anything other than filename will cause your stuff to crumble when files are added and removed from the DB.

And thanks for the info about the plugin databases.  It's a good idea because it could simplify the job of the plugin author, and provide a clean, standardized system for creating, backing up, and sharing data.

Thanks.

-Matt

[RhinoBanga]

Matt,

Do you have any timescales for this DB enhancement or are you just at the design phase?

The reason I ask is that I obviously would like to use your new DB capability but if it's months away then I will have to stick to my external DB for now.

[Matt]

Yeah, it's at least a few months out.  We'll post more details as we figure it out ourselves...

Thanks.

-Matt