[BUGs]...UMS v3.0.0-a3

[ExSport]

• During the installation I set 2GB of memory for UMS. It is saved in registry. Unfortunately when UMS is starting it rewrites value to 1280 so 2GB is lost and not used.
• ffmpeg engine is using wrong DLNAOrgPN value so file is unplayable e.g. on PanTV. Check link. Right now I am not sure if it is true for remuxed or also transcoded files. I tested so many scenarios so my brain is overloaded little bit. Using DLNAOrgPN=false made files playable (PN is not sent in this case)
• [engine] name at the end of file name means UMS should remux or transcode file depending on audio/sub priority. When subs are not needed => remux, transcode otherwise. It is something like auto-smart-engine. But if [engine] name is at the beginning like in transcode folder, UMS should force transcoding like it works for MEncoder. It is not true when "remux if possible" is enabled for [FFmpeg] engine. So there is inconsistency in logic between these two engines! Not possible to force transcoding this way.
• When video have more than one audio tracks and second, third,4th...is DTS then for ffmpeg engine first track is loaded and tagged as DTS also in case it is AC3. It is because DTS muxing doesn't use -map parameter so always first track is loaded. When e.g. playing second DTS track and first is AC3, tsmuxer mux it as DTS so no audio is present on renderer.
• when ffmpeg engine is used with subs, quality is very very poor also with max quality set =1Gbit. Mencoder w/wo subs and tsmuxer is OK. Also ffmpeg without subs is OK but it is because of bug mentioned earlier that file was remuxed also in case transcode folder was used.
• It seems ffmpeg generates hw incompatible mpegts files. I tried to remuxed mkv with h264 so ffmpeg is using annexb and mpegts output. This file is unplayable on PS3 also when I remuxed them on PC and uploaded it directly to PS3. When I remuxed this unplayable ffmpeg file with tsmuxer, PS3 can play it! When I remuxed it via ffmpeg again to mpegts, file is still unplayable but when remuxed to mp4, file is playable! I think I already spotted similar thing somewhere in forum. This mp4 was also playable on PanTV with disabled PN sending. When it was sent, I am not sure what PN was used but file was unplayable.
• ...forgot it...will add it if I will remember...

[ExSport]

Definitely there should be separate thread for bugs
I checked google code and it seems it is not used as bug tracker (months there are no updates from devs) so posted it here. Also here better formating can be used to make thoughts more readable.

[SubJunk]

Thanks for all the testing!
The reason we don't have a separate "bugs" section is because many users think they have a bug when they ask for support, but sometimes they are using it wrong or they actually mean a feature request, so it's better to just call it all "support" and treat everything like a potential bug. I hope that makes sense

During the installation I set 2GB of memory for UMS. It is saved in registry. Unfortunately when UMS is starting it rewrites value to 1280 so 2GB is lost and not used.

OK. Maybe Optimus can have a look since he is the most recent maintainer of that code.

ffmpeg engine is using wrong DLNAOrgPN value so file is unplayable e.g. on PanTV. Check link. Right now I am not sure if it is true for remuxed or also transcoded files. I tested so many scenarios so my brain is overloaded little bit. Using DLNAOrgPN=false made files playable (PN is not sent in this case)

Replied in that thread

[engine] name at the end of file name means UMS should remux or transcode file depending on audio/sub priority. When subs are not needed => remux, transcode otherwise. It is something like auto-smart-engine. But if [engine] name is at the beginning like in transcode folder, UMS should force transcoding like it works for MEncoder. It is not true when "remux if possible" is enabled for [FFmpeg] engine. So there is inconsistency in logic between these two engines! Not possible to force transcoding this way.

The reason the transcode folder doesn't mux when you select MEncoder is because MEncoder never muxes in the first place, it just defers to tsMuxeR when it can. FFmpeg and tsMuxeR are the only engines that truly mux, so selecting either of them in the transcode folder can make them mux.
It is a confusing thing and I think that's why PMS decided to remove the ability to automatically remux. However if we made it as you suggest, that using the FFmpeg engine via the transcode folder should always transcode, then it is still illogical because tsMuxeR muxes.
I will have to think about which is the less-illogical situation.

When video have more than one audio tracks and second, third,4th...is DTS then for ffmpeg engine first track is loaded and tagged as DTS also in case it is AC3. It is because DTS muxing doesn't use -map parameter so always first track is loaded. When e.g. playing second DTS track and first is AC3, tsmuxer mux it as DTS so no audio is present on renderer.

I'm not sure what you mean by "tsmuxer mux it as DTS so no audio is present on renderer", I thought you were talking about FFmpeg, not tsMuxeR?

when ffmpeg engine is used with subs, quality is very very poor also with max quality set =1Gbit. Mencoder w/wo subs and tsmuxer is OK. Also ffmpeg without subs is OK but it is because of bug mentioned earlier that file was remuxed also in case transcode folder was used.

I will test this

It seems ffmpeg generates hw incompatible mpegts files. I tried to remuxed mkv with h264 so ffmpeg is using annexb and mpegts output. This file is unplayable on PS3 also when I remuxed them on PC and uploaded it directly to PS3. When I remuxed this unplayable ffmpeg file with tsmuxer, PS3 can play it! When I remuxed it via ffmpeg again to mpegts, file is still unplayable but when remuxed to mp4, file is playable! I think I already spotted similar thing somewhere in forum. This mp4 was also playable on PanTV with disabled PN sending. When it was sent, I am not sure what PN was used but file was unplayable.

FFmpeg muxing works OK for me most of the time, sometimes it fails though which is why it is disabled by default.

[ExSport]

Subjunk thanks for feedback.

I'm not sure what you mean by "tsmuxer mux it as DTS so no audio is present on renderer", I thought you were talking about FFmpeg, not tsMuxeR?

It means that UMS will generate two separate FFmpeg pipes, one video and one audio track. This is sent to tsMuxeR. Meta file include these two pipes and for audio lpcm is defined there. But as I said UMS missed map param for DTS audio so always first track is loaded. First problem is that incorrect track is loaded but when it is DTS you can hear audio, but incorrect track. But second problem is that if first track is AC3 then no audio is played because meta file have lpcm defined for ac3 so tsmuxer output is "wrong".

About the HW incompatible files generated with ffmpeg when remuxing is used=annexb+mpegts:
Tested only few mkv files, will try more but for me resulting files were not playable on two PS3s but when I changed mpegts to mp4 remux done by FFmpeg, then files were compatible. But PC and PanTV played both alternatives.
Next time will test more files if test results will differ(outside home for 2 weeks)...

About muxing/transcoding:
[MEncoder]movie.mkv is transcoded by MEncoder whatever settings is used
Movie.mkv[MEncoder] is remuxed by tsMuxer when "remux when possible" is enabled. When disabled, file is transcoded by MEncoder
[FFmpeg]movie.mkv is remuxed when "remux when possible" is enabled. When disabled, time is transcoded.
Same settings in UMS for different engines, different behavior.
When engine is typed at the end of file I always took it as something like [auto] and when it is typed before file, I took it like forced engine. Right now ffmpeg changed this "logic/feel". tsMuxeR is tsMuxeR so here all the time I expect that file will be remuxed in all cases whatever renderer position in name is used
Thanks for support!
Edited!

[Optimus_prime]

During the installation I set 2GB of memory for UMS. It is saved in registry. Unfortunately when UMS is starting it rewrites value to 1280 so 2GB is lost and not used.

OK. Maybe Optimus can have a look since he is the most recent maintainer of that code.

I'll take a look at it when i'm back from holidays

[ExSport]

One hint, final memory size is taken from registry, not "hardcoded" or "counted". If you will change permissions on registry key so UMS can't change it, it is used as registry say
Hope it helps in troubleshooting.

[Optimus_prime]

Yeah the fix will be up soon, i've hardcoded the memory amount nsis decides to launch with, thus ignoring the user set amount. My bad
The hardcoding is ignores your own value. I'm attempting to fix it
Edited

[Optimus_prime]

Exsport, Fixed with pull request submitted

[ExSport]

If I am not wrong this code part changes heapsize registry from installation package (NSIS) but what I described is that running ums.exe/ums.jar itself changes the registry value when it is starting.

[Optimus_prime]

No, it's the correct one. Like i said on git, i can upload a working copy or you can build from my git branch nsis_size_fix. (Also i wouldn't submit unless i had fixed it)