Child Item

Videos losing media_info in list_folder

A number of mp4 files that have been unmodified for a few months and which used to show metadata, have started losing their media_info and are now showing the 'file' tag when retrieved through the API with list_folder. I was wondering if this is something with a known cause and if there is anything i can do to make them show as 'video' with metadata again?

Thanks in advance for any advice,

-lite

stdClass Object
(
    [.tag] => file
    [name] => <filename>.mp4
    [path_lower] => /<filename>.mp4
    [path_display] => /<filename>.mp4
    [id] => id:4zVIEn7c_-AAAAAAAAAAXw
    [client_modified] => 2019-08-21T10:28:12Z
    [server_modified] => 2019-08-21T10:28:12Z
    [rev] => 015909e07b8a971000000016298d580
    [size] => 23850103
    [is_downloadable] => 1
    [content_hash] => c5689d5d31cc499ec759552c1f5f092cf6cb3dca5923d40d07a2e7f4973e34ea
    [file_lock_info] => stdClass Object
        (
            [is_locked] => 
        )

)

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

@litemotiv The 'media_info' functionality on /2/files/list_folder was deprecated earlier this year, and retired this month. You can find more information in the documentation for the 'include_media_info' parameter for /2/files/list_folder.

If your app(s) need access to the media information for files like this, please update your app to retrieve the media information from /2/files/get_metadata instead.

By the way, to clarify, the top level ".tag" in your sample is the subtype for the returned "Metadata" object, which has always been one of "file", "folder", "deleted". That hasn't changed. By the "video" tag you mentioned, it sounds like you're actually referring to the ".tag" value for the nested (as FileMetadata.media_info.metadata) "MediaMetadata" object, which would be one of "photo", "video".

All comments

Здравко

Hi @litemotiv,

Metadata is old and seems going to be deprecated. Don't rely to them anymore.

Hope this helps.

Greg-DB

If your app(s) need access to the media information for files like this, please update your app to retrieve the media information from /2/files/get_metadata instead.

litemotiv

Thank you for the explanation Greg. I gather this means that metadata now needs to be retrieved per individual file? This does increase the latency somewhat significantly i assume? I have for instance a number of folders containing a collection of video files, before i issued a single lookup using list_folder with include_media_info set to true to retrieve information such as the length of the videos.

When issuing separate get_metadata calls for each file, the time it takes to retrieve this on a folder increases from around 1 second to 4-5 seconds, i assume this also means that the load on the Dropbox side may increase accordingly. Is this the recommended approach from this point going forward?

Greg-DB

@litemotiv Thanks for following up. Yes, you'll need to call /2/files/get_metadata once per file for which you want to retrieve the media info. This is the recommended approach now. Depending on your use case, this may unfortunately increase the overall latency. I'll be sure to pass this along as feedback.