Print

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

[DoubtingThomas]

A couple questions about the KEY field.  There as a post about the KEY field recently, but I can't find it.

Please correct me if I'm wrong, I assume the KEY field is a unique numeric identity field for every track imported into MediaCenter.

I have deleted a track from MC and then reimported it, and the KEY value did not change, so I assume the KEY value is stored in a tag?

What if a track is imported that was previously imported by another copy of MediaCenter, does the KEY value change?  If not, what if there is a conflict with another track with the same KEY value?

Is the KEY value simply a counter that selects the next unused value or is it derived somehow?  Are KEY values ever reused?  I have changed a track name and the KEY value did not change.

What uniquely identifies a track internally for MC and under what circumstances would a KEY value ever change?

I'm trying to keep track of deleted tracks from MC by comparing a current export to the prior export.  I am trying to figure out the best way to see if a track from the prior export exists in the latest export.  Of course I can check for the same Artist/Album/TrackName, but the KEY field would seem to be more accurate and would automatically handle any renaming of the Artist/Album/TrackName fields.

[blgentry]

I know very little about this so I won't even speculate on most of your questions.  I'll just tell you that you can display the KEY with the filekey() function.  It sounds like you might already know this, but just in case...

You can make an expression column in a view or list.  Make that column simply have the value:  filekey()

Then you can export a playlist and select "only visible fields".  That way the filekey gets included in the export.  Then you can use whatever tool you were planning on using to compare file keys.  I would use some sort of DIFF program.  Probably Unix comm for me, but there are tons of visual diff programs around that would work as long as you first sorted both files by file key.

Brian.

[DoubtingThomas]

I know very little about this so I won't even speculate on most of your questions.  I'll just tell you that you can display the KEY with the filekey() function.  It sounds like you might already know this, but just in case...

Thanks.  I am using MCWS to do a full export of my MediaCenter database with the KEY field.

[Matt]

Is the KEY value simply a counter that selects the next unused value or is it derived somehow?  Are KEY values ever reused?  I have changed a track name and the KEY value did not change.

The database keeps a counter for the next key it's going to issue.  If there's a collision, it uses the next ID.

That way, it'll always be a unique number (relative to that database).

[DoubtingThomas]

The database keeps a counter for the next key it's going to issue.  If there's a collision, it uses the next ID.

That way, it'll always be a unique number (relative to that database).

Thanks.  I think I started with MC8....  I currently have 31,004 track in the database, and the highest KEY value is 35,949,475.

[Matt]

Thanks.  I think I started with MC8....  I currently have 31,004 track in the database, and the highest KEY value is 35,949,475.

Well we won't be in trouble until the highest key is 4,294,967,296.

But even then it should just loop around and find an unused value.

Now if you're trying to import 4,294,967,296 + 1 tracks, we might have problems.  Ha!

[DoubtingThomas]

Well we won't be in trouble until the highest key is 4,294,967,296.

But even then it should just loop around and find an unused value.

Now if you're trying to import 4,294,967,296 + 1 tracks, we might have problems.  Ha!

The best laid plans of mice and men...  at USWest we created a db in 96 with Oracle identity fields as the key between many tables and we calculated we'd "never" have to reset them... I got them reset back in 2009 on a 2am swat call... and they've been reset once again since I retired...

And I don't know if anyone has a solution yet for the UNIX time_t (long) variable which will overrun in 2038...

[DoubtingThomas]

Matt,

One good thing I learned today about the key field.

If I copy a new file over an old one and do "update tags from library" it copies the key field from the library to the replacement file (which had already been imported into MC and then removed).   I do this when I get a better version of a track.  Copying the key from the library is a huge help to me in tracking deletions because as far as my code is concerned, there was no change to the track even though I actually replaced the file.

Thanks for the info.