Print

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

[aviateur]

Hello:

The subject is my question. Is it possible to change an existing 'DateImported' value? I use this value for physical storage purposes. So after re-importing a CD, I would like to change the 'DateImported' value back to its original value which determines its physical location.

Thanks for your help,
Lawrence

[blgentry]

I don't understand how or why you're storing your media by date imported.  But I guess I don't need to either. 

There are no user facing tools to change Date Imported in MC that I'm aware of.  It can be done, but it takes some work.  Essentially, you can export the selected files as an MPL playlist, then edit the dates in that playlist, and reimport the edited list.  This should update the import dates.  I tested this a while back, when I was writing some tools to change these types of things.  I recall my tests being successful, but it's a been a while.

Brian.

[glynor]

[Date Imported] is read-only.

You can modify it via MPL import or COM. I'm not sure about MCWS (I've never tried). You have to use the internal date format, which is a bit fiddly.

[aviateur]

I don't understand how or why you're storing your media by date imported.  But I guess I don't need to either. 

There are no user facing tools to change Date Imported in MC that I'm aware of.  It can be done, but it takes some work.  Essentially, you can export the selected files as an MPL playlist, then edit the dates in that playlist, and reimport the edited list.  This should update the import dates.  I tested this a while back, when I was writing some tools to change these types of things.  I recall my tests being successful, but it's a been a while.

Brian.

Brian:

Thanks for the reply. Your workaround suggestion was unsuccessful. I modified 'DateImported' and 'DateCreated' to December 1, 2012. I then imported the 'one album' playlist only to discover the 'Date Imported' was once again the current system date/time. So I decided to try a painfully obvious workaround. I modified the system date to 2012. This, indeed, worked although there were several 'screaming howler monkey' messages about certificate expiration dates. However, as GWB once proclaimed, "Mission Accomplished"! For those curious, I was able to determine quickly that the value stored in the date fields are the number of seconds that have transpired from the anchor date/time stamp of December 31, 1969 17:00.

Incidentally, I'm happy to give you the 35,000' view of the reason why 'DateImported' was a necessary component in the serialization process to manage the physical storage of 5,000+ CDs. The process negates the need for continuous physical maintenance to alphabetize my entire audio library every time there are new items to add. The order is logically maintained with a pointer to the physical location. The process involves copying source information (AlbumArtist, Album, DateImported) from Media Center and pasting it into a dynamic MS Access table which then, via code, establishes inventory sequence numbers by groups within small moving boxes (24 so far). By using 'DateImported' ranges per group, this process establishes a fixed sequence order. I then produce PDF reports which are placed on an iPad, which allows me to narrow my search and retrieval to an alphabetized box. I retrieve CDs about 2 dozen times a year for the purpose of reading/researching liner notes or for the occasional re-import. As I acquire new CDs, they are placed in the current box being filled and then the whole process is executed once again to refresh and reflect the new additions which then appear in the new PDF reports. So there's the HOW and the WHY.

Cheers,
Lawrence

[blgentry]

Your workaround suggestion was unsuccessful. I modified 'DateImported' and 'DateCreated' to December 1, 2012. I then imported the 'one album' playlist only to discover the 'Date Imported' was once again the current system date/time. [...] For those curious, I was able to determine quickly that the value stored in the date fields are the number of seconds that have transpired from the anchor date/time stamp of December 31, 1969 17:00.

If you're sure you changed the date to the correct value, based on the number of seconds, I'm not sure why it didn't work.  Oh wait!  Now I remember!!!

There's some weird bug/behavior which requires you to import the playlist *twice*.  The first time it won't pick up the changed values.  But the second time it will.  If I'm remembering correctly.  Give it a try.

The process involves copying source information (AlbumArtist, Album, DateImported) from Media Center and pasting it into a dynamic MS Access table which then, via code, establishes inventory sequence numbers by groups within small moving boxes (24 so far). [...] So there's the HOW and the WHY.

Wowsers!  Impressive and moderately scary!    My CD collection is less than 1/10th that size and it's kind of a pain to move things to the right places in order to keep them alphabetized.  I like your inventory number idea.  In the abstract, all you'd really need is the box number of each CD and it wouldn't need to be based on anything, other than something to make sure the box numbers are unique.  But I don't know much about your system... just thinking out loud.

If you had a bunch of these dates to change, you'd probably want to automate it in some way.  Assuming you can get it working with the import/export method to start with.  As you've discovered, the math isn't too hard.  If you are going to set to a specific date, you might want to use a library to do it.  I was simply experimenting with offsets:  Like add or subtract 30 days from the current import date.  That seemed to work just fine.

Good luck to you.

Brian.

[blgentry]

Incidentally, did you know you can store custom data in custom fields in MC?  You could very easily create a field called "Storage Location" (or similar) and put something in the field like "Box #22".  You could even include more info if you wanted to like:  "Garage, NW quadrant, box #22".

This would seem like the logical thing to do:  Putting all of the data about your music collection in one place, instead of 2 or 3.  Just a thought.

Brian.

[aviateur]

Incidentally, did you know you can store custom data in custom fields in MC?  You could very easily create a field called "Storage Location" (or similar) and put something in the field like "Box #22".  You could even include more info if you wanted to like:  "Garage, NW quadrant, box #22".

This would seem like the logical thing to do:  Putting all of the data about your music collection in one place, instead of 2 or 3.  Just a thought.

Brian.

Brian, Hi:

No joy on the import/export attempts so I will live with changing the system date back and forth when necessary. As I mentioned, I only need to update 'DateImported' for the occasional re-import operation of one album. By the way, I employ 'dbPoweramp' for ripping purposes.
 
Regarding the abstract perspective, I believe we are in agreement. When I search, I only concern myself with the box number. The sequence number is just for order and count processing purposes within MS Access. But make no mistake, the sequence number was instrumental when I conducted inventory before permanent storage.

Regarding custom fields, I just discovered that capability last evening. It must've been your mental telepathic aura that pushed me in that direction. That aside, when I took complete inventory back in November 2015, I used the field called 'Custom' to place a value called EOB (end of box) in the respective CD entry within MC for the last CD stored in a box. I use it later on as a tripping mechanism within MS Access to increment to the next box number as I sequentially process by sequence number each of the CD items. With this approach, I only had to modify 24 items within MC as opposed to modifying 5,000+ items. So, in essence I am keeping all the pertinent data within MC.

I've attached some page excerpts from 3 documents I developed within MS Access.

One final note, my approach uses MC as my source data. I refresh (replace) the MS Access database data as often as needed. I then process inventory and sequence integrity (data cleansing) code. I am able to correct any errant import issues without having to individually inspect tens of thousands of tracks. Using MC as my only source data (everything in one place as you say) eliminates the need to manage a separate database outside of MC. I did that in years past. You can just imagine the synchronization challenge and effort required to keep a large library in order while ensuring data integrity. So, in summary, the purpose of MS Access along with the personally-developed complementary code is for inventory tracking, offline visual aids, and data integrity verification.

The efficacy of the process is proved on a regular basis because the automation affords me more discretionary time to actually listen to the music as opposed to being the full time librarian/administrator.

Cheers,
Lawrence

[glynor]

You may want to look at: MCFileIngester

Example video:
https://vimeo.com/85110224

It was designed explicitly for re-importing new copies of previously imported media assets without altering fields like [Date Imported] and Playlists.

[blgentry]

Sounds like you've got your system worked out quite well.  I enjoyed seeing the reports; thanks for sharing them.    I have a lot of the albums in your lists (but not nearly as many as you have!).

Do you put the sequence number on the CD case?  That's got to be a lot of work, but it probably gets easier as you get your system set up.

It may or may not have occurred to you yet:  You can make new fields in MC's database that stores dates.  So if you wanted to, you could alter the import dates in this new field and use it as a source of data for your export/import to MS Access.

In fact, you might want to use a 3 tier system which makes your life really, really easy.  Here's what I'd suggest:

[Date Imported] :  Included field that's read only and populated by MC automatically.

[Date Imported Adjusted]:  Use this field for any song, album, etc that you want to make the import date different.  You'd directly enter a date into this field.

[Date Imported Correct]: This is a calculated field.  It takes the value of [Date Imported Adjusted] if it has a value in it.  If it doesn't, it takes the value of [Date Imported].  That way this field always has the CORRECT import date in it.  Either the regular one or your adjusted value.  It's very easy to make a calculated field like this, if the idea appeals to you.

Brian.

[aviateur]

Brian:

Thanks for the 'Calculated Field' tip. I'll explore that idea further. That also might work well with your export / import MPL suggestion.

Also, I do not mark the CD cases in anyway because there is no reason to do so. I use the logical mapping that the sequenced inventory list provides. So, here is a highly unlikely but germane for the purpose of discussion scenario.

Someone stops by home while I'm away to borrow an audio CD album. After some time goes by, one day I discover a thank you note with the CD on my desk. What do I do? First, I change out all the door locks at my home. Second, I look in the sequenced Audio Inventory list on my iPad to determine in which box it should reside. The sequence for the box is already established, so it is a simple matter of inserting the CD between the BEFORE and AFTER titles for the subject CD case. It's that simple. Incidentally, I was very careful to use the same box loading technique to preserve the sequence of the box: top-to-bottom rows, left-to-right columns, bottom layer first, and top layer last.

Cheers,
Lawrence

[glynor]

That way this field always has the CORRECT import date in it.  Either the regular one or your adjusted value.  It's very easy to make a calculated field like this, if the idea appeals to you.

I explained in detail how to do this for someone once before:
https://yabb.jriver.com/interact/index.php?topic=97481.msg673556#msg673556

It is actually easier now than when I wrote this. Back then there were some fiddly-bits around sorting with the calculated field. This has changed now that we have &datatype=[Date]. You couldn't, before, do this, though so the optimal way would be slightly different than these instructions. This amounts to just adding the data type to your custom field for manual entry and the expression.

Again, or you could avoid the situation entirely with MCFileIngester when you do need to replace existing rips on disk for some reason. I run this on my Library automatically (to ingest new copies of TV recordings, after they get processed by VideoReDo) every single day and it works perfectly.