INTERACT FORUM

More => Old Versions => JRiver Media Center 30 for Windows => Topic started by: hoyt on October 02, 2022, 12:37:00 pm

Title: MCWS Response Change from MC29 to MC30
Post by: hoyt on October 02, 2022, 12:37:00 pm

I had noticed but hadn't put time in to troubleshooting yet that something was screwing up my python import scripts.  I finally nailed down where the issue is.  I call this:

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/Files/Search?Action=JSON&Fields=Key&Query=[Filename]=%22Y:%5Cfolder%5C2022%5Csubfolder%5Cnew_file.flac%22
In MC29, the response was a blank JSON file if the file wasn't found, so I then knew that this was a new file to be imported.  In MC30, instead I get a server 500 error.  I feel like this was a change at some point recently, but couldn't find it in the forum logs.

Title: Re: MCWS Response Change from MC29 to MC30
Post by: hoyt on October 02, 2022, 12:43:46 pm

Actually looks like it worked as I expect on 30.0.5, but not 30.0.6:

4. Changed: The MCWS function Files/Search returns a failure if no matching files are found.

That seems wrong.  The server didn't fail....

Title: Re: MCWS Response Change from MC29 to MC30
Post by: Hendrik on October 02, 2022, 01:25:47 pm

I agree, if anything it should maybe return a 404 and definitely not a 500. But an empty response seems like the most sensible otherwise.

Title: Re: MCWS Response Change from MC29 to MC30
Post by: hoyt on October 02, 2022, 02:56:54 pm

Quote from: Hendrik on October 02, 2022, 01:25:47 pm

I agree, if anything it should maybe return a 404 and definitely not a 500. But an empty response seems like the most sensible otherwise.

Yeah.  My thought is that the request is to search.  The search succeeded, so it should be a 200.  The results are just blank.  It's not like I'm calling something by a key value and I'm supplying an invalid key.

Title: Re: MCWS Response Change from MC29 to MC30
Post by: cncb on October 04, 2022, 09:09:25 am

Sorry, this was my change and is useful when you are trying to "play" by the search.  I will modify it to only return an error if you specify the "Play" action and otherwise return an empty response as before.

Title: Re: MCWS Response Change from MC29 to MC30
Post by: lepa on October 28, 2022, 02:28:50 pm

There is still another server error returned for valid SetInfo request when data type is Date or Date (float) and data is not changed. Could you also fix this. If server error response cannot be changed, could you please at least add that "No changes" note to Date scenarios also. This was partially fixed years ago to other field types. (https://yabb.jriver.com/interact/index.php/topic,106802.msg899975.html#msg899975)


Example:
This call will work the first time (if the value provided ultimately changes the "Date" field):

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Date&FileType=Filename&Value=2022%2F10%2F26&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3Calling it again will fail, and there is no informational "No changes" message returned.  So it's impossible to determine the difference between a benign 500 server reply and a fatal 500 error.

If the field is changed to be a String field, such as Comment, then the correct informational "No changes" is returned in the server 500 error when there are no changes, so the 500 "error" can be safely ignored.

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Comment&FileType=Filename&Value=2022%2F10%2F26&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3
And using an unformatted value for a Date field works correctly, the No changes message is returned on subsequent runs, or it just accepts the value and never produces an error.

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Date&FileType=Filename&Value=44860.7444444444408873&Formatted=0&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3

Title: Re: MCWS Response Change from MC29 to MC30
Post by: Outlaw Audio on November 05, 2022, 03:02:12 pm

Quote from: lepa on October 28, 2022, 02:28:50 pm

There is still another server error returned for valid SetInfo request when data type is Date or Date (float) and data is not changed. Could you also fix this. If server error response cannot be changed, could you please at least add that "No changes" note to Date scenarios also. This was partially fixed years ago to other field types. (https://yabb.jriver.com/interact/index.php/topic,106802.msg899975.html#msg899975)


Example:
This call will work the first time (if the value provided ultimately changes the "Date" field):

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Date&FileType=Filename&Value=2022%2F10%2F26&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3Calling it again will fail, and there is no informational "No changes" message returned.  So it's impossible to determine the difference between a benign 500 server reply and a fatal 500 error.

If the field is changed to be a String field, such as Comment, then the correct informational "No changes" is returned in the server 500 error when there are no changes, so the 500 "error" can be safely ignored.

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Comment&FileType=Filename&Value=2022%2F10%2F26&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3
And using an unformatted value for a Date field works correctly, the No changes message is returned on subsequent runs, or it just accepts the value and never produces an error.

Code: [Select]

http://127.0.0.1:52199/MCWS/v1/File/SetInfo?Field=Date&FileType=Filename&Value=44860.7444444444408873&Formatted=0&File=%2Fprivate%2Ftmp%2Ftest%2Ftrack1.mp3

Matt, any feedback on this issue?  Its not particularly crucial to those only running JRiver but becomes more so for those of us running third party apps

Title: Re: MCWS Response Change from MC29 to MC30
Post by: Matt on November 07, 2022, 08:38:15 am

I've worked with Outlaw Audio over email and this should be sorted in the next build.  Thanks for the help.

Title: Re: MCWS Response Change from MC29 to MC30
Post by: Outlaw Audio on November 07, 2022, 09:38:18 am

Quote from: Matt on November 07, 2022, 08:38:15 am

I've worked with Outlaw Audio over email and this should be sorted in the next build.  Thanks for the help.

Thanks for taking care of this Matt!