list_folder with include_media_info=true return empty entries array.

Thanks for the clarification.  

It would be helpful if that was explained clearly in the documentation.
I have to say that I think this is a very poor way for the API to respond in this case.

I understand that the media info might not exist yet.

That's fine. I appreciate that it could take time to generate.

However I think it is very misleading to return an empty entries array.  That indicates that the folder is empty when it is clearly not true.  That leaves my application thinking that this folder is empty and that there is nothing to see or do in this folder which is clearly not the case.  

Would it not make more sense to return a normal listing dataset containing the same entries as would be returned if include_media_info=false but include something to indicate that the media_info is pending.

You could return something like this;

"entries": [
  {
    ".tag": "file",
    "name": "myphoto.jpg",
    "path_lower": "/mypath/myphoto.jpg",
    "path_display": "/mypath/myphoto.jpg",
    "parent_shared_folder_id": "1234567890",
    "id": "id:abcdefghijklmn",
    "client_modified": "2015-09-30T09:08:43Z",
    "server_modified": "2017-02-28T15:15:33Z",
    "rev": "1234567890",
    "size": 5685499,
    "media_info": null,
    "sharing_info": {
      "read_only": false,
      "parent_shared_folder_id": "1234567890",
      "modified_by": "dbid:abcdefghijklmno"
    },
    "content_hash": "1234567890abcdefghijklmno"
  }
]

At least that way my application can decide how to proceed.  

I could flag files with media_info=null for later processing or I could download the images that are missing media_info and generate it myself.