I've been trying to fix the FIXMEs in this commit. Basically, the PS3's support for different formats is hardcoded into PMS, via a method Format.ps3compatible(), which causes problems for non-PS3 renderers e.g. [No Transcode] option does not appear under the #Transcode# folder for an .mkv on a mkv-supporting renderer.

I decided to define an abstract Format.isCompatible(DLNAMediaInfo media, RendererConfiguration renderer) method. The intention is to give flexibility on which detection method will be used for specific formats. Maybe there is a nicer way of doing this?

I have modified the MPEG.java, WAV.java, and MP3.java formats to check the renderers conf for compatibility. The remaining formats will point back to ps3compatible() in order to preserve the experience for formats where generalized compatibility detection has not been defined.

All the FIXMEs were then modified to use the isCompatible() method. The implementation of isCompatible() is working for the VirtualFileTranscodeFolder.java FIXME ([No Transcode] option) and the 1st DLNAResource.java FIXME (stream/transcode decision). I am not sure how to test the remaining 2 FIXMEs ("remove child" and "secondary format").

This log shows my results for several renderers when browsing the same shared video folder:("for direct streaming" means the video was detected as compatible and a [No Transcode] option has been added)

Thanks, I will look into a pull request. The attached patch was created with Eclipse in Git format.

Be warned, when you take a closer look you will see inefficiencies. If you are happy with the abstract isCompatible() method and the respective overrides, I will investigate the possibility of storing the result somewhere after the 1st call, so that subsequent calls can retrieve the value without much computation.

If you have better ideas, feel free to tell me what you want and I'll do my best to get it up to PMS standard.

Edit: Been looking and learning. I will try clean up the inefficiencies before sending a pull-request.

I have reviewed the patch, made some adjustments and committed it to a fresh branch named "iscompatible".The proposed change looked good, thanks!

Most of my changes added comments, reformatted code a bit and marked the old method as deprecated.Formats cannot know upfront what renderers they are compatible with, so there is no need for any format to override the default isCompatible() behavior.To enforce this, I moved the method to Format and made it final.

Funny how unit tests manage to bring out inconsistencies hidden in old code. It looks like isCompatible() is fully backwards compatible with ps3compatible(); no build failure when I build the latest version of the iscompatible branch.

Sorry, haven't had much time lately. Excellent progress! The comments are good... I found the names of the types in the Format type hierarchy to be misleading.

The last commit shows the reason why I chose to make isCompatible() over-ridable... the media info library and force stream extensions are not always enough to assess format compatibility. I guess the idea needs to be made more general before the method can be made final.

What do you think about the liberal use of the RendererConfiguration.match(media) method? It seems to be a long routine and can be called several times for every child added (now that Format.isCompatible() makes use of it). Would probably need some kind of caching system if this causes problems.

Edit: Most of the video formats have been tested and are detecting properly for all my renderers.

StreamHD wrote:Sorry, haven't had much time lately. Excellent progress! The comments are good... I found the names of the types in the Format type hierarchy to be misleading.

The last commit shows the reason why I chose to make isCompatible() over-ridable... the media info library and force stream extensions are not always enough to assess format compatibility. I guess the idea needs to be made more general before the method can be made final.

Well, the code is a bit peculiar there. WEB isn't a format, it's a protocol. And why would a MP3 or MPG downloaded via the web or some other protocol not be supported by a renderer? It merely means transport will be different.

But that's an exercise for another time.

What do you think about the liberal use of the RendererConfiguration.match(media) method? It seems to be a long routine and can be called several times for every child added (now that Format.isCompatible() makes use of it). Would probably need some kind of caching system if this causes problems.

If problems arise the outcome can be stored for reuse.But for now it seems to work as advertised.

Edit: Most of the video formats have been tested and are detecting properly for all my renderers.

Good! After that last commit no problems here either. I'll make a pull request for it.

Raptor399 wrote:Well, the code is a bit peculiar there. WEB isn't a format, it's a protocol. And why would a MP3 or MPG downloaded via the web or some other protocol not be supported by a renderer? It merely means transport will be different.

But that's an exercise for another time.

That makes alot more sense!

Raptor399 wrote:If problems arise the outcome can be stored for reuse.But for now it seems to work as advertised.

Take a look at the commits to my iscompatible branch. It solves the inefficiencies without getting a headache over WEB.java.