"Can't read file" - now on almost all files

[speckledegg]

I'm hoping someone a bit more technical than me can help. I went away from home for a few days, and when I returned, it seems that UMS updated, and all of a sudden, every video file seems to say "can't read file".

What's odd is that a few of them, if I go into the #transcoding folder and try to play the untranscoded one, that seems to work. It's almost as if the files are being 'forced' to transcode, and the system is saying it can't read them. None of this really makes any sense to me - I've been using UMS for years and never had a problem I wasn't able to sort out.. but this one has me stumped.

I've tried reinstalling, clean installing, removing java and then reinstalling UMS... I've fiddled with settings - all to no avail. So here I am...

I've uploaded the log file that is taken from a fresh install, with no fiddling, and I'm hoping someone can help.

ETA: Sometimes, it doesn't say "can't read file" - it just goes as if it's going to play it, and then returns right back to the folder list of files.

Thanks in advance,

Mark

[Nadahar]

"Can't read", "Corrupt data" and many other such terms are generic terms that authors of renderer software use as a "generic error" when playback fails and their code doesn't know (or doesn't care to explain) the real problem. It could just as well have said "General alert".

What it usually means is that it receives something other than it expects. UPnP AV/DLNA specifies metadata that servers and renderers exchange to try to "negotiate" what media will work and not for a given scenario. If UMS misrepresents the media by sending false metadata so that the renderer "thinks" that it can play it, but when the data is received, it's actually not as promised, either such a "generic error" or simply abruptly aborting playback is common results.

The whole point of a standard is that you think you know what the other parties will do, so it makes sense to not spend too much time writing code to hande things that can not occur according to the standard, so in that sense it makes sense that they don't "analyze and inform in more detail". It's not supposed to happen. Yet it does...

So, without knowing the specific cause in your case, I am 99% sure that UMS is doing something it shouldn't. I would just downgrade to a version that does the job, and stay there until you have a reason to upgrade. That way you don't have to be a guinea pig for every mistake made by the developers.

[speckledegg]

Thank you - I did wonder about the 'error' message.

I have actually tried reverting back to an older version of UMS, but I'm having the same problem. I am wondering if it's an ffmpeg issue? I had a look at the logs but to be honest, it may as well have been in hieroglyphics.

It seems as if something has changed which means that the videos are not being transcoded properly, or at all, or some false data is being sent which is telling UMS to stop playing, or that it can't play.

[Nadahar]

I guess it depends on how much you downgraded. I haven't really run UMS after 6.8.0, so I'm not familiar with the quirks of each version. Looking at your log, I just searched for the first attempt to play something, and checked out the metadata.

Code: Select all

<dc:title>This.Is.X</dc:title>
<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="303923" colorDepth="8" duration="0:42:29.755" nrAudioChannels="6" protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_TS_SD_EU_ISO;DLNA.ORG_OP=10" resolution="1280x718" sampleFrequency="48000">http://192.168.0.11:5001/get/108/This.Is.X.mkv_transcoded_to.ts</res>
<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="303923" colorDepth="8" duration="0:42:29.755" nrAudioChannels="6" protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_TS_SD_NA_ISO;DLNA.ORG_OP=10" resolution="1280x718" sampleFrequency="48000">http://192.168.0.11:5001/get/108/This.Is.X.mkv_transcoded_to.ts</res>
<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="303923" colorDepth="8" duration="0:42:29.755" nrAudioChannels="6" protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_TS_SD_JP_ISO;DLNA.ORG_OP=10" resolution="1280x718" sampleFrequency="48000">http://192.168.0.11:5001/get/108/This.Is.X.mkv_transcoded_to.ts</res>

Here's the corresponding transcoding command:

Code: Select all

DEBUG 2020-02-02 21:31:21.596 [ffmpeg64.exe-2] net.pms.io.ProcessWrapperImpl Starting "C:\Program Files (x86)\Universal Media Server\win32\ffmpeg64.exe" -y -loglevel info -i X:\Folder\This.Is.X.mkv -filter_complex pad=iw:iw/(16/9):0:(oh-ih)/2,scale=1280:720 -bufsize 31250k -maxrate 31250k -crf 19 -c:a copy -c:v libx264 -tune zerolatency -preset ultrafast -level 31 -pix_fmt yuv420p -f mpegts \\.\pipe\ffmpegvideo_82_1580679081292

As you can see, this isn't exactly accurate. First off, the "MPEG_TS_SD" profiles are obviously invalid for a 1280 x 718(20) video, the resolution isn't correct and the bitrate is by definition unknown for a transcoding, and thus wrong (it's probably the bitrate of the untranscoded video). There might be other problems as well, but I see no reason to dig into the details with so many errors already obvious.

My guess is that transcoding has been broken for a long time, if it ever worked for this renderer. The latest version of UMS seems to have another bug introduced regarding subtitles, which means that it will try to transcode things that really don't need transcoding. My guess is that this bug, meaning that everything with subtitles will be transcoded, is the real reason for what you're experiencing, and that the transcoding "issues" have been there for quite a while.

That doesn't explain why downgrading doesn't work though, but as I'm not sure exactly when which bug was introduced, I'm wondering if you "went far enough back".

[speckledegg]

Thanks again for the help... I tried going back to the last release of UMS 9.1.0 as that was working fine up until about a week ago - well, I say fine, there were some occasional glitches, but it was playing most things most of the time.

I'm still wondering if something in UMS 9.2.0 *and* some recent change in FFMPEG might be clashing or something? It's strange that it was working up until very recently, and now it's not working at all.

I can sometimes get some files to play if I add their extensions into the "do not transcode" box, but not all MKVs will play.

I will try going back to UMS 8.2.0 and see if that changes anything.