Sometimes property might return a subclass type when object is subclassed.
This especially happens with custom GdkPaintable implementations.
For this reason instead of comparing object type, check if it inherits what we want.
When seeking to a marker position, logic always used NORMAL seek method since
FAST would be too inaccurate. This is fine, but when user sets preferred seek
method to ACCURATE we should use it always (including seeks to marker positions).
Sometimes data is similar and can be determined to be a playlist
by NOT including some specific syntax (e.g. HLS). For this reason
add ability to define an exclusion requirement for playlist parsers.
Similar to queue alternation functions present in reactable, also
add ones for timeline alternations as these are a must for non-newly
created items.
For consistency, remove auto thread switching logic from insert/remove
functions in ClapperTimeline object. Such behavior is unexpected and
I feel it could lead to potential issues such as deadlocks.
It was ported to Clapper Enhancers repo as a plugin called "Control Hub"
for better clarity what it does. Applications using old one should slowy
move towards using new implementation instead.
Slight cleanup related to media item construction.
Also fixes an issue where item ID was not being set when
created with g_object_new (what bindings usually use).
In cases where there are multiple objects resolving a playlist at once
(e.g. player starts playing playlist item that Media Scanner also works on),
just ignore parsing results from the other parser. We keep/use parsing
results from whichever parser parsed the playlist first.
Instead of doing this inside player, logic was reworked and moved into playlist demuxer
itself. It uses GstQueries to communicate with upstream elements. This way we can post
an error from running pipeline which helps keep this logic in single place and have it
shared with other pipelines (like the one used in Media Scanner Enhancer).
As part of the rework, nested playlist limit was added and set to 10 redirects.
Seems like a safe/optimal number and this simplifies stuff a lot. Instead of
keeping a list of strings with previous redirected URIs, we can just store the
one most recent in media item.
Fixes a problem where error message from unplayable URI content
(e.g. non-existing file) arrives on pipeline bus before resolved
playlist which contains that URI.
With this change, a playlist can be resolved into individual items
which are put into queue even if first item of it is unplayable.
We do not want to create situations where multiple threads are running
cache cleanup at once (since they all think last one was run long ago).
This can be prevented with a combination of global mutex and a "trylock",
so we can simply avoid both mutex locking and starting another cleanup.
This should be used internally for whether title is still used from parsing, not if parsing was successful.
Fixes an issue where in such cases correct title is not updated later on.
In some cases, simple properties in reactable enhancers are not enough.
This allows enhancers to do something on a signal from user (e.g. button/shortcut press).
It can also be used to communicate with the player for things that were
already done externally (like playlist parsing in Media Scanner enhancer).
Allows to mark a job with a given ID as started, then when another thread/instance
wants to process the same ID we can detect it and await previous job finish.
This is especially useful for not extracting the same URI concurrently while
still allowing to process multiple different URIs at once without blocking.
