Bug Report: MKV Tags Trigger Transcoding

[lulzyatlas 20]

No logs for this one, but after a bit of troubleshooting, backtracking, and testing (my goto problem solving routine) I've narrowed this one down.

 

The issue was observed on server versions 3.0.5597.0 and 3.0.5597.1

 

MKV's muxed with a certain variety of tags would trigger the server to attempt a transcode despite the file and codecs being supported on clients, after remuxing the issue doesn't appear to occur with Global Tagged MKV's, but rather only MKV's with the individual streams each carrying a tag stream. Whether or not this is due to a symbol or unsupported character in these tags I didn't think to discover. However after remuxing with global tag/independent tag streams, and no tag streams at all, the files proceeded to directplay and directstream as expected.

 

Something tells me the tags are confusing the server's codec identification, but as I've never looked at the source I couldn't say where or how that process takes place in the cogs of the program, but I can confirm that tagging a set of tags (may or may not be dependent on what's actually in them) directly to a video stream or audio stream will trigger transcoding, regardless of the actual media codecs.

[Luke 37024]

It is best to just look at a specific example including the media info, transcoding log and what app you're doing it from. 

[lulzyatlas 20]

I resolved this issue a few days back without opening the dashboard (just watching for that tell tale ffmpeg.exe process) and transcoding logging disabled so I'm not sure I'll be able to provide a log relevant to the case.

 

From memory, I recreated the issue a few times for confirmation on the Android app, MBC, and Emby Theater, which is what led me to believe it's something the server sees with the file.

 

The only thing separating the file from my other media was the tags bearing the '~' characters, once they were remuxed with a Global Tag having only ':' as the non-alphanumeric character, they proceeded to direct* playback fine on all 3 client types.

 

If I get the time to do some error hunting I'll try to mux up a file with those kinds of tags again and go for a logged recreation.

Edited May 6, 2015 by lulzyatlas

[ebr 14904]

If you ever got transcoding out of MBC/MBT something isn't configured properly (assuming you're on your local LAN).

[lulzyatlas 20]

If you ever got transcoding out of MBC/MBT something isn't configured properly (assuming you're on your local LAN).

I haven't gotten back to reproducing this on log as it's been resolved since that post when I stripped the tags. I can't recall if it affected MBC but it definitely forced a Transcode attempt for MBT and Android when certain symbols were present in the tags. I've confirmed that much. Alas, it's no bother for me now, if I have the time I'll try and reproduce the behavior.