Performance / concurrency / MediaInfoParser

[ik666]

This PR makes UMS significantly more responsive in the initial scan phase after startup. Main blocking point was actually the MediaInfoParser, which is now multi threading aware.

There is still some blocking in the MediaStore.getResource and MediaStore.getResources methods, which causes a control point to block initially for some seconds (in my case up to 20). However, every consecutive browse request is going through without any blocks. I'll have a look at that later.

[SubJunk]

Good idea!

[SurfaceS]

@ik666

You don't have to mess up too much the code to have concurrent MediaInfo parsing.
See #4638

[SurfaceS]

@ik666
In case of parallel access to the same objectID and same renderer, later threads wait till first one finishes.

Each renderer has its own store under MediaStore.
synchronized members will lock the store (not all renderer's store).

On StoreContainer :
synchronized members will lock this container (not all container).

I think synchronized members for StoreContainer are correct.

Maybe it is too much synchronized members on MediaStore.

But, JUPnP was locking the entire service on serving requests.
This lock was removed in favor of synchronized members on MediaStore, that lock only the renderer store, allowing other renderers to be served concurrently.
I think synchronized is the way to keep, but it can be improved a bit.

[ik666]

@SurfaceS Thanks for comments and your code review. I'm not such a fan of static code access, but I can live with it and will merge your changes.

Let's investigate the blocking thing when we run into issues. I'm working on blocking/waiting on requests for the same objectID and renderer. The synchronized methods synchronize agains the class, and this is IMHO far to much (block all renderer).

Usually - in the current design - there is very little concurrency, because, as you mentioned, mediaStores are held for each renderer.

[SurfaceS]

The synchronized methods synchronize agains the class, and this is IMHO far to much (block all renderer).

The synchronized methods synchronize against the associated instance of the class => this.

[ik666]

The synchronized methods synchronize agains the class, and this is IMHO far to much (block all renderer).

yes ...

[ik666]

Added user responsiveness. In case a requested folder cannot be scanned in time (2 seconds), a folder is presented to the user telling him to wait and rescan. If a request takes always longer than 2 second this implementation will actually fail. In that case, we could cache the result for later use (maybe should be implemented anyways).

[SurfaceS]

AtomicBoolean mean volatile int, but why not.

[SurfaceS]

@ik666
I've just reviewed your PR.
You can copy/paste my code (#4638 #4639 #4640 #4643) on this PR if needed. I just want to have a fixed/working/clean PR.

Added user responsiveness. In case a requested folder cannot be scanned in time (2 seconds), a folder is presented to the user telling him to wait and rescan. If a request takes always longer than 2 second this implementation will actually fail. In that case, we could cache the result for later use (maybe should be implemented anyways).

@ik666 Move this part under a separate PR as I don't think it will be merged, so it will late your PR.