INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: avid on July 26, 2023, 06:01:05 am
-
Maybe it's a URL encoding problem, but I can't see it.
When I try to play a video file via MCWS it doesn't do anything, though returns status OK. Not quite true - if there is anything already in the queue, it starts playing that, but it won't replace the queue or add to it. So that means it is recognising some sort of play command.
So I can successfully play a file with (e.g.) mc31 /replace "D:\Video\This Is Spinal Tap.mpg"
But if I use MCWS, neither of these do anything:
http://localhost:52199/MCWS/v1/Playback/PlayByFilename?Filenames=D%3a%5cVideo%5cThis+Is+Spinal+Tap.mpg
or
http://localhost:52199/MCWS/v1/Control/CommandLine?Arguments=%22/Replace+D%3a%5cVideo%5cThis+Is+Spinal+Tap.mpg%22
Different values of "Location" seem to make no difference.
Any ideas? Does it need non-standard URL encoding?
If I get absolutely desperate, I will explicitly launch a "mc31" sub-process to do this, but that seems horrible!!
-
Try using %20 for spaces, I'm not sure the + shortcut works in filenames.
-
Thank you - that was it. So it's as I guessed - a non-standard understanding of URL encoding.
My .Net software controlling MC uses the standard library URLEncode() function:
SendMCWS("Playback/PlayByFilename?Filenames=" + HttpUtility.UrlEncode(path));
But I will trivially post process the encoded string to turn "+" into "%20" and all should be well.
-
I can probably make it handle + in there. Its handled in some spots but might have been forgotten there.