My experiences using the Zidoo REST API for playing video and selecting audio/subtitle tracks

I found the existing API useful for this task, but a bit quirky and very fussy about timing. For what it's worth, I'm using the API on a Z10 Pro running firmware 6.4.62.

I wanted to be able to start a video with pre-selected choices of audio and subtitle tracks, rather than fumbling around after the video starts changing things. The interface looks like this:



I'm using either of these calls to start a video playing:

GET /ZidooPoster/PlayVideo?id=[id]&type=0
GET /ZidooFileControl/openFile?path=[path]&videoplaymode=0

The tricky thing here that I discovered is this: the Zidoo gets cranky if you use either of these calls to start a video while another video is currently playing. The new video will start, but will often stop abruptly a few minutes into playing if the previously playing video hadn't been explicitly stopped.

So, in order to prevent this, it's necessary to check the status of the player first with this API call:

GET /ZidooVideoPlay/getPlayStatus

This has its own annoying quirk. For no reason I can fathom this call occasionally returns a 804 error, claiming the URL is invalid. But submitting the same URL again will then work without complaint. This requires a retry loop in case the 804 error occurs.

If nothing is playing you'll get a status of 806 in return (although I treat anything other than 200 or 804 as meaning nothing is playing).

By examining the path returned by a 200-status getPlayStatus result, as status.video.path, you might see that the video you're trying to play is already playing. If a different video is playing, or if you don't care about restarting the same video, you then need to use this API call to make sure playing has stopped:

GET /ZidooControlCenter/RemoteControl/sendkey?key=Key.MediaStop

Experimentation led me to wait at least 500 milliseconds before sending another command after sending this one.

If all I want to do is start up a video and let the Zidoo make its own choices about audio and subtitle tracks, I'm done at this point. But to continue on and change those tracks, the following needs to occur:

First, wait at least 250 milliseconds after starting playback and before doing anything else.

Next, it would be nice if I could just now send the audio track and subtitle track commands immediately, but that is not the case. It's necessary to again check player status, in a loop, once again using this API call...

GET /ZidooVideoPlay/getPlayStatus

...until it is certain that the video is now playing. Not until then will the audio and subtitle API calls be effective. And there's another twist to worry about too: if the video isn't starting from the beginning, but is instead picking up in-progress from a previous play point.

Why does this matter? Because if a video has played beyond the first minute, is stopped, then is played again, the user will be presented with an on-screen dialog asking if they want to continue playing from the last playback point, or restart the video.

So long as that dialog remains on the screen the audio and subtitle API calls won't work.

My work-around was this: getPlayStatus also tells you, if a video is playing, the current playback point in milliseconds, via status.video.currentPosition. If I see anything later than 58000 (58 seconds) I forego making any immediate audio/subtitle track changes, and instead prompt the user if they want to re-issues those selections, giving the user time to first respond to the dialog, or ignore it until it times out (10 seconds? 15?).

Once I know the last video (if any) has been stopped, the selected video is playing, and no on-screen prompt is in the way, I can finally send either or both of these API calls:

GET /ZidooVideoPlay/setAudio?index=[zero-based offset into list of audio tracks]
GET /ZidooVideoPlay/setSubtitle?index=[0 for no subtitles, or one-based offset into list of subtitle tracks]

If I issue both calls, I wait 250 milliseconds between each. I discovered if I sent API calls too quickly, one after the other, they might be ignored and/or the player could get into a weird state with out-of-sync audio or stuttering, jerky video playback.

 

If anyone would like to see a live demo (limited for copyright reasons, and because I don't want strangers starting up movies on my Zidoo) of my personal video library application, it can be found at https://shetline.org. You can use the credentials demo / checkThis%0UT (that's a zero, not an oh, in the password).

For real-life personal use this web application provides me adaptive video streaming at 480p-1080p, as network conditions allow, and remote download of full MKV files. As a demo user you're stuck with clips no longer than 3 minutes at crappy non-adaptive 320p resolution.

The source code is available at: https://github.com/kshetline/video-server