"No Entry" sign for info about BBC mp4 video file

I have a HDR FOX-T2 purchased in the UK, running firmware 1.03.12 and custom firmware 3.02.

When I was last in the UK I missed some BBC programs and picked up the mp4's using get_iplayer, then transferred them to my humax. linux avprobe shows me all of the metadata on each of the files, and the humax plays them perfectly.

However, the info "i" button on the remote control simply brings up the barred circle "No Entry" icon when the file is selected from the media display. Also, when the file is playing, the "i" button simply shows the name of the file.

I have a lot of files with not-very-helpful names, and all I can do to identify them properly is to offload them to a linux desktop and ask avprobe about the metadata. Is this my best option, or have I overlooked something?
 
'Fraid not. The info function accesses metadata stored in the .hmt sidecar file for a .ts, but the .hmt is constructed from metadata in the broadcast, and in any case the Humax firmware won't even look for a .hmt for any other video file.

There is an off-the-box utility by Raydon called AV2HDR, which (assuming the input file is compatible) remuxes it as a .ts and creates the sidecar files to go with it, but I have no idea whether it tries to extract any metadata from the input file.

Presuming the metadata is stored at the beginning of a .mp4, it might be possible for the skilled parties to extend the WebIF to display metadata for .mp4's, but that would only be in the WebIF media browser (if at all) - making the standard user interface do it would mean remuxing into a .ts.
 
In Web-If>Browse Media Files if you click on the file titles, the metadata appears in a pop up window. This includes synopsis information for mp4 files downloaded from Get_iPlayer.
 
Thanks very much (everyone) for your collectively helpful suggestions.
  1. Black Hole: yes, I had already thought of using the linux avconv program to do something similar. However, remuxing can often consume a lot of processor time and so I only do it when I have a special requirement and am prepared to make the effort.
  2. MontysEvilTwin: yes! You have pointed out something that I am embarrassed to admit I overlooked. I have just tried it and all the metadata is displayed in the browser pop-up panel.
  3. MymsMan: yes, that was my original point. They were renamed as part of a hard disk corruption recovery process. Before MontysEvilTwin gave me the answer, my only option had been to copy each file off the box, read the metadata, then rename the copy on the box. This was a laborious and time-consuming option. However, now I have a way to view the metadata on the box, assigning meaningful names is a small effort to achieve my objective.
 
However, remuxing can often consume a lot of processor time and so I only do it when I have a special requirement and am prepared to make the effort.
Just as a point of information, remultiplexing is not a processor-intensive process unless the target video/audio codec is different from the source. Simply packaging an existing video/audio stream in a different overall "wrapper" (which is what we mean by remultiplexing, not re-encoding), is (or should be) very quick.

I am pleased to learn the metadata facility is already included in the WebIF. Not having had cause to try it, I couldn't be sure. Perhaps someone can confirm whether or not AV2HDR also interrogates and transfers any metadata?
 
Perhaps someone can confirm whether or not AV2HDR also interrogates and transfers any metadata?
AV2HDR-T2, being primarily a non-native import utility, does not attempt to recover metadata from sources.
A non-native source known to contain EPG metadata would first require converting to 192 byte T'S container format (including the EIT stream) before importing to the T2 and then further processed with the sidecar utility. A bit long winded, but doable. In this particular case I think MET'S solution is the best option.
 
Just as a point of information, remultiplexing is not a processor-intensive process unless the target video/audio codec is different from the source. Simply packaging an existing video/audio stream in a different overall "wrapper" (which is what we mean by remultiplexing, not re-encoding), is (or should be) very quick.
Agreed, but not always so easy for me using the linux tools. I switched from the older ffmpeg to avconv because it is "more intelligent" about choosing the conversion you probably want to perform, and so it requires a smaller number of arcane command-line parameters. (Sometimes, avconv doesn't need anything beyond the input and output filenames.) However, I usually find it has decided my file needs lengthy re-encoding even though I was sure that re-multiplexing was not only possible, but "obviously" what I desired. My choice of terminology was sloppy, so thanks for clarifying.
 
Just a postscript to finish my story. I am well into the restoration process and discovered some of my recordings were not mp4, but were "bare" ts files. The latest sidecar (2.2) restored their metadata from the original transmission streams perfectly. Thanks to the author and maintainers of this valuable tool!
 
Back
Top