[Solved] M2TS Files Now Seen As MP4s After 2.6.0 Update

[ExSport]

You can disable AviSynth engine directly in GUI or uninstall it if not needed. I never used it and don't have installed it because I don't need 30->60 fps feature etc.
To be on gigabit it doesn't mean you will achive it (without good tweaking you will never get more than 500Mbit or even 200Mbit)
I can't say what is your problem exactly but on my PS3 I don't have problems with higher bitrates than 150. So if buffer is not empty at times it stutter it seems to be network is problem or PS3 (check fw version or make fresh reboot).
You can try to limit your network bandwidth to something smaller than 150 if it will fix your problem (set global limit in GUI or in PS3.conf for this renderer only).

[Triplefun]

Thanks for this. I have removed the LAV codec install, reinstalled UMS 2.6.1, did not include AVISYNTH and only enabled FFPEG. Note I am using WHS v1. I have had to force m2ts transcoding in order for it to recognise all my files. I then had some fun exploring the stuttering and found a link between the 'max bandwidth' I can play on the PS3 with the UMS load memory setting. If set to the default (768MB) I peak at 200mbs. If I set it to 512MB I peak at only 50mbs. If I set it to 1200MB I peak at 120mbs. And 980MB gives about 250mbs. Note I can do a file transfer between my W8 64bit PC and the WHS at 110MB/s so the network should be OK. There have been instances in the past with PMS, not very many and some time ago, when I have seen 500mbs. I have the UMS memory restriction set to 0. It's obviously a very sensitive area with lots of trade offs.

I just had a look at the UMS log file and noted it was 46MB after 14 minutes of up time.

The PS3 had an estimated network speed of 256Mb/s. This used to be 500Mb/s. Note I have let it 'automatically' determine the renderer. When I set it to PS3, the Samsung AllShare refuses to work.

I also get thousands of the following log file entries with variable buffer size (dependent on content). '242822' was the smallest, '965495' was the biggest I could find.

DEBUG 2013-04-19 10:35:09.203 [Thread-27] [vob @ 02863ae0] buffer underflow i=0 bufi=830159 size=965495
DEBUG 2013-04-19 10:35:09.203 [Thread-27] [vob @ 02863ae0] packet too large, ignoring buffer limits to mux it

For your reference this was the initial file load entry in the log file ..

INFO 2013-04-19 10:33:00.171 [New I/O worker #1] Starting transcode/remux of xxx.m2ts
DEBUG 2013-04-19 10:33:00.187 [ffmpeg.exe-4] Starting "C:\Program Files\Universal Media Server\win32\ffmpeg.exe" -y -loglevel warning -threads 4 -i "D:\shares\Videos\Documentary\yyyy\xxx.m2ts" -threads 4 -ac 6 -g 5 -q:v 1 -qmin 2 -c:a copy -c:v mpeg2video -f vob pipe:
DEBUG 2013-04-19 10:33:00.281 [ffmpeg.exe-4] Attaching thread: ffmpeg.exe-4
DEBUG 2013-04-19 10:33:00.515 [Thread-27] [mpegts @ 027b3a80] DTS discontinuity in stream 2: packet 4 with DTS 53994170, packet 5 with DTS 54007504
DEBUG 2013-04-19 10:33:00.531 [Thread-27] [mpegts @ 027b3a80] max_analyze_duration 5000000 reached at 5004000 microseconds
DEBUG 2013-04-19 10:33:00.562 [Thread-27] [vob @ 02863ae0] VBV buffer size not set, muxing may fail
INFO 2013-04-19 10:33:06.187 [StartPlaying Event] Started playing xxx.m2ts on your PlayStation 3
DEBUG 2013-04-19 10:33:06.187 [StartPlaying Event] The full filename of which is: D:\shares\Videos\Documentary\yyyy\xxx.m2ts and the address of the renderer is: 192.168.1.7
DEBUG 2013-04-19 10:33:11.046 [Thread-27] [vob @ 02863ae0] buffer underflow i=0 bufi=234004 size=242822

[SubJunk]

Yeah those errors/warnings are normal when there's no rate restriction, nothing to worry about

[SubJunk]

AYColumbia, did you notice that I gave the links to 2 more test versions?

[AYColumbia]

AYColumbia, did you notice that I gave the links to 2 more test versions?

Yep, didn't get around to it until now. Drum roll please...

Neither worked.

[Triplefun]

Thanks again - I set the rate to 500mbs and now it plays with no stuttering and the PS3 display rate peaks at 160mbs. Also, as you said, the log file is a lot less cluttered !!!

[ExSport]

@Triplefun: I am not saying it is your case but in general noone should trust windows what they show:

Note I can do a file transfer between my W8 64bit PC and the WHS at 110MB/s so the network should be OK

110MB/s is 880Mbit what is quite impossible also on server platform with enterprise switches Windows caches local and network READ/WRITES so in most cases when Windows will finish copy, you can still spot that there is huge network bandwidth or disk R/W.
Sometimes also 1 or 2 minutes after finished copy, file is still not transftered and is running in background (check resource monitor). Because of that sometimes shown speed is not real.
And yes, as a SubJunk said, buffer under/overflow is when you will set e.g. very high quality (150Mbit bitrate) with very low bandwidth limit (30Mbit). It will generate buffer problems and spams the log
When you set 500Mbit bandwidth limit, you used 0=no limit or default UMS setting 110Mbit? Weird if changing 0 to 500 will do anything. EDIT: Ok, it is bug of FFMPEG: Git
Also size of "Java heap size" should have no effect on size of transcoded stream as you described. MEncoder or FFMpeg will still generate same bitrate of transcoded file but only difference is that with more memory there will be less stuttering problems due to out of memory.

[SubJunk]

AYColumbia, did you notice that I gave the links to 2 more test versions?

Yep, didn't get around to it until now. Drum roll please...

Neither worked.

That's really strange... Can you please re-test them? Maybe it is something that only happens sometimes. Please test "486930e" and "a21a33a" a few times to see if they consistently have/don't have the bug. It's annoying I know, but those 2 versions are barely different from eachother so this will help

[AYColumbia]

AYColumbia, did you notice that I gave the links to 2 more test versions?

Yep, didn't get around to it until now. Drum roll please...

Neither worked.

That's really strange... Can you please re-test them? Maybe it is something that only happens sometimes. Please test "486930e" and "a21a33a" a few times to see if they consistently have/don't have the bug. It's annoying I know, but those 2 versions are barely different from eachother so this will help

Well, I know that "486930e" works for sure because I've gone back to it and it still works fine. It's worked EVERY time I've installed it which is 3 times. I'll report back when I confirm "a21a33a" works or not.

[AYColumbia]

Okay, you were right in that something wonky must have happened when I tested it the first time. The first thing I noticed is that it recognized my Oppo (kind of) and the Roku as Unknown. When UMS-a21a33a didnt' work, it recognized the Roku as some media device and the Oppo as Unknown.

I installed it twice and it worked both times. First after uninstalling UMS-486930e but not doing a clean install and then after uninstalling it and then re-installing using a clean install. Worked great both times. It's my "go to" version now.

BTW, I have the Oppo BDP-103 and UMS has the 83 and 93 but not the 103. Any chance of getting the 103 added? BTW, the 103 is a media renderer as well as a media player where the 83/93 are only DMPs.