Print

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

[bblue]

Would anyone be willing to share the details of the conversion between a human-readable full date (and time) and the resulting floating point value?  I'd like to be able to do the same conversion externally after reading an entry from MCWS.

Failing that, I suppose I could add a field to the library which is calculated from the FP value to the appropriate human readable format in real time.  If this becomes necessary:

1. Can this addition be added to the loaded library in real time?

2. What would be the best method for update of this new field for the full library?

3. I notice that in FLAC Properties (in the action window), "JR_DATE = xxxxx" seems to be added to the Vorbis comment field whenever the more than just the four digit year is entered in the Library DATE field.  Otherwise, JR_DATE does not appear.  Is this automatic by the system?  If so, would I assume that that would happen along with #2, above?

4. scratched from original message.

Thanks for any insight.  (The Wiki seems to be void of these kinds of details)

--Bill

[Matt]

The values are days since 1900.  The decimal is the time.

JRiver uses all custom date handling (for cross-platform), but Excel and Windows also use this format in some areas.  Google has some additional information.

[bblue]

The values are days since 1900.  The decimal is the time.

JRiver uses all custom date handling (for cross-platform), but Excel and Windows also use this format in some areas.  Google has some additional information.

Thanks Matt.  So far I haven't found anything in Python which can already perform these conversions, but it doesn't look too difficult to make (hopefully).

Can you comment on the library questions?

--Bill

[Matt]

Can you comment on the library questions?

#3 above is 'yes'.  There's special date handling to use the standard field when possible, but also store a high-precision version when necessary.  This is only possible with the stock date field since it requires special handling in the tagging plugins.

[bblue]

Would anyone be willing to share the details of the conversion between a human-readable full date (and time) and the resulting floating point value?  I'd like to be able to do the same conversion externally after reading an entry from MCWS.

Failing that, I suppose I could add a field to the library which is calculated from the FP value to the appropriate human readable format in real time.  If this becomes necessary:

1. Can this addition be added to the loaded library in real time?

2. What would be the best method for update of this new field for the full library?

Matt already responded to my third part of the above message (thanks), but didn't touch these two questions.

For these I was making the assumptions (you know what they say about those!) that the regular DATE field was already being returned by MCWS's Info query and I'd only be concerned with somehow obtaining the new library field.  WRONG!  Neither DATE or JR_DATE is currently returned in the Info query.

So whether it's DATE or a custom field in the Library, how would one gain access to a field that is not already returned by Info?  GetInfo gets close, but I can't tell from the itemization of it if just the custom field could be requested of a file which was requested by filekey.

If GetInfo will in fact work, you'd have to first use Info to get the Filekey of the currently playing track, then GetInfo by Filekey to get the custom field.

Will GetInfo in fact do this, or is there a better way?

Matt?  Anyone?

Thanks.

--Bill

[Matt]

Since you're off the beaten path, I think you're just going to have to spend time trying things.

MCWS/v1/File/GetInfo is the correct function to get file information.

[leezer3]

Thanks Matt.  So far I haven't found anything in Python which can already perform these conversions, but it doesn't look too difficult to make (hopefully).

Can you comment on the library questions?

--Bill

Python discussion and some code snippets on StackOverflow:
http://stackoverflow.com/questions/14271791/converting-date-formats-python-unusual-date-formats-extract-ymd

-Leezer-

[bblue]

Python discussion and some code snippets on StackOverflow:
http://stackoverflow.com/questions/14271791/converting-date-formats-python-unusual-date-formats-extract-ymd

-Leezer-

Thanks for the forward.  I've tested a bunch of those from stackoverflow.com.  Most of them are off by two days, but I did find a couple that produced (almost) the right results (see below.

Which brings me to a question which is not addressed in any of these conversions.  Probably Matt will know this, but I'm open to any response.

In these formulas converting from SerialDate to YMD format, there is NO notion of the year by itself.  E.g., there's no '1984' or '2001',  it's always either 1983-12-31 or 1984-01-01.  If the year itself is supposed to be a generic year, and NOT 01-01, how is that accounted for on MC?  If it's not accounted for, there can be no notion of the first day of the month.

I hadn't thought far enough ahead to realize this initially, but it's painfully obvious now.  There must be a flag of some sort that is controlling how the native year resolves.  Matt?  Anyone?

--Bill

[bblue]

Since you're off the beaten path, I think you're just going to have to spend time trying things.

MCWS/v1/File/GetInfo is the correct function to get file information.

Off the beaten path?  How so?  Just trying to understand functions and techniques that are obviously intended to be used.

GetInfo itself doesn't necessarily give you all the info you need to get the data you need, since it requires the file index as the target.  That is readily available from Info, but it means making two http calls to end up with what you want.  That is, unless there's another more efficient way to get the file index.

What threw me off, was that GetInfo with no field specifier is supposed to return ALL fields for that track.  But it doesn't seem to.  You have to specify that field, and even then the field name will not be returned if there is no data for it.  I.e. there's no notion of an empty field.  Is that how it should be working?

Code: [Select]

"GET /MCWS/v1/File/GetInfo?Fields=Date&File=" + Filekey + " HTTP/1.1\n\n"     # will work fine if you have authentication off

"GET /MCWS/v1/File/GetInfo?Fields=Date&File=" + FileKey + " HTTP/1.1\nAuthorization: Basic "+base64.standard_b64encode(MCSUser)+"\n\n"

The second line is the format if you have authentication turned on, and the variable MCSUser is "username:password" (as you have it set) and encrypted base64.

--Bill

[bblue]

In these formulas converting from SerialDate to YMD format, there is NO notion of the year by itself.  E.g., there's no '1984' or '2001',  it's always either 1983-12-31 or 1984-01-01.  If the year itself is supposed to be a generic year, and NOT 01-01, how is that accounted for on MC?  If it's not accounted for, there can be no notion of the first day of the month.

I hadn't thought far enough ahead to realize this initially, but it's painfully obvious now.  There must be a flag of some sort that is controlling how the native year resolves.  Matt?  Anyone?

--Bill

Hi Matt,

Any information on this?  So far I've determined that GetInfo contains only the Date field if it is not blank.  No other field is relevant to Date.

If Date exists, Date will also appear in the file tags.  If Date in GetInfo contains more than just the year, JR_Date will also be written to file tags (but apparently no other indicator exists that I can find).  It appears as though the only 'flags' that can tell you how to use the Date returned from GetInfo are the file tags themselves.  If Date appears, use it (it will only be the year), if JR_Date appears, use it instead for more detail.  From all the documentation I've read, there is no mention of having access to the file tags, except as they filter up through MC, except in the FLAC window in the Tags window in Action.

Unfortunately, MC doesn't seem to be religious about updating the file tags from the library unless certain changes have been made to the tags (I'm not sure what).  So occasionally, JR_Date or Date fields in the FLAC file tags may not exist even though it/they should.  Which is curious, because whether or not they are shown in the file, MC still reports the right Date in the Library/Playlist displays.  It's only when you look at the FLAC data directly in MC that you seem them missing.

I just added a calculated field to the library whose contents can be read by GetInfo as long as you list the fields that you want explicitly.  It will not show the new field if Fields is not itemized in the request, which is supposed to default to all fields.

Does all this sound correct to you?  Any other thoughts, corrections or suggestions?

So for now I can work with my extra library field's calculated results, but would still really like to know more about the above issues, if you can.

Thanks.

Despite this bout of frustration, I still think MC is quite amazing in its capabilities.  Excellent work!

--Bill

Are there any other MCWS commands/results that may not yet be listed in the documentation (docs and source) that might help in this situation?

[MrC]

I recall reading this thread a while ago, and had some thoughts, but haven't re-read it thoroughly tonight.  If you still have an interest, ping the thread and we'll continue...