Print

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

[DrKNo]

It is a bit thankless from me to post complaints that close to Christmas, luckily it's not that urgent.
I'm writing an autoresolver for pyMCWS currently, and I noticed that (1) not all fields are returned, and (2) some fields have inconsistent datatypes. This can be worked around, but it's not beautiful and is confusing for new users. The offending fields are:

Fields that are not returned in Library/Fields endpoint, but are returned using Library/Search:
Key
Date (readable)

The following fields are returned in Library/Fields with DataType "Date", but they are not JRiver Date formats (Numbers are far to big) - possibly classical timestamps? This causes automatic conversion to fail.
Date Imported
Date Created
Date Modified
Date First Rated
Date Tagged
Last Skipped
Last Played
Date Last Opened

Then, finally, there's a few undocumented types:
Image File
Time
File Size
User
Path
Date (float)

I'd offer to document them them in the wiki but I do not believe I have editing permissions.

Finally, to completely overstretch any goodwill: Would it be possible to also get the remaining properties of fields from that endpoint? Most relevant for me would be "acceptable values", but there's also:
Display
Display Plural
Hidden
Relational
Flags
Save in Tags
Show a link checkbox
Default Search Field

Thank you for considering the suggestions and happy holidays to all of you!

[Hendrik]

Fields that are not returned in Library/Fields endpoint, but are returned using Library/Search:
Key
Date (readable)

These are not actual library fields, but inserted by MCWS.

The key is of course the FileKey, and taken again as input for many MCWS calls, and Date (readable) is a pre-formatted variant of date.

The following fields are returned in Library/Fields with DataType "Date", but they are not JRiver Date formats (Numbers are far to big) - possibly classical timestamps? This causes automatic conversion to fail.
Date Imported
Date Created
Date Modified
Date First Rated
Date Tagged
Last Skipped
Last Played
Date Last Opened

We have two date types, Date (float) and Date.

Date (float) is a double-precision floating-point value in days since 1900. Its typically formatted to not include zero components, ie. if the resulting date falls on january 1st at midnight, it would only show the year. (if zero is supposed to be shown, there is a fudge factor of 1/10th of a second to make it not exactly zero - the magic of floating points!). Can also be negative for dates before 1900.

The Date type is a typical unix timestamp, with all its restrictions.

Currently, only the fields "Date", "Date (release)" and "Date Recorded" (not sure why it was chosen for this field, but we can't change it after) use the Date (float) type. The other Date fields are more closely related to actual interactions with the file or physical file properties, and use a unix timestamp.

The field list returned by the API should correctly reflect which field uses which date type.

Finally, to completely overstretch any goodwill: Would it be possible to also get the remaining properties of fields from that endpoint? Most relevant for me would be "acceptable values", but there's also:

I can add acceptable values, not sure how useful many of the other properties are.

[DrKNo]

Thank you for the fast reply, Hendrik! That clears up a lot.

Regarding key and date (formatted): I understand the intention, but the typical dev will get a list of fields using the fields endpoint, and then be surprised if new fields pop up in the actual query. Maybe one can include them in the fields query? Not a priority though, could maybe just be mentioned in the MCWS API docs.

Regarding the dates: You are right, the date (Float) is returned correctly for these fields. Could maybe be mentioned in the documentation? There is currently only one type of date listed there.

Regarding the additional data: Thank you for offering to implement "acceptable values". If at all possible, I would also be interested in the two display values, for, well, displaying.

[DrKNo]

Date (float) is a double-precision floating-point value in days since 1900. Its typically formatted to not include zero components, ie. if the resulting date falls on January 1st at midnight, it would only show the year. (if zero is supposed to be shown, there is a fudge factor of 1/10th of a second to make it not exactly zero - the magic of floating points!). Can also be negative for dates before 1900.

While I have you on this, this is the method I used to convert dates until now. However, I consistently got a result off by plus two days. I have mostly tested dates > 1990

Date entered is 2009, an int is returned: 39814
wolfram alpha says it should be 39812 days: https://www.wolframalpha.com/input/?i=days+between+1900+and+2009
and python accordingly returns the 3rd January 2009:

Code: [Select]

days = float(jriver_date)
date = datetime.strptime("1900", "%Y")
date += timedelta(days=days)
print(date)

[Hendrik]

I double checked the code, and its actually "days since midnight 30 december 1899" for some reason

https://www.wolframalpha.com/input/?i=days+between+midnight+30+december+1899+and+2009

For the plain "Date" field, I would recommend to simply use the "Date (readable)" pre-formatted value to avoid having to deal with it.

[DrKNo]

I need a general solution for this (user fields with the date type are set to Date (float)) - but luckily that's not hard to do If I know the starting date. Thank you for your time, Hendrik, I appreciate it!