Why you guys just do not fix your media archive?
The metadata “stereo_mode” must be set correctly in the media file.
Anyone can just check it by ffprobe if correct metadata is set or not.
Kodi can just not use his magic ball to find what media should be played…
Funnily, I just had asked Myron over at TinyMediaManager to fix a very similar issue. So far, TMM was not putting the stereomode into the nfo file, which led to Kodi not recognizing the file as 3D within the GUI (playback of MVC worked though, I use MVC exclusively). This is not quite the same issue as here, but it lists all the options for this field in MKV files, which can also be written by any program in the respective field of an accompanying nfo with the same effect.
FSBS videos I have aren’t mine–expect it’s the same with you all. Wonder if it’s possible to ‘correct’ those FSBS w/o re-encoding, rather fixing the MKV header info. Other than the screenshot above, no idea what else needs to be fixed.
I agree with Portisch that it’s better to run a batch file to properly fix the metadata than introduce an ugly hack that will cause problems down the road. If you add the tags, then, as I understand, the files should work in Vero or any other device.
@Portisch Is there a new commit to fix an existing bug in the next nightly or should things work right now?
Hi @Portisch What about a commit fix on CE-NG in the code, since it’s EOL no need to worry about future problems. I just wander how the vero deals with it fine without metadata change?
@Portisch, thank you for working on this. On your suggestion to “fix metadata of your media”, I’m not sure how/what exactly. Can MKVMerge be used to edit the header data to “fix” these FSBS files?
I am using the Ugoos AMB6+ and I tried patching the metadata to fix the “stereo_mode” as suggested. I am playing Titanic, Avatar and Passengers in 3D ripped using MakeMkv.
Running the CE 21.2-Omega. The stereo_mode is set to block_lr as default.
Device is not getting into 3D mode by default and I have to “enable” it from the 3D glasses icon at the bottom right.
Even after modifying the metadata, it doesn’t automatically go into the 3D mode. If I pause the movie, enable 3D and exit and play again, then I see something which looks like a 3D image, but no idea what it is trying to do. Also Makemkv is reading the MVC as 1920x1080 instead of 3480x1080 as suggested somewhere in the thread above, not sure if it applies to the format I have.
Here is the original metadata.
You do not need to “fix” your metadata when stereo_mode is already set.
CE-NG and CE-NE does not fully support 3D.
Use CE22-NO.
When then it still does not work make kodi log with video component enabled and share a part of video as sample. Without a log and more info I just guess your TV does not support 3D at all…
adding on to Portisch: First, I think it is commendable, that you tried to fix it by reading this forum :-).
However, you are mixing very different issues together. MVC has nothing to do with anything side-by-side, right_left, left_right and so on. 1920x1080 is also correct for MVC and should be like that.
MVC is block_lr or block_rl only in the metadata, nothing else. For your movies, they should all be block_lr afaik. From a glance at the metadata, it doesn’t look like this is actually a 3D-file at first glance? Are you sure you extracted the MVC-stream in MakeMKV, as it is deselected by default? Usually, with 3D MVC, the first line reads something like “Stereo High@L4.1 / High@L4.1” and not just h264 (high). Can you share a sample, like 1min, of the file?
Well, I am a newbie to his, so I had to ensure to read through everyone’s issues and debugs before I dive into this deep hole and not get the “no log, no data, no problem” response from Portisch (which somehow I still managed to get. ).
About the h264, unless mvc file is different, the log snippet from Portisch a few responses above in this thread shows the Fall 2022 file with the same h264 format. Although that is 3840x1080, so can’t say they are the same, but the encoding still is the same.
Yes, I checked the MVC box before ripping. And the ugoos box does show it as a 3D file in the info.
Any help with the command to sample a 1 min clip of the file?
Easiest ist using MKVToolNix, under Output you can select splitting options by e.g filesize or time (in seconds I think if I remember correctly). Just set the time to 1 min and abort when it starts the second file and the first one is complete.
Did you get any 3D file (especially MVC) to work so far? I can provide a sample which definitely works, if you need one or download some from here: https://kodi.wiki/view/Samples#3D_Formats Number 5 is a 3D MVC MKV.
For the log from Portisch: For SBS-files (3840x1080 for Full SBS or 1920x1080 for Half SBS) it is supposed to be “only” h264 and nothing else. Think of it this way: side-by-side or top-and-bottom are already “prepared” two-eye frames in a completely normal video stream. Other than the metadata (and the weird-ish resolution for FSBS) nothing shows, that it is 3D. The player does not need to process the picture and just sends it as is (with a flag, that it is 3d, if the player knows about it → thats why metadata is so import for these files, as the player can only guess, that it could be 3D for FSBS/FTAB from the resolution, which is not 100% sure).
MVC is completely different, it consists out of the picture for one eye only and a second special video stream (which you cannot see or watch), which contains the difference between this single eye and the other eye. The player (in this case the Ugoos) creates the second eye on the fly, assembles a picture in a special format (neiter SBS nor TAB) and sends it to the TV. So there is picture processing, done on a hardware level and the player knows for sure, that it is 3D from the file itself and it should be no issue, sending the so called frame packed picture to a 3D TV.
I initially tried the ce22-no build, but it gave error as it seems to be for the x86 platform (aarch64) and not arm? I had to then use the latest ng build which didn’t work as you said they don’t support 3D.
).