[MX Player] Are G. Bee:
Thank you for your reply but I am not entirely sure what you are trying to point out from that link you provided? Which metadata is "some"? Not to mention I am a Python developer and that is what...C? ;) Also that link is 2500+ lines, and I would be more then happy to look at it further for any relative information that it might contain but without knowing why I am looking, what I'm looking at, or what I am looking for, I really don't want to spend the whole night reading a novel of code I probably wouldn't make heads or tales of anyhow? ;) I don't mean to be disrespectful in any regard, but please understand that I can only compile the FFmpeg code following instructions, I have no idea what the code means.

I am also not sure if I am following all of what you are saying with regards to "If HW decoder is used for network source, MX does not uses FFmpeg at all unless source is from local server such as 192.168.x.x or localhost(127.0.0.1)"? Are you suggesting that the media must be local to the device it is playing on (ie; attached via USB)? Or are you suggesting that as long as it is within a local network then H/W decoder should use FFmpeg (ie; all addresses starting with 192.168.x.x)? Also note that regardless of this statement, I know for fact that MX Player, network or local, still reads the stream's "language" tag's just fine and if found, uses that information to compile the generic subtitle stream's title. This will be explained in more detail in a few moments. Now if it helps to clarify further I am currently streaming the videos through my local network. The drive with the files are hosted on a PC in the room next to me using a Windows shared folder (SMB), and the device playing them is a Rikomagic MK902 Android TV Box, which is right in front of me. I am not trying to remote play the files outside of my local network.

I have also looked at the available API but in all fairness it does not really have any relevance towards my issue...at all? The title of this thread suggests I am referring to the names of the individual streams within a video, and the conversation so far has had nothing to do with the display title of the movie itself? I am not trying to display a new title for the video as a whole, I am trying to figure out which metadata tag MX Player reads to obtain it's stream title information from; as in the title(s) that are displayed when you click either the subtitle or audio buttons while a video is playing. That said, I am sure that ES File Explorer is launching it via an Intent but I have no way to access/alter what it is/isn't sending along with the URL. Also from my experiences, there are no actual issues accessing file metadata via SMB as I can access that information via the file's properties from within any explorer, Windows or Android? The only real question is whether it was implemented or not by the developers?

Now the reason I ask is because I would like to properly encode my files so that the titles I set for the stream(s) are displayed in place of the Generic titles that MX Player seems to use.

Here is an example of the current generic stream title(s) that display in MX Player:

Audio track #1 - English

The first part of the title "Audio track", is generic. The "#1" represents the stream number, and if there are two audio streams then it might say "#1" and/or "#2". Last but not least, " - English" is the detected language of the stream. I know that it is detecting the language metadata because when I remove the language tag from the file, the generic title changes to "Audio track #1". That said, my video files already have embedded titles associated with each audio/sub stream(s), and although I understand the need for generic names for files that do not have such metadata, I do not understand why this metadata is being ignored when it is available?

I do appreciate your efforts to respond, but in all fairness I am not quite sure if you really understood my question? ;) If you did, and my lack of understanding the C code is stopping me from understanding what you were trying to suggest, then please let me humbly apologize and ask that you further clarify what you were suggesting, in layman's terms, for the less C-educated individuals like myself. :)

Here is example of the current generic titles, next to them are the custom titles that are already embedded into my files and should be replacing the generic ones.

Audio:

(generic) Audio track #1 - English <--> English (5.1) (custom)

(generic) Audio track #2 - English <--> English (Stereo) (custom)

Subtitle:

(generic) Track #1 - English <--> English (Full) (custom)

(generic) Track #2 - English <--> English (Parts) (custom)

It was suggested within the first response that MX Player "should" first look for the stream's title, then use the generic if none was found, but after some testing this does not appear to be the case. On first thought I had the exact same assumption because it really seemed like the logical/standard way to go about it, but after the testing was done I am now unsure and I would like some verification as to whether MX Player is actually setup to check for the stream's title, or not? If so, then I assume I should be filing a bug report? If it isn't, then I can simply put in a feature request to have MX Player read custom stream tags first, then imply the generic tag if none is found.

After that, all I'll need to do is be patient and hope it is approved/added in the near future.... ;)

Hopefully my further explanation has helped clarify the issue for you!

**UPDATE**

I think I might now understand more of what you are suggesting.

1. The "titles" are submitted with the intent, and not pulled from the metadata of the file; provided it is streaming.

2. Because the intent generated by ES File Explorer is not submitting the stream's title along with their intent, MX Player is defaulting to generic tags due to lack of provided information.

I should also point out that the display of the custom titles fails on locally played files just the same, but they are also being initiated by ES File Explorer so I will have to test them from within MX Player itself before I will know for sure if this is the issue

Looking back at the API, I only see "video_list.name" & "subs.name", which imply the Intent could at least handle the subs stream titles, but nothing about the audio streams seem to be defined? That said, I still cannot really access the intents that are being sent anyhow as they are being created by ES File Explorer when you launch the file :(

**UPDATE 2**

I have tested the files through MX Player directly and there is no change to the stream titles at all. It does appear that the language metadata is read regardless of whether it is played locally, or via a SMB connection so it appears the title metadata "could" be read, but it appears that it is being disregarded. Either way, the purpose of my app is to prepare the files with as much usable metadata as possible. How MX Player, or the application that launches MX Player via intent, handles the data I have provided within the media file is not really something that relates to what I am trying to accomplish, nor do I have any control over.

The first response I received suggested that MX Player should be using the stream's title, if found, but no matter how I test it this does not appear to be the case. As mentioned before, I already know that the stream's language metadata is being used to form the generic stream's name as the removal of these tags actively effect the stream name's end result, so access to the title information should be possible.

Unfortunately I am still somewhat confused with the suggestions/lack of clarification made within the second post but from what I could gather, H/W decoder has something to do with it if it is played via the network as it will not use FFmpeg. I'm assuming this suggests that FFmpeg is being used to gather the metadata, and because H/W decoder doesn't invoke it via the network(?), it will not display?

All I can say is that no matter which decoder is selected, whether it is played locally or via a local network, the stream's titles are not implemented. Although I would obviously prefer the first suggestion to be true :P, I have no problems if it isn't, and would be happy to wait in line for a feature request to be implemented (if it all). I would just like some solid clarification as to whether MX Palyer should be using the metadata or not, and if so, should I file a bug report after all the testing I have done?

If you would like to reproduce this issue, please modify the below FFmpeg command with a video & srt file on your system and give it a run:

ffmpeg -fflags +genpts -i "Video.mp4" -i "Video.srt" -map 0:0 -map 0:1 -map 0:1 -map 1:0 -map 1:0 -c:v copy -c:a:0 copy -c:a:1 copy -c:s:0 mov_text -c:s:1 mov_text -map_metadata -1 -map_chapters -1 -metadata:s:a:0 language="eng" -metadata:s:a:0 handler="English (Stereo)" -metadata:s:a:1 language="eng" -metadata:s:a:1 handler="English (5.1)" -metadata:s:s:0 language="eng" -metadata:s:s:0 handler="English (Full)" -metadata:s:s:1 language="eng" -metadata:s:s:1 handler="English (Parts)" -movflags faststart "output.mp4"

This should result in a file named "output.mp4" with 2 audio streams & 2 subtitle streams; all of which have two metadata tags set on each stream; title & language. You can use MediaInfo for your OS (CLI & GUI versions available - http: //mediaarea.net/en/MediaInfo/Download) to verify that the information is set on the file. If you prefer to use FFmpeg to obtain the metadata then look for handler_name under each stream, instead of Title. After testing the stream names for both Audio/Subtitle streams, you can remove the language tags from the same command and run it again, you will see that even with the Title tag set, the generic stream name will only change when the language tag is set/unset.

Thanks again!