Some videos not playing after upgrading from v13.6 to v14.12

[mik_s]

I can't see what is different about that video that would make the the TV display a black picture.

I did see one clue in the 13.6 logs that UMS does see something that is not right so it does transcode instead of remux, but I don't know what it is or why 14.12 is different.

Code: Select all

net.pms.encoders.FFMpegVideo Not muxing the video stream with FFmpeg because the video codec is not the same as the transcoding goal.

Exactly what that goal is I have no idea.

I see that there is not a transcoding profile set for this TV so it is using the default "MPEGPS-MPEG2-AC3" one. Maybe it will work using one with h264.
Try this conf out, I changed it to "MPEGTS-H264-AC3" which is what my PS4 uses so I assume this will work on your TV since it is also from Sony and around the same time period.

[binary512]

Re: "Try this conf out, I changed it to "MPEGTS-H264-AC3" which is what my PS4 uses so I assume this will work on your TV since it is also from Sony and around the same time period."

Ans: The new conf file appears to be a step backwards...most of the video files do not even show up in the normal listing, nor in the #Transcode# folder, so am unable to play them.
There was only one file that played from the originals, and that was "Test.Fail.3.Skips every 3-4 seconds". It played alright, just as in the previous configuration. And that is the one with h264 v4.2.

I have attached a new log file in the hopes it may show something new.

Update: I believe I found the problem with this last video and why it is not playing properly. It appears to be the MKVTOOLNIX utility (current version 92.0). If I take a good MKV file (that plays properly) and run it through MKVTOOLNIX (to remove subtitles, for example), the resulting file is no longer playable, even though it has the same valid encoding as the original, which IS playable. I will see if older versions of MKVTOOLNIX are available to download. If they are, I will see which version introduced this problem and get back to you.

Thank you for all your help.

[mik_s]

OK that transcoding profile is no good so the default one was correct.

It makes sense that removing the subs from the MKV file would stop it working as UMS is trying to remux instead of transcode which is the problem with the black screen.

Thinking about it the problem is probably with choosing to remux when it shouldn't.
It is supposed to transcode to mpeg2 but instead it is copying the h264 stream. The TV can usually play this but this is being sent as mpeg2 so the video cannot be decoded resulting in the black screen.

I did a bit of testing on my TV by commenting out MKV as supported and I think this is the case, it did the same thing by remuxing instead of transcoding.
Instead of a black screen it just would not play but may be because the test file had no audio.
If I remove h264 from the f:mpegps|mpegts section it will start to work again as it knows it does not match the goal

Code: Select all

codec "h264" failed to match support line f:mpegps|mpegts   v:mjpeg|mp4|mpeg1|mpeg2|wmv   a:aac-lc|he-aac|ac3|dts|lpcm|mp3|wma   m:video/mpeg
Not muxing the video stream with FFmpeg because the video codec is not the same as the transcoding goal.

This is definitely a bug as it should be checking the transcoding profile first instead of just the mpegts|mpegps section.

I think the same trick would work in the conf for your TV for the time being till it is fixed properly and I don't think your videos will be in these formats anyway so should not affect them.
See if this is any better.

[binary512]

I have uploaded a debug log file and I was wondering if you could see if/what there is any difference in the way the two files (before MKVTOOLNIX and after MKVTOOLNIX).
The first filename is: "Test.Fail.5.Internal Subs (pre MKVTOOLNIX-works).mkv" ; This file works fine in UMS.
The second filename is: "Test.Fail.5.v91.mkv" ; This file does not play in UMS...black screen and skips every 3-4 seconds.
The second file fails to play in UMS, but SHOULD work if all that MKVTOOLNIX is doing is removing the internal subtitle.

I am hoping there is something in the log file that I could tell the MKVTOOLNIX developers that could fix this problem.

Thank you.

[mik_s]

That shows the same thing, UMS thinking it can remux instead of transcode when there are no subs otherwise the subs have to be burned in to the video which requires a full transcode.

Did you try this new conf?

[binary512]

Re: "Did you try this new conf?"
Ans: Yes, see the post above (Mon Jun 09, 2025 4:09 pm).

[mik_s]

From those logs that was not the conf I posted as it still had the old setting. I downloaded it to check I attached the right one.

Make sure you delete the old one first then replace it with that one.

[binary512]

I removed the older conf files and used the most recent one you sent. Everything is working EXCEPT one file...
File "Test.Fail.1b.Internal Subs (audio and subs out-of-sync).mkv"
--- Fails when selecting from the normal menu. Audio/video out of sync with each other. Subtitles are hit & miss.
--- Works correctly when selecting FFMpeg and VLC from the #TRANSCODE# menu.
--- Fails when selecting MEncoder from the #TRANSCODE# menu. Audio/video out of sync with each other. Subtitles are hit & miss.

The log file is attached.

[mik_s]

Good to see that fixed the main problem. I'll make an issue on Github as this behaviour is incorrect in V14.12

That file that is still out of sync because the "Defer to MEncoder when transcoding problematic subtitles" option is still enabled so is using MEncoder instead of FFmpeg.
It might have re-enabled after changing versions. If you turn this off it should work normally.

[binary512]

Re: That file that is still out of sync because the "Defer to MEncoder when transcoding problematic subtitles" option is still enabled so is using MEncoder instead of FFmpeg.
Ans: That fixes EVERYTHING!!!! Thank you.

Re: I'll make an issue on Github as this behaviour is incorrect in V14.12.
Ans: Can I follow this issue on Github? Can you send me a link to monitor so I know when it has been fixed. Do you know what upcoming version the fix will appear?
Also, when it is finally fixed, do I just need to put the "h264" option back in the renderer configuration file? Is there anything else that I should change?

Thank you for all your help. It is greatly appreciated.