With the knowledge of the relationship between isCompatible(), isStreamableV2(), and isSkipTranscode(); and also the peculiarity with WEB.java it was possible to optimize the efficiency of the DLNAResource.addChild() method. Here, the isIncompatible variable is used to over-ride the relationship for WEB "formats".
The #TRANSCODE# folder is only generated for children of type video, so the child's format is never null. Similarly, the following relationship applies (we never deal with the WEB "format" here): isCompatible() = (isStreamableV2() || isSkipTranscode())
child. These values describe the child and should be associated with it. This fixes a bug in VirtualFileTranscodeFolder.java, where justStreamed.isSkipTranscode() always returns false during the the [NO TRANSCODE] folder decision.
Remove forceTranscodeV2. Use isStreamableV2() and setStreamableV2() instead. The DLNAResource.isStreamableV2() method is intended to describe whether a resource's media info has support defined from it's default renderer. This value can be stored instead of continuously recalculating it.
fact streamable. This patch ensures/enforces the following relationship: Format.isCompatible() = isSkipTranscode() && !forceTranscodeV2 The above relationship may be exploited in the future to enhance the efficiency of the code. The override of isCompatible() by WEB.java currently prevents this (it is the only "format" which breaks the relationship). Motivation for use as exploit: See the addChild() method in DLNAResource.java and notice how the conditional statements reduce when applying this relationship. The same applies for FileTranscodeVirtualFolder.java. Additionally, there is more control over when RendererConfiguration.match() and Format.skip() are executed.
The method interfered with the correctness of isCompatible() and its backwards compatibility with ps3compatible(). On top of that the comment seemed to want to force transcoding, where in reality returning true ended up forcing streaming. To remove this paradox and to restore control to each individual renderer configuration the method has been removed, bringing the code in line with all other formats.
Removed the overrides of it in all formats. Also verified that the PS3.conf correctly mimicks the behavior of ps3compatible(), meaning the new isCompatible() should correctly mimicks the behavior of ps3compatible() for the PS3 in particular. Other renderers may notice different behavior now that the hardcoded behavior of ps3compatible() is gone. That is a side effect of the newly won possiblity to truly configure compatibility per renderer.
Added info to Renderer.conf for hidden params.
(See: http://www.ps3mediaserver.org/forum/viewtopic.php?f=11&t=12530&p=63509#p63507) This reverts commit 6edfca1.
…of channel handling threads to 1 to avoid concurrency issues. This should fix issue 1156 for the HTTP V2 engine. Logging reveals that multiple threads can be involved in handling the same request. The PMS code has not been designed to handle one request with multiple threads in parallel. As a result concurrency issues arise at random locations, several ArrayOutOfBoundsExceptions and NullPointerExceptions have been reported at places where they should not occur in a single thread environment. To avoid concurrency issues this commit limits the number of pool threads to 1. Performance does not seem to take a hit from this change. Also, it is still possible to stream to multiple clients at the same time. See: http://docs.jboss.org/netty/3.2/api/org/jboss/netty/handler/execution/OrderedMemoryAwareThreadPoolExecutor.html